VYPR
Critical severityNVD Advisory· Published Nov 7, 2022· Updated May 1, 2025

CVE-2022-44797

CVE-2022-44797

Description

btcd before 0.23.2, as used in Lightning Labs lnd before 0.15.2-beta and other Bitcoin-related products, mishandles witness size checking.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

btcd before 0.23.2 mishandles witness size checking, allowing large witness data to be parsed, which can crash lnd nodes when processing certain large blocks.

Vulnerability

Overview

CVE-2022-44797 describes a flaw in btcd (and its derivative lnd by Lightning Labs) where the software incorrectly validates witness data size during transaction parsing. Specifically, btcd versions prior to 0.23.2 imposed a maximum witness item size of 11,000 bytes (maxWitnessItemSize = 11000), but the Bitcoin consensus rules allow witness elements up to 4,000,000 bytes. This mismatch meant that btcd would reject legitimate transactions with large witness elements that comply with consensus rules, causing a denial-of-service condition for nodes using btcd or lnd [1][4]. The commit that fixes the issue raises maxWitnessItemSize to 4,000,000 bytes, aligning with the actual consensus limit [4].

Exploitation

An attacker could craft a Bitcoin transaction containing a witness element larger than 11,000 bytes but within the 4,000,000 byte consensus limit. When a btcd or lnd node (before the fix) attempts to parse a block containing such a transaction, the overly restrictive check causes the node to fail to process the block. This can lead to a node becoming unable to synchronize with the blockchain or process new blocks, effectively rendering it inoperable until the offending block is skipped or the node is patched [2]. The attack requires no authentication or special network position; an attacker can simply broadcast the malformed transaction and have it mined into a block, affecting any vulnerable node that receives that block.

Impact

The primary impact is a denial-of-service condition affecting lnd nodes (before v0.15.2-beta) and btcd nodes (before v0.23.2). Because lnd is commonly used as a Lightning Network implementation, vulnerable nodes could be forced offline, potentially disrupting payment channels and causing financial losses. The official release notes for lnd v0.15.2-beta describe this as an 'emergency hot fix release' to address a bug that can cause lnd nodes to be unable to parse certain large blocks [2].

Mitigation

The vulnerability is fixed in btcd version 0.23.2 and lnd version 0.15.2-beta. Users of either software should upgrade to the patched version immediately. No workarounds are documented; the only reliable mitigation is to update to the fixed releases [2][3]. The fix involves updating the maximum witness item size constant to match the consensus limit of 4,000,000 bytes [4].

AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected packages

Versions sourced from the GitHub Security Advisory.

PackageAffected versionsPatched versions
github.com/btcsuite/btcdGo
< 0.23.20.23.2
github.com/lightningnetwork/lndGo
< 0.15.2-beta0.15.2-beta

Affected products

3

Patches

1
7fdaf6958781

wire: remove erroneous witness size check in wire parsing

https://github.com/btcsuite/btcdOlaoluwa OsuntokunOct 10, 2022via ghsa
2 files changed · +15 12
  • blockchain/weight.go+1 1 modified
    @@ -7,9 +7,9 @@ package blockchain
     import (
     	"fmt"
     
    +	"github.com/btcsuite/btcd/btcutil"
     	"github.com/btcsuite/btcd/txscript"
     	"github.com/btcsuite/btcd/wire"
    -	"github.com/btcsuite/btcd/btcutil"
     )
     
     const (
    
  • wire/msgtx.go+14 11 modified
    @@ -106,24 +106,26 @@ const (
     	// an input's witness data. This number is derived from the fact that
     	// for script validation, each pushed item onto the stack must be less
     	// than 10k bytes.
    -	maxWitnessItemSize = 11000
    +	maxWitnessItemSize = 4_000_000
     )
     
     // TxFlagMarker is the first byte of the FLAG field in a bitcoin tx
     // message. It allows decoders to distinguish a regular serialized
     // transaction from one that would require a different parsing logic.
     //
     // Position of FLAG in a bitcoin tx message:
    -//   ┌─────────┬────────────────────┬─────────────┬─────┐
    -//   │ VERSION │ FLAG               │ TX-IN-COUNT │ ... │
    -//   │ 4 bytes │ 2 bytes (optional) │ varint      │     │
    -//   └─────────┴────────────────────┴─────────────┴─────┘
    +//
    +//	┌─────────┬────────────────────┬─────────────┬─────┐
    +//	│ VERSION │ FLAG               │ TX-IN-COUNT │ ... │
    +//	│ 4 bytes │ 2 bytes (optional) │ varint      │     │
    +//	└─────────┴────────────────────┴─────────────┴─────┘
     //
     // Zooming into the FLAG field:
    -//   ┌── FLAG ─────────────┬────────┐
    -//   │ TxFlagMarker (0x00) │ TxFlag │
    -//   │ 1 byte              │ 1 byte │
    -//   └─────────────────────┴────────┘
    +//
    +//	┌── FLAG ─────────────┬────────┐
    +//	│ TxFlagMarker (0x00) │ TxFlag │
    +//	│ 1 byte              │ 1 byte │
    +//	└─────────────────────┴────────┘
     const TxFlagMarker = 0x00
     
     // TxFlag is the second byte of the FLAG field in a bitcoin tx message.
    @@ -586,8 +588,9 @@ func (msg *MsgTx) BtcDecode(r io.Reader, pver uint32, enc MessageEncoding) error
     			// item itself.
     			txin.Witness = make([][]byte, witCount)
     			for j := uint64(0); j < witCount; j++ {
    -				txin.Witness[j], err = readScript(r, pver,
    -					maxWitnessItemSize, "script witness item")
    +				txin.Witness[j], err = readScript(
    +					r, pver, maxWitnessItemSize, "script witness item",
    +				)
     				if err != nil {
     					returnScriptBuffers()
     					return err
    

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

8

News mentions

0

No linked articles in our index yet.