Jekyll2026-06-18T10:10:31+00:00https://lightning.community/SI/feed.xmlLightning Labs Security AdvisoriesThese are the security advisories for Lightning Labs products. Please report any security issues to security@lightninglabs.engineeringLND Gossip Nil-Map Panic on Zero-Timestamp Messages2026-06-18T09:00:00+00:002026-06-18T09:00:00+00:00https://lightning.community/SI/2026/06/18/lnd-zero-timestamp-gossip-dosImpact

An unauthenticated peer could crash a victim lnd node by sending a channel_update or node_announcement carrying a timestamp of 0. In the gossiper’s announcement de-duplication path, a first-seen message with timestamp 0 skips both the discard branch and the initialization branch and falls through to an assignment into a nil senders map, triggering a panic (“assignment to entry in nil map”) that crashes the node.

There is no fund-loss path. The node restarts cleanly, but it can be crashed again by repeating the attack.

Severity

Scored against the Lightning Labs severity taxonomy (4-dimension rubric):

Dimension Score Reasoning
Impact Low Panic and crash. The node restarts cleanly; no fund-loss path and no sustained liveness invalidation.
Attack Vector High Network. Any peer can deliver the malformed channel_update / node_announcement with no prior relationship.
Exploitability High A single zero-timestamp message reliably triggers the panic on a default configuration.
Virality Low The node crashes while batching the message for rebroadcast, before relaying it, so the attack does not self-propagate through gossip. Each victim must be targeted directly.

Result: T3. Rule 3 (Impact = Low, base T3); no promotion because Virality is not High. A non-viral crash-DoS is T3 regardless of how trivially it triggers.

Patches

The issue was fixed in lnd v0.20.1-beta by lnd #10469 (“lnwire: enforce non-zero timestamp in gossip messages”), which rejects zero-timestamp gossip messages at parse time so they never reach the affected code path. Users should update to a version >= v0.20.1-beta to be protected.

Disclosure timeline

  • Reported to Lightning Labs by Nishant Bansal.
  • Reproduced and verified by Matt Morehouse using a proof-of-concept attack program.
  • Fix merged in lnd #10469 and released in v0.20.1-beta.
  • Public disclosure: 2026-06-18.

Credit

Reported by Nishant Bansal (@NishantBansal2003).

References

]]>LND Onion Bomb2024-06-20T09:00:00+00:002024-06-20T09:00:00+00:00https://lightning.community/SI/2024/06/20/lnd-onion-bombImpact

A parsing vulnerability in lnd’s onion processing logic led to a DoS vector due to excessive memory allocation.

Patches

The issue was patched in lnd v0.17.0. Users should update to a version >= v0.17.0 to be protected.

References

Detailed blog post: https://morehouse.github.io/lightning/lnd-onion-bomb/

Developer discussion: https://delvingbitcoin.org/t/dos-disclosure-lnd-onion-bomb/979

]]>Witness Block Parsing DoS Vulnerability2022-11-17T09:00:00+00:002022-11-17T09:00:00+00:00https://lightning.community/SI/2022/11/17/witness-block-parsing-dos-vulnerabilityImpact

All lnd nodes before version v0.15.4 are vulnerable to a block parsing bug that can cause a node to enter a degraded state once encountered. In this degraded state, nodes can continue to make payments and forward HTLCs, and close out channels. Opening channels is prohibited, and also on chain transaction events will be undetected.

This can cause loss of funds if a CSV expiry is researched during a breach attempt or a CLTV delta expires forgetting the funds in the HTLC.

Patches

A patch is available starting with lnd v0.15.4.

Workarounds

Nodes can use the lncli updatechanpolicy RPC call to increase their CLTV value to a very high amount or increase their fee policies. This will prevent nodes from routing through your node, meaning that no pending HTLCs can be present.

References

https://github.com/lightningnetwork/lnd/issues/7096

https://github.com/lightningnetwork/lnd/releases/tag/v0.15.4-beta

]]>