A peer with pending channels open against a victim lnd node could exhaust the
node’s heap memory by spamming channel_reestablish messages. Each
connection’s chanMsgStream holds up to 1,000 queued messages; pending
channels do not drain that stream until the link becomes active. A single
attacker connection could therefore accumulate approximately 20 MB of heap.
Scaled across the maximum permitted number of pending channels, an attacker
could force the victim to allocate approximately 20 GB of heap memory,
OOM-killing the process.
There is no fund-loss path. The node restarts cleanly, but the attack can be resumed as long as the pending channel relationships remain.
Scored against the Lightning Labs severity taxonomy (4-dimension rubric):
| Dimension | Score | Reasoning |
|---|---|---|
| Impact | Low | OOM crash. The node restarts cleanly; no fund-loss path and no sustained liveness invalidation. |
| Attack Vector | High | Network. Any peer can initiate the channel openings needed to reach the affected queue; no funded channel or prior trust relationship is required. |
| Exploitability | High | Saturating a single connection’s queue is trivial; scaling to the pending-channel limit is feasible for a motivated attacker. |
| Virality | Low | Per-victim. The attacker must have pending channels in place for each target; the attack does not propagate automatically. |
Result: T3. Rule 3 (Impact = Low, base T3); no promotion because Virality is not High.
The issue was fixed in lnd
v0.19.0-beta
by capping the chanMsgStream queue size and reducing the global
pending-channel limit from 1,000 to 50. Users should update to
v0.19.0-beta or later to be protected.
A peer could render a victim lnd node unresponsive by sending a large volume of gossip query messages. Without per-peer connection limits or bytes-based rate limiting on gossip query processing, a sustained query stream from a single peer could exhaust node resources and cause a denial of service.
There is no fund-loss path. The node restarts cleanly, but the attack can be repeated.
Scored against the Lightning Labs severity taxonomy (4-dimension rubric):
| Dimension | Score | Reasoning |
|---|---|---|
| Impact | Low | Transient denial of service. The node restarts cleanly; no fund-loss path and no sustained liveness invalidation. |
| Attack Vector | High | Network. Any peer can send gossip query messages with no prior channel relationship. |
| Exploitability | High | Sending gossip query messages requires no special capability; flooding is straightforward on a default configuration. |
| Virality | Low | Per-victim. The attacker must establish a direct connection to each target; the attack does not self-propagate. |
Result: T3. Rule 3 (Impact = Low, base T3); no promotion because Virality is not High.
The issue was fixed in lnd
v0.19.0-beta
by the combination of two changes: the global inbound non-channel peer
connection limit (also cited on the P2P connection
flooding advisory),
and lnd #9607
(“discovery: unify rate.Limiter across all gossip peers”), which replaces
the previous message-count rate limit with a byte-rate limit on outbound
gossip traffic and exposes it as two new configuration flags
(--gossip.msg-rate-bytes and --gossip.msg-burst-bytes). Together these
bound both how many peers can query in parallel and how much serialized
gossip data any one peer can extract per second. Users should update to
v0.19.0-beta or later to be protected.
Reported by Matt Morehouse.
]]>Any peer, with no prior channel relationship, could crash a victim lnd node by repeatedly sending
gossip_timestamp_filter messages. When lnd receives a
gossip_timestamp_filter, it creates in-memory copies of all channel
announcements, channel updates, and node announcements whose timestamps fall
within the requested range — potentially more than 200,000 messages for a node
with a complete view of the network graph — and spawns a goroutine to deliver
them one-by-one to the requesting peer. Because lnd continued processing
incoming messages from the same peer while those goroutines were active, an
attacker could send additional gossip_timestamp_filter messages before the
first batch was delivered, spawning more goroutines and creating additional
in-memory copies of the full announcement set. Repeating this rapidly exhausted
available memory and crashed the node.
There is no fund-loss path. The node restarts cleanly, but the attack can be repeated.
Scored against the Lightning Labs severity taxonomy (4-dimension rubric):
| Dimension | Score | Reasoning |
|---|---|---|
| Impact | Low | OOM crash. The node restarts cleanly; no fund-loss path and no sustained liveness invalidation. |
| Attack Vector | High | Network. Any peer can send gossip_timestamp_filter messages with no prior channel relationship. |
| Exploitability | High | Trivially executable; repeated filter messages rapidly exhaust memory on any victim with a non-trivial routing graph. |
| Virality | Low | Per-victim. Each target requires a direct peer connection from the attacker; the attack does not propagate through the network. |
Result: T3. Rule 3 (Impact = Low, base T3); no promotion because Virality is not High. A reachable non-viral crash-DoS is T3 regardless of how trivially it triggers.
The issue was fixed in lnd
v0.18.3-beta
by lnd #9009 —
specifically commit
013452c,
which replaces the per-syncer gossip-filter semaphore with a single global
one shared across all syncers, bounding total concurrent backlog-send
goroutines regardless of the number of connected peers. (The PR’s title
refers only to its channel-announcement banning changes; the semaphore
refactor rides alongside in the same commit.) Users should update to
v0.18.3-beta or later to be protected.
Reported by Matt Morehouse.
013452c in lnd #9009Any peer, with no prior channel relationship, could suppress a victim lnd node’s processing of
channel_update or node_announcement messages for a targeted short channel
ID (SCID). The gossiper’s validation barrier gates child messages on the
successful completion of their parent channel_announcement validation. An
attacker sends many channel_announcement messages carrying the target SCID
but an incorrect chain_hash; sending each from a different peer bypasses the
recentRejects cache, and every such announcement fails validation. Any
legitimate channel_update for that SCID that arrives while the poisoned
announcements are in flight is bound to the failing parent and is discarded.
Whether a specific legitimate update is caught in that window depends on
timing, so the attack succeeds probabilistically rather than deterministically;
the sustained spam is also observable as a broader gossip DoS.
The victim will see elevated error-log volume in the gossiper. There is no fund-loss path; affected routing-table entries degrade gracefully when stale, and routing failures are the worst observable outcome.
Scored against the Lightning Labs severity taxonomy (4-dimension rubric):
| Dimension | Score | Reasoning |
|---|---|---|
| Impact | Low | Degraded gossip accuracy for targeted SCIDs. Routing failures may increase, but there is no fund-loss path and the node continues operating normally. |
| Attack Vector | High | Network. Any peer can send channel_announcement messages with no prior channel relationship. |
| Exploitability | Med | Probabilistic. Flooding is reliable, but whether a specific legitimate channel_update is caught in the failing-parent window depends on timing. Running the spam at scale hits a non-trivial fraction of updates. |
| Virality | Low | Per-SCID, per-victim effort. The attack does not propagate through the network. |
Result: T3. Rule 3 (Impact = Low, base T3); no promotion because Virality is not High.
The issue was fixed in lnd v0.19.0-beta. Users should update to v0.19.0-beta or later to be protected.
An anchor-channel peer could prevent a victim lnd node from recovering the value of outgoing HTLCs after a force close.
For anchor channels, the first-stage HTLC sweep transaction cannot be funded from the HTLC output itself; lnd must contribute internal-wallet inputs to pay for the sweep. To guard against fee-estimate uncertainty, lnd required at minimum twice the HTLC amount to be available in the internal wallet before attempting the sweep. Because lnd’s default configuration holds only the anchor reserve (up to 100,000 sats) in the internal wallet, any outgoing HTLC above approximately 50,000 sats could go unswept when a channel force-closes — the budget check fails and no sweep is attempted.
Two failure modes follow from this:
The organic (non-adversarial) version of this bug was also observed in the wild: eventual sweeps at very high fee rates once wallet balance became available, and force closes of incoming channels as a downstream consequence.
Scored against the Lightning Labs severity taxonomy (4-dimension rubric):
| Dimension | Score | Reasoning |
|---|---|---|
| Impact | Med | Per-victim fund loss when triggered adversarially. Excessive on-chain sweep fees and cascading incoming-channel force closes when triggered organically — observed in production. |
| Attack Vector | Med | Channel partner. The attacker must have an active channel with the victim to route HTLCs through it. |
| Exploitability | Med | The 100k-sat default anchor reserve makes a non-trivial fraction of lnd nodes vulnerable; an attacker running the exploit at scale will successfully hit a meaningful fraction of targets. |
| Virality | Low | Per-victim. Each attack requires specific HTLC routing on a dedicated channel; the technique does not propagate automatically. |
Result: T1. Rule 2 (Impact = Med, base T1). No promotion (Vector ≠ High). No demotion (Exploitability ≠ Low; not both Vector and Virality are Low).
The two failure modes were addressed by separate changes, all landing in lnd v0.19.0-beta:
DeadlineHTLCRatio sweeper parameter (default
0.5). Under the new default, the sweep is self-funded from the HTLC output
itself and no longer waits on internal-wallet top-up, closing the fund-loss
path for larger HTLCs.Users should update to v0.19.0-beta or later to be protected.
An attacker could exhaust a victim lnd node’s available file descriptors by opening a large number of inbound connections that do not correspond to any shared channel. Because lnd imposed no limit on concurrent non-channel peer connections, an attacker could hold many connections open indefinitely. Once the file-descriptor limit was reached, the node could no longer open files, accept or initiate connections, or perform other file-system operations, rendering it effectively non-functional until restarted.
There is no fund-loss path. Restarting the node clears the excess connections, but the attack can be immediately resumed.
Scored against the Lightning Labs severity taxonomy (4-dimension rubric):
| Dimension | Score | Reasoning |
|---|---|---|
| Impact | Low | File-descriptor exhaustion and associated service unavailability. The node restarts cleanly; no fund-loss path. |
| Attack Vector | High | Network. Any peer can initiate inbound TCP connections with no prior relationship or shared channel. |
| Exploitability | High | Opening TCP connections requires no special capability; saturating the OS file-descriptor limit is straightforward. |
| Virality | Low | Per-victim. The attacker must establish and hold connections to each target; the attack does not propagate through the network. |
Result: T3. Rule 3 (Impact = Low, base T3); no promotion because Virality is not High.
The issue was fixed in lnd
v0.19.0-beta
by introducing a global limit on inbound non-channel peer connections. Users
should update to v0.19.0-beta or later to be protected. Node operators running
large routing nodes are also recommended to set their OS-level open-file limit
(ulimit -n) appropriate to their expected peer count.
An attacker with a direct channel to a victim lnd node could steal the value of one or more in-flight HTLCs by combining an available denial-of-service vector with a race condition in lnd’s handling of pending commitment transactions.
A channel peer can hold two valid commitment transactions at a time: a to-be-revoked commitment and a pending commitment. When the remote party’s pending commitment confirms, lnd fails back all HTLCs that were present on the to-be-revoked commitment but are absent from the pending commitment, on the assumption that those HTLCs’ outcomes have already been forwarded upstream. Under normal conditions this is safe. The race condition arises when the victim node is crashed at a precise moment — after the preimage for an outgoing HTLC becomes known but before that result has propagated to the upstream node. An attacker who controls both the crash timing (using an available unpatched DoS vector) and the confirming commitment can then claim the outgoing HTLC via the preimage path while the victim’s node, upon restart, fails back the incoming HTLC — capturing the value from both ends.
The attack requires the attacker to have at least one direct channel with the victim and access to an unpatched denial-of-service vector to control crash timing. Under those conditions it can be carried out in 10–20 minutes.
Scored against the Lightning Labs severity taxonomy (4-dimension rubric):
| Dimension | Score | Reasoning |
|---|---|---|
| Impact | Med | Per-victim fund loss; the value of one or more HTLCs can be stolen. |
| Attack Vector | Med | Channel partner. The attacker must have at least one direct channel with the victim and be able to route HTLCs through it. |
| Exploitability | Med | Requires specific conditions — a direct channel and an available DoS vector to control crash timing — but is reliably executable when those conditions are met. Without a DoS vector the race window is extremely narrow and very unlikely to trigger in practice. |
| Virality | Low | Per-victim. Each attack requires dedicated channel setup and per-victim coordination; the technique does not propagate automatically. |
Result: T1. Rule 2 (Impact = Med, base T1). No promotion (Vector ≠ High). No demotion (Exploitability ≠ Low; not both Vector and Virality are Low).
The issue was fixed in lnd
v0.18.0-beta
by lnd #8667 (“Merge new
sweeper branch to master”), which brought
lnd #8514 into master
along with its isPreimageAvailable guard on the fail-back path (commit
6f0c2b5).
The guard causes checkRemoteDiffActions to skip failing back an outgoing
HTLC that is present on the to-be-revoked commitment but absent from the
pending commitment when the preimage is already known, eliminating the race
window. Users should update to v0.18.0-beta or later to be protected.
Reported by Matt Morehouse.
]]>Any peer, with no prior channel relationship, could exhaust a victim lnd node’s memory by sending a
flood of query_short_chan_ids gossip messages. Two compounding buffers amplify
the attack: the gossiper’s per-peer message stream holds up to 1,000 queued
messages, and each GossipSyncer maintains an additional 100-message buffer.
Each deserialized query_short_chan_ids message can be up to 128 KB (larger
when zlib-encoded). A single peer can therefore force the victim to allocate
approximately 140 MB of heap; repeated across multiple peers the node quickly
runs out of memory and the process is OOM-killed.
There is no fund-loss path. The node restarts cleanly, but the attack can be repeated.
Scored against the Lightning Labs severity taxonomy (4-dimension rubric):
| Dimension | Score | Reasoning |
|---|---|---|
| Impact | Low | OOM crash. The node restarts cleanly; no fund-loss path and no sustained liveness invalidation. |
| Attack Vector | High | Network. Any peer can send gossip messages with no prior channel relationship. |
| Exploitability | High | Flooding the buffers requires only repeated message sends; the stacked per-peer and per-syncer buffers make this reliably achievable. |
| Virality | Low | Per-victim. Each target requires a direct peer connection from the attacker; the attack does not propagate automatically. |
Result: T3. Rule 3 (Impact = Low, base T3); no promotion because Virality is not High.
The issue was fixed in lnd v0.19.0-beta. The connection limit introduced to address the P2P connection-flooding issue also caps the per-peer memory exposure from this attack. Users should update to v0.19.0-beta or later to be protected.
Reported by Matt Morehouse.
]]>A channel initiator could cause a victim to recover little or nothing from a
breach transaction by manipulating update_fee immediately before executing a
fraudulent close.
The attack proceeds in five steps. Alice (the channel initiator) sends Bob an
update_fee setting the fee rate high enough to burn the majority of the
channel balance to transaction fees, completing a full commitment exchange. She
then sends a second update_fee returning the fee rate to a normal level,
completing another full exchange. At this point Alice’s node holds a revoked
high-fee commitment. Alice performs a circular rebalance to empty the channel
into another of her channels, then broadcasts the revoked high-fee commitment.
Bob’s breach-remedy transaction successfully spends the breach output, but the
fee rate in that commitment consumes nearly the entire channel balance — leaving
Bob with at most the channel reserve.
Two variants exist. In the griefing variant Alice simply destroys the channel balance at a cost to herself of the reserve (approximately 1% of capacity). In the profit-seeking variant Alice colludes with a miner to capture the burned fees, netting approximately 97% of the channel balance at a reserve cost of 1%.
Scored against the Lightning Labs severity taxonomy (4-dimension rubric):
| Dimension | Score | Reasoning |
|---|---|---|
| Impact | Med | Per-victim fund loss. The victim’s breach-remedy transaction is valid, but the channel balance has been burned to fees. Loss is bounded by the affected channel; each additional victim requires the attacker to fund a new channel (capital lock, on-chain cost), so damage is not disproportionate to attacker effort. |
| Attack Vector | Med | Channel partner only. The attacker must be the channel initiator in a funded channel with the victim. |
| Exploitability | High | The griefing variant is reliable against any channel partner. The profit-seeking variant requires miner collusion and is harder. The dominant variant drives the score. |
| Virality | Med | Replayable template. The same attack can be applied to any channel Alice has initiated, but each attempt requires a separately funded, capital-locked channel — so the marginal cost per victim is real, not near-zero, and virality is Med rather than High. |
Result: T1. Rule 2 (Impact = Med, base T1). No promotion (Vector ≠ High). No demotion (Exploitability ≠ Low; not both Vector and Virality are Low).
The issue was fixed in lnd
v0.18.3-beta
by lnd #8824 (“multi:
include commitment fees in dust calculation”, commit
ac4ef28).
On receiving an update_fee, the recipient now computes the proposed
feerate’s total commitment-fee-plus-dust exposure on both commitments; if
either would exceed the configurable MaxFeeExposure limit (default 500,000
sats), the update is rejected and the channel link fails. The same limit is
applied on HTLC adds so that an attacker cannot bypass it by stuffing HTLCs
to inflate commitment weight past the cap. Users should update to
v0.18.3-beta or later to be protected.
Note: MaxFeeExposure is an absolute cap, not a fraction of channel
capacity. On channels well above ~500,000 sats total balance the burn is
bounded by the cap; on smaller channels a malicious initiator can still
burn a significant fraction of the balance within it.
Reported by David Harding.
]]>Any peer, with no prior channel relationship, could exhaust a victim lnd node’s memory by spamming
channel_announcement messages. The gossiper’s validation barrier initializes
internal dependency maps (nodeAnnDependencies, chanEdgeDependencies) for
each incoming announcement but failed to clean those maps up after processing.
An attacker that sends a continuous stream of channel_announcement messages
fills the maps without bound, eventually OOM-killing the process.
There is no fund-loss path. The node restarts cleanly once the attacker disconnects, but the attack can be repeated.
Scored against the Lightning Labs severity taxonomy (4-dimension rubric):
| Dimension | Score | Reasoning |
|---|---|---|
| Impact | Low | OOM crash. The node restarts cleanly when the attacker disconnects; no fund-loss path and no sustained liveness invalidation. |
| Attack Vector | High | Network. Any peer can send channel_announcement messages with no prior channel relationship. |
| Exploitability | High | Trivially executable; a continuous stream of announcements saturates the maps on a default configuration. |
| Virality | Low | Per-victim. The attacker must hold a connection to each target; the attack does not propagate through the network. |
Result: T3. Rule 3 (Impact = Low, base T3); no promotion because Virality is not High. A reachable non-viral crash-DoS is T3 regardless of how trivially it triggers.
The issue was fixed in lnd v0.19.0-beta. Users should update to v0.19.0-beta or later to be protected.