Lightning Attacks Index
Real incidents and disclosed vulnerabilities, with VLS takeaways
TL;DR
This page tracks 17 Lightning incidents and disclosed theft-capable vulnerabilities. 4 of them drained real funds. Each entry covers what broke, how the attack worked, and whether VLS would have stopped it.
Could VLS have stopped them?
- 6 yes: rules like fee ceilings, spend caps, and payment approval would have blocked the signature.
- 1 limits damage: the attack isn't blocked outright, but fee ceilings and velocity limits cap how much it can extract.
- 3 fix in development: the policy rule that would block these is designed but not implemented yet.
- 4 alert only: DoS attacks and chain blindness. VLS can't block these, but its heartbeat and independent chain view warn the operator so they can step in before deadlines expire.
- 3 no: bugs in how the node builds its on-chain claims. There is no bad signature to block and no reliable signal to alert on.
In the 4 incidents with confirmed losses, the node signed every draining payment because a bug in the software around it asked it to. The verdict on each card goes into detail.
What belongs in this index
Two categories are included:
- Real incidents: documented cases where funds were drained or service integrity was compromised.
- Disclosed theft-capable vulnerabilities: credible disclosures where loss is possible, even if no public loss total exists.
Incidents and disclosed vulnerabilities
Filter incidents
Concurrent-withdraw race drained 4.07 BTC
A race condition in LNBank's balance enforcement allowed an attacker to trigger many concurrent withdrawals before the database reflected prior withdrawals, draining Lightning liquidity via outgoing payments.
A race condition in LNBank's balance enforcement allowed an attacker to trigger many concurrent withdrawals before the database reflected prior withdrawals, draining Lightning liquidity via outgoing payments.
- Impact: 4.07 BTC reported drained from one operator in ~20 minutes (~$164,500 at the time).
- Bug class: concurrency and stale-state balance checks.
- Spectrum fit: Level 2 for the operator (self-custody hot node). LNBank itself is a custodial layer for users (Level 1 failure mode for them).
Background
LNBank was a third-party plugin for BTCPay Server that exposed "user wallets" under an admin custodian model, letting a self-hosted node operator offer Lightning accounts to others. The victim ran their own Bitcoin and Lightning infrastructure with LNBank on top of their node liquidity.
Attack
The attacker submitted many parallel withdrawal or payment requests. Due to a timing gap between "request accepted" and "database state updated," multiple requests could pass balance checks using stale state, effectively spending the same balance repeatedly.
Results
The operator observed a rapid sequence of outgoing Lightning payments and stopped the node after noticing, but not before a large drain. This looks like "the node approved everything" because the node did exactly what the wallet layer requested, repeatedly, at speed.
Could VLS have stopped it?
Yes, if you enforce limits at the signer. If the signer is willing to sign unlimited outgoing payments, VLS will not magically know they are "unwanted." But VLS is specifically good at enforcing hard caps that wallet-layer bugs cannot bypass.
How VLS could have stopped it
- Key separation: VLS holds signing keys in a separate process. Even if the wallet layer is compromised, the attacker cannot produce signatures directly.
- Inflight HTLC cap: VLS enforces policy-commitment-htlc-inflight-limit, capping the total value of all in-flight HTLCs on a commitment. This limits maximum exposure at any point in time.
- Velocity limits: VLS rate-limits total outgoing payment value per time window at invoice pre-approval, which would throttle how fast a drain can proceed.
Sources: victim report, maintainer recap, incident report (Atlas21), LNBank discontinued after second CVE
More details
- Why this matters: concurrency bugs are normal web-app failures, but on Lightning they can become full liquidity drains.
- What to learn: if your service lets users trigger sends, treat signer-side caps as mandatory, not optional.
- Aftermath: a second critical vulnerability was found in LNBank weeks later (December 25, 2023). The developer discontinued the plugin entirely. v1.9.2 was the final release, with sending functionality disabled.
Malicious routing fees drained more than 0.1 BTC
A public report described attackers draining an LNbits-backed wallet by forcing withdrawals to route through a node charging extreme fees. Without tight per-payment fee ceilings, the wallet can burn funds as routing fees.
A public report described attackers draining an LNbits-backed wallet by forcing withdrawals to route through a node charging extreme fees. Without tight per-payment fee ceilings, the wallet can burn funds as routing fees.
- Impact: report claims "together more than 0.1 BTC" drained.
- Bug class: fee policy gap and missing guardrails for fee limits.
- Spectrum fit: Level 1 or 2 depending on deployment, but the failure mode is "hot wallet can be coerced into paying attacker-controlled fees."
Background
LNbits is often deployed as a wallet and accounts layer in front of a Lightning node. In this report, the attacker did not need key extraction. They exploited fee policy.
Attack
The attacker opened a channel with the victim's node, deposited sats into an LNbits wallet, then sent payments to a destination where the only route passed through an attacker-controlled node charging 999,000 ppm. LNbits did not pass a fee_limit parameter to LND, so LND paid the extreme fee without objection. In one example, an 891,000-sat payment incurred ~890,000 sats in fees, nearly a 1:1 ratio. This was repeated multiple times.
Results
Funds are drained as routing fees. This can be confusing because "the payment succeeded," but the wallet balance collapses.
Could VLS have stopped it?
Yes, fee policy enforcement catches this directly. VLS enforces a maximum routing fee as a percentage of the invoice amount. A payment where fees approach 100% of the value would be rejected.
How VLS could have stopped it
- Routing fee cap: VLS enforces max_feerate_percentage, which caps routing fees as a percentage of the invoice amount. An 891,000-sat fee on an 891,000-sat payment (~100% fee) would be rejected outright.
- Inflight HTLC cap: VLS enforces policy-commitment-htlc-inflight-limit, capping the total value of all in-flight HTLCs on a commitment.
- Velocity limits: VLS rate-limits total outgoing payment value per time window at invoice pre-approval, limiting the speed of repeated extraction.
Sources: LNbits issue report, fix PR (fee_limit_msat), follow-up: Spark backend fee gaps
More details
- Note: this is a public report in a GitHub issue, not a third-party forensic postmortem.
- Builder takeaway: fee limits are not a UX detail. On Lightning, fee limits are a security boundary.
- Fix: PR #447 merged December 5, 2021 (less than a week after report), adding fee_limit_msat across LND REST, LND gRPC, and CLightning backends. A follow-up issue (#611) later showed fee-tracking gaps persisted in the Spark backend.
Exploited node API semantics, ~14M sats stolen
Public reporting states attackers exploited payout automation combined with ambiguous payment status semantics, draining the bot's hot wallet.
Public reporting states attackers exploited payout automation combined with ambiguous payment status semantics, draining the bot's hot wallet.
- Impact: ~14 million sats (~0.14 BTC, ~$9,480 at the time) reported stolen.
- Bug class: automated payouts plus ambiguous status checks and idempotency failures.
- Spectrum fit: Level 1 failure mode (custodial hot-wallet service).
Background
@lntxbot was a popular Telegram Lightning tipping bot running on Eclair (ACINQ's Lightning implementation). Users trusted the bot to custody funds and execute payouts. The bot's payout logic relied on polling Eclair's getsentinfo API for payment status.
Attack
Eclair's getsentinfo API returned an empty array [] both when a payment was never attempted AND when a payment was in-flight but not yet recorded. The bot treated [] as "not attempted" and retried, causing the same payout to be sent multiple times. Attackers exploited this ambiguity to trigger repeated payments from the bot's hot wallet.
Results
The bot's hot wallet was drained via repeated payments. The operator took the bot offline, posting: "A group of thieves have exploited a very subtle vulnerability on @lntxbot and stolen ~14 million sats."
Could VLS have stopped it?
Yes, velocity controls limit the damage. VLS rate-limits total outgoing payment value per time window. Even if the node's payout logic retries endlessly, the signer throttles how fast funds can leave.
How VLS could have stopped it
- Velocity limits: VLS rate-limits total outgoing payment value per time window at invoice pre-approval, stopping repeated payouts once the limit is reached.
- Inflight HTLC cap: VLS enforces policy-commitment-htlc-inflight-limit, capping the total value of all in-flight HTLCs on a commitment at any point in time.
Sources: case writeup, operator announcement, Éclair getsentinfo issue (root cause), Éclair fix PR, incident report (Protos)
Routing fee siphoning by design mismatch
User Reckless-Satoshi demonstrated that custodial services offering free or cheap withdrawals can be drained by positioning a high-fee routing node in the payment path and collecting the difference as profit.
User Reckless-Satoshi demonstrated that custodial services offering free or cheap withdrawals can be drained by positioning a high-fee routing node in the payment path and collecting the difference as profit.
- Impact: ~450,000 sats extracted from LNMarkets in 6 minutes (~4M sats/hour potential). Six services tested: LNMarkets, Southxchange, Bitfinex, OKEx, Muun, and Wallet of Satoshi.
- Bug class: product and policy mismatch, not cryptography.
- Spectrum fit: Level 1 failure mode (custodial service paying fees on behalf of users).
Background
Lightning routing fees are real value. If a service offers free or cheap withdrawals while paying variable routing fees, the difference can be exploited. This was demonstrated as security research (responsible disclosure, September 2021), not a malicious attack.
Attack
The researcher deposited sats into a custodial service, set up a routing node so the withdrawal path passed through it, then withdrew. The routing fee collected exceeded the service's withdrawal fee, producing a net profit per cycle. Profit condition: withdrawal_fee + deposit_fee < routing_fee_collected.
Results
Results varied by service. LNMarkets had failsafes that triggered after 6 minutes. Southxchange allowed ~300 withdrawals/minute with no initial rate limiting. Wallet of Satoshi was most resistant: it charged exact routing fees plus a 0.3% reserve, making the attack unprofitable. All flaws were disclosed and fixed before publication.
Could VLS have stopped it?
Not automatically. This is primarily a policy and product decision problem. But once you decide your fee policy, a validating signer can enforce it consistently.
How VLS could have helped
- Routing fee cap: VLS enforces max_feerate_percentage, which would catch withdrawals routed through extreme-fee nodes where routing fees consume most of the payment value.
- Velocity limits: VLS rate-limits total outgoing payment value per time window at invoice pre-approval, limiting the total extraction rate.
- Inflight HTLC cap: VLS enforces policy-commitment-htlc-inflight-limit, capping the total value of all in-flight HTLCs on a commitment.
Sources: researcher writeup (LN+), scripts repo, news coverage
"Replacement Stalling" (disclosed theft-capable)
A vulnerability in LND's sweeper subsystem allows an attacker to stall the victim's HTLC claim transactions by forcing repeated fee resets, preventing confirmation until upstream deadlines expire and the attacker can steal the channel balance.
A vulnerability in LND's sweeper subsystem allows an attacker to stall the victim's HTLC claim transactions by forcing repeated fee resets, preventing confirmation until upstream deadlines expire and the attacker can steal the channel balance.
- Impact: theft-capable: attacker can steal essentially the entire channel capacity for ~186,480 sats in attack cost. No confirmed wild exploitation.
- Bug class: on-chain resolution and confirmation dynamics around sweeping HTLC claims.
- Spectrum fit: Level 2 to 3 operators are exposed. Hardening infrastructure does not remove this class of risk.
Background
LND's sweeper subsystem batches and fee-bumps on-chain claim transactions during force closes. Discovered by Matt Morehouse during code review. Affects LND ≤0.18.5, fixed in 0.19.0-beta.
Attack
The attacker sends ~40 payments through the victim's node, then force-closes. The victim's sweeper batches all the claims into one transaction and starts bumping fees to get it confirmed before the 80-block deadline. The attacker repeatedly breaks the batch by double-spending one of its inputs. Each time the sweeper rebuilds, it resets fees back to minimum, so the victim's claims never confirm in time. After 80 blocks of stalling, the deadlines expire and the attacker takes the funds.
Results
Theft is possible under adversarial conditions even without node key extraction. Reported May 9, 2024; public issue filed January 16, 2025 after no progress; fix merged February 21, 2025; LND 0.19.0 released May 22, 2025; publicly disclosed December 4, 2025.
Could VLS have stopped it?
Not reliably by itself. This class of issue is about on-chain confirmation and resolution behavior. VLS can enforce signing policy, but it cannot force the mempool to confirm your transaction or fix a flawed claim algorithm.
How VLS could have helped
- Defense in depth: even if this class of bug is present, signer-side policies can still prevent additional damage paths during an incident.
- Operational recovery: signer-driven alerts and emergency procedures can shorten time-to-response.
- Safer defaults: enforce conservative fee bump bounds and sanity checks on sweeping-related signatures when possible.
Sources: disclosure writeup, disclosure thread
LNURL-auth SSRF (CVE-2025-32013)
A documented SSRF vulnerability in LNbits shows a common reality: Lightning failures often start as normal web app vulnerabilities, and then pivot toward wallet control.
A documented SSRF vulnerability in LNbits shows a common reality: Lightning failures often start as normal web app vulnerabilities, and then pivot toward wallet control.
- Impact: CVSS 9.3 Critical. SSRF can expose internal services, read files, and reach node APIs depending on deployment. No confirmed exploitation.
- Bug class: server-side request forgery via unvalidated callback URL in the /api/v1/lnurlauth endpoint.
- Spectrum fit: this is usually an entry point. The "loss" depends on what the attacker reaches next.
Background
Many Lightning systems are web apps: dashboards, wallet services, and APIs. Those systems have typical web attack surface. Affects LNbits < 0.12.12. Fixed in 0.12.12. Published April 2025.
Attack
When processing LNURL-auth requests, LNbits accepts a callback URL and makes an HTTP request to it using the httpx library with redirect following enabled and no URL validation. Any user who can create a wallet account can craft a request to /api/v1/lnurlauth pointing at internal network addresses (localhost, 192.168.x.x, etc.).
Results
The practical outcome is highly deployment-dependent. SSRF can enable deeper compromise, such as extracting credentials or reaching node APIs.
Could VLS have stopped it?
Yes, for preventing fund loss. VLS cannot prevent the SSRF itself, but if the SSRF leads to node compromise, VLS holds the signing keys separately. The attacker gains node access but cannot sign transactions to steal funds.
How VLS could have helped
- Key separation: VLS holds signing keys in a separate process (or hardware device). An attacker who compromises the node still cannot produce signatures.
- Velocity limits: even if the attacker can issue signing requests via the compromised node, VLS caps total outgoing value per time window.
- Policy validation: VLS validates every signing request against protocol rules and policy bounds, rejecting anything out of spec.
Sources: GitHub advisory, NVD
"Excessive Failback" exploit (theft-capable)
A disclosed LND bug where a malicious channel peer can trigger an HTLC-resolution edge case that makes the victim incorrectly "fail back" an HTLC upstream after it has effectively succeeded downstream, creating a theft-capable loss scenario.
A disclosed LND bug where a malicious channel peer can trigger an HTLC-resolution edge case that makes the victim incorrectly "fail back" an HTLC upstream after it has effectively succeeded downstream, creating a theft-capable loss scenario.
- Impact: theft-capable: attacker can steal the full value of a routed HTLC. No confirmed wild exploitation. Affects LND <=0.17.5, fixed in 0.18.0.
- Bug class: on-chain HTLC resolution logic and state replay edge case (force-close and restart conditions).
- Spectrum fit: Level 2-3 (hot node operators; hardening does not remove this class of protocol-resolution risk).
Background
Discovered by Matt Morehouse during an audit of LND's contractcourt package. Affects LND <=0.17.5, fixed in 0.18.0. The BOLT5 spec actually mandated the vulnerable behavior. CLN, Eclair, and LDK independently fixed this corner case before LND.
Attack
The attacker controls two channels around the victim (upstream and downstream) and routes a large HTLC through the victim. The HTLC is claimed downstream via preimage, but LND signs a new commitment without the HTLC and doesn't track that the preimage was revealed. After a force-close and node restart (which the attacker can trigger via an unpatched DoS), LND sees the HTLC is "missing," marks it as failed, and sends a failure message upstream. Result: downstream keeps the funds (already claimed), upstream gets refunded, and the victim loses the HTLC value.
Results
Theft is possible when the attacker can force a node restart. Reported March 20, 2024; fix merged April 19, 2024; LND 0.18.0 released May 30, 2024; publicly disclosed March 4, 2025.
Could VLS have stopped it?
Not yet. The architecture is in place, but the key policy rule is not yet implemented. VLS's persistence (KVV) survives node restarts, so preimage knowledge would not be "forgotten" like LND's was. The policy rule for this (policy-commitment-payment-settled-preimage) is not yet implemented. Payment preimage management is currently in development.
How VLS could have helped
- Restart-safe state (implemented): VLS persists HTLC settlement facts in its own KVV store, independent of the node's database. A node restart cannot erase what the signer knows.
- Independent chain view (implemented): VLS's txoo oracle and ChainTracker can observe preimage reveals on-chain without relying on the node.
- Preimage tracking (not yet implemented): once policy-commitment-payment-settled-preimage is implemented, VLS can refuse to sign a commitment that removes an HTLC for which it knows the preimage was revealed. This is currently in development.
Sources: disclosure writeup, disclosure thread, BOLT5 spec fix PR
"Excessive Failback" exploit #2 (variant)
A follow-on variant of the excessive failback exploit. The original (#7) required the attacker to force-close; this variant works when the victim force-closes using its own commitment, which the attacker can trigger by sending an error message.
A follow-on variant of the excessive failback exploit. The original (#7) required the attacker to force-close; this variant works when the victim force-closes using its own commitment, which the attacker can trigger by sending an error message.
- Impact: theft-capable, same mechanism as #7. No confirmed wild exploitation. Affects LND <=0.18.5, fixed in 0.19.0.
- Bug class: HTLC resolution replay and failback logic reachable via victim-initiated force-close path.
- Spectrum fit: Level 2-3 (hot node operators; still upgrade-critical).
Background
Morehouse discovered this variant while updating the BOLT5 spec after the original disclosure (#7). He realized there were two cases that needed updating in BOLT5, but only one had been patched in LND. Affects LND <=0.18.5, fixed in 0.19.0.
Attack
Same core mechanism as #7: the attacker controls upstream and downstream channels and routes an HTLC through the victim. The difference is the force-close path. The attacker sends an error message, causing the victim to force-close using its own commitment. After a restart, LND incorrectly fails back the HTLC upstream even though it was already claimed downstream.
Results
Theft is possible under the affected conditions. Variant reported March 5, 2025 (one day after original disclosure); fix merged March 20, 2025; LND 0.19.0 released May 22, 2025; publicly disclosed December 4, 2025.
Could VLS have stopped it?
Not yet. Same as #7: the architecture is in place, but the key policy rule is not yet implemented. VLS's KVV persistence survives node restarts, and its txoo oracle provides an independent chain view. The policy-commitment-payment-settled-preimage rule is not yet implemented. Payment preimage management is currently in development.
How VLS could have helped
- Restart-safe state (implemented): VLS state persists independently of the node, so a restart cannot cause the signer to forget settlement facts.
- Independent chain view (implemented): txoo oracle provides chain data directly to the signer.
- Preimage tracking (not yet implemented): once policy-commitment-payment-settled-preimage is implemented, VLS can refuse to sign commitments that remove HTLCs with known preimages. Currently in development.
Sources: disclosure writeup, disclosure thread (LND 0.19.0 vulns)
"Preimage Extraction" exploit (theft-capable)
A disclosed Eclair vulnerability where the node's on-chain preimage monitoring during force close only checked HTLCs in its local commitment, allowing an attacker to close the channel with its own still-valid commitment and steal funds when the victim fails to learn a revealed preimage.
A disclosed Eclair vulnerability where the node's on-chain preimage monitoring during force close only checked HTLCs in its local commitment, allowing an attacker to close the channel with its own still-valid commitment and steal funds when the victim fails to learn a revealed preimage.
- Impact: theft-capable: attacker can steal the full value of a routed HTLC. No confirmed wild exploitation. Affects Eclair <=0.11.0, fixed in 0.12.0.
- Bug class: chain monitoring and preimage extraction blind spot during force-close.
- Spectrum fit: Level 2-3 (hot node operators; this is a protocol-monitoring correctness issue).
Background
Eclair's preimage extraction code only checked HTLCs in the node's local commitment transaction. This code existed from the very beginning of Eclair. The fix (0.12.0) expanded checking to include remote and next-remote commitments. Reported March 5, 2025; fixed in just 6 days (March 11, 2025).
Attack
The attacker routes a payment: Upstream A -> Victim B -> Attacker M. The attacker fails the payment and updates the commitment, so the victim removes the HTLC from its local state. The two commitments now disagree: the victim's local commitment has the HTLC removed, but the attacker's own commitment still contains it and was never revoked. The attacker broadcasts that commitment (a valid close, not a punishable breach) and claims the HTLC on-chain using the preimage. Because the victim only monitors its local commitment for preimages, it never sees the on-chain reveal. It cannot relay the preimage upstream, so upstream gets refunded and the victim loses the HTLC value.
Results
Theft is possible without the attacker needing to compromise the node. Reported March 5, 2025; fix released March 11, 2025 (Eclair 0.12.0); publicly disclosed September 23, 2025.
Could VLS have stopped it?
Not yet. VLS's independent chain view is the right architecture for this, but the key policy rule is not yet implemented. VLS has its own blockchain view via the txoo oracle and ChainTracker, so it can detect preimages revealed on-chain even if the node misses them. The policy-commitment-payment-settled-preimage rule is not yet implemented. Payment preimage management is currently in development.
How VLS could have helped
- Independent chain monitoring (implemented): VLS's txoo oracle feeds blockchain data directly to the signer, so it does not depend on the node's chain scanning. This is exactly the capability Eclair was missing.
- Preimage tracking (not yet implemented): once policy-commitment-payment-settled-preimage is implemented, VLS can refuse to sign a commitment that removes an HTLC for which it observed a preimage on-chain. Currently in development.
- Real fix (node side): monitor every currently valid commitment (local, remote, and next-remote) for on-chain preimage reveals. This is not about revoked commitments: during an update the two sides' commitment states briefly disagree, and the counterparty can close with its own unrevoked commitment that still carries the HTLC.
Sources: disclosure writeup, disclosure thread
"Irrevocable fees" revoked commitment fee manipulation
A disclosed attack class where a malicious counterparty can manipulate commitment fee states so an older valid commitment pays up to 98% of the channel value as miner fees. Fees are "irrevocable" because even a justice transaction cannot recover them.
A disclosed attack class where a malicious counterparty can manipulate commitment fee states so an older valid commitment pays up to 98% of the channel value as miner fees. Fees are "irrevocable" because even a justice transaction cannot recover them.
- Impact: up to 98% of a channel's value can be stolen as miner fees. Estimated $2.89M/day exploitable across 3,000 channels. No confirmed wild exploitation. All four major implementations were affected.
- Bug class: fee-update bounds, commitment-state dynamics, and Bitcoin relay/mining realities.
- Spectrum fit: Level 2-3 (hot node operators; fee state is part of the safety boundary).
Background
Discovered by David Harding (with Bastien Teinturier's observation about pre-signed fee variants). Affects all four major implementations. Patched: Eclair v0.10.0 (Feb 2024), LDK v0.0.123 (May 2024), LND v0.18.3-beta (Sept 2024). CLN vulnerable when --ignore-fee-limits is enabled.
Attack
The attacker moves the channel balance to their side, then inflates commitment fees to 98% of the channel value. They restore fees to a normal level and move the balance back to the victim's side. The attacker then broadcasts or mines the high-fee commitment. The 98% goes to miners as fees, which are irrevocable: even if the victim publishes a justice transaction, they cannot recover the fees.
Results
Potentially catastrophic per-channel loss. All implementations now limit max acceptable fees to a tolerance multiple of estimated fees. A complete fix requires Bitcoin P2P changes (package relay) and LN protocol changes (static commitment fees). Discovered January 31, 2024; publicly disclosed December 10, 2024.
Could VLS have stopped it?
Yes. VLS enforces policy-commitment-fee-range, which rejects commitment transactions with fees outside configured bounds. A commitment allocating 98% of channel value to fees would be refused.
How VLS could have helped
- Fee range enforcement: policy-commitment-fee-range is implemented and would reject commitments with extreme fee states.
- HTLC inflight limits: policy-commitment-htlc-inflight-limit caps the total value at risk in HTLCs.
Sources: disclosure thread
CVE-2020-26896: invoice DB preimage-release bug
LND fell back to the invoice database when looking up preimages, releasing preimages for invoices that matched a forwarded HTLC by hash and amount. A malicious peer could intercept an HTLC, probe the preimage through a colluding relayed HTLC, and steal the intercepted funds.
LND fell back to the invoice database when looking up preimages, releasing preimages for invoices that matched a forwarded HTLC by hash and amount. A malicious peer could intercept an HTLC, probe the preimage through a colluding relayed HTLC, and steal the intercepted funds.
- Impact: CVSS 8.2 HIGH. Theft possible in certain edge cases, plus weakened receiver privacy. Affects LND < 0.11.0-beta, fixed in 0.11.0-beta. No confirmed wild exploitation.
- Bug class: preimage handling and invoice/DB isolation failure in on-chain claim path.
- Spectrum fit: Level 2-3 (routing nodes that forward HTLCs and accept payments; nodes with rejecthtlc=1 are not affected).
Background
Reported by Antoine Riard. Affects LND < 0.11.0-beta, fixed in 0.11.0-beta (PR #4157). Published October 20, 2020. The fix properly isolates the preimage database from the invoice database by checking the HTLC's next_hop field.
Attack
When claiming an on-chain received HTLC, LND would fall back to the invoice database if the preimage database didn't contain the preimage. If the HTLC's payment hash and amount collided with an invoice, LND would release that invoice's preimage even though the victim was not the final hop. A malicious peer could intercept an HTLC intended for the victim, probe the preimage via a colluding relayed HTLC, and steal the intercepted payment.
Results
Fund theft possible in specific routing scenarios. Also weakens receiver privacy by confirming HTLC destinations. Fixed in LND 0.11.0-beta by isolating preimage lookups from the invoice database.
Could VLS have stopped it?
No. This is node-side preimage and invoice database logic. VLS does not control which preimage the node uses when claiming on-chain.
How VLS could have helped
- Not applicable: the vulnerability is in LND's preimage lookup path, not in a signing request that VLS would validate.
Sources: NVD record (CVE-2020-26896), full disclosure (Lightning-Dev)
Invalid Claims Liquidity Griefing
A bug in LDK's claim aggregation code: a break statement stopped processing after the first conflicting transaction, leaving other aggregated claim transactions invalid and locking funds until manual recovery.
A bug in LDK's claim aggregation code: a break statement stopped processing after the first conflicting transaction, leaving other aggregated claim transactions invalid and locking funds until manual recovery.
- Impact: liquidity griefing: funds locked until manual recovery. A variant in LDK 0.1-beta could enable actual fund theft. No confirmed wild exploitation. Affects LDK <=0.0.125, fixed in LDK 0.1.
- Bug class: claim aggregation and conflict handling during on-chain resolution.
- Spectrum fit: Level 2-3 (hot node operators; this is on-chain claim construction correctness).
Background
Discovered by Matt Morehouse during an audit of LDK's chain module. Affects LDK <=0.0.125, fixed in LDK 0.1. LDK aggregates certain on-chain claims into single transactions to save fees. The bug was a single break statement that stopped conflict processing too early.
Attack
The attacker opens an anchor channel with the victim, routes 3 HTLCs with specific timeouts, then force-closes using a revoked commitment at a precise block height. The timing causes LDK to split claims into separate aggregated transactions. The attacker then broadcasts a transaction that conflicts with both claim transactions. LDK detects and fixes the first conflict but the break statement causes it to miss the second, leaving that claim transaction permanently invalid.
Results
The victim's node endlessly rebroadcasts the invalid claim transaction. Funds remain locked until the operator manually constructs a valid claim transaction. Reported December 23, 2024; fix merged January 15, 2025; LDK 0.1 released January 16, 2025; publicly disclosed January 23, 2025.
Could VLS have stopped it?
No. This is claim transaction construction logic in LDK's chain module. VLS does not control how the node builds or manages claim transactions.
How VLS could have helped
- Not applicable: the vulnerability is in LDK's claim aggregation code, not in a signing request that VLS would validate.
Sources: disclosure writeup
"Infinite Inbox" DoS (peer message queue OOM)
LND queued up to 1,000 messages per peer (each up to 64 KB) with no limit on peer connections. An attacker can flood the node with large messages and crash it via OOM in under 5 minutes.
LND queued up to 1,000 messages per peer (each up to 64 KB) with no limit on peer connections. An attacker can flood the node with large messages and crash it via OOM in under 5 minutes.
- Impact: node crash/hang via OOM. Demonstrated in under 5 minutes on 8 GB RAM. Attack is free. No confirmed wild exploitation. Affects LND <=0.18.5, fixed in 0.19.0.
- Bug class: resource exhaustion via weakly bounded message queuing and unlimited peer connections.
- Spectrum fit: Availability attack (orthogonal to custody level, but downtime can amplify other risks like missed HTLC deadlines).
Background
Discovered by Matt Morehouse. Affects LND <=0.18.5, fixed in 0.19.0. LND dispatched peer messages into subsystem queues (gossiper, channel link) with up to 1,000 messages per peer and no limit on inbound connections.
Attack
The attacker opens many peer connections and floods them with large query_short_channel_ids messages (up to 64 KB each). With 1,000 messages queued per peer and unlimited connections, memory is exhausted quickly. The researcher demonstrated OOM in under 5 minutes on an 8 GB node.
Results
Availability loss. The attack is essentially free for the attacker. Reported September 15, 2023; fix merged March 12, 2025 (~18 months later); LND 0.19.0 released May 22, 2025; publicly disclosed December 4, 2025. Fix: queue size reduced to 50 messages, new peer access manager limits inbound connections to 100 for peers without open channels.
Could VLS have stopped it?
No, but it can raise the alarm. VLS does not prevent a node process from being DoS'd. This is an availability attack, but prolonged downtime can become a fund theft vector if HTLC CLTV deadlines expire while the node is offline. That second part is visible to the signer: VLS knows each HTLC's CLTV expiry from the commitments it validates and follows block height through its own chain view, so it can flag approaching deadlines even while the node is down.
How VLS could have helped
- Not applicable: the vulnerability is in LND's peer message handling, not in a signing request that VLS would validate.
- Detection and alerting: VLS's heartbeat acts as a dead-man's switch: when the node stops responding, the missing heartbeat raises an operator alert. Because the signer knows the HTLC deadlines and the current block height, the operator can be warned in time to intervene (e.g., force-close from a recovery node) before deadlines expire. VLS cannot take that protective action on its own.
Sources: disclosure writeup
gossip_timestamp_filter DoS (full graph replay, OOM)
Sending gossip_timestamp_filter with timestamp 0 requests the entire network graph. LND loaded hundreds of thousands of messages into memory simultaneously, allowing an attacker to crash the node via OOM.
Sending gossip_timestamp_filter with timestamp 0 requests the entire network graph. LND loaded hundreds of thousands of messages into memory simultaneously, allowing an attacker to crash the node via OOM.
- Impact: OOM crash. Demonstrated: 8 GB RAM exhausted in minutes, swap exhausted in ~2 hours, OS kills LND. Attack is free. Affects LND <=0.18.2, fixed in 0.18.3-beta.
- Bug class: resource exhaustion via expensive gossip responses and no concurrency limits.
- Spectrum fit: Availability attack (downtime can increase risk of other failure modes like missed HTLC deadlines).
Background
Discovered by Matt Morehouse. Affects LND <=0.18.2, fixed in 0.18.3-beta. The vulnerability existed since 2018 when gossip filtering was added to LND. A first fix attempt in December 2023 failed because it could be bypassed using multiple node IDs.
Attack
The attacker sends gossip_timestamp_filter messages with timestamp 0, requesting the full network graph. LND loads all requested messages into memory simultaneously before sending them. The attacker keeps connections open by sending pings and slowly acknowledging messages. Memory grows until OOM.
Results
Availability loss. The attack is essentially free. Reported July 13, 2023; first fix attempt December 2023 (bypassed); proper fix merged August 27, 2024; LND 0.18.3 released September 12, 2024; publicly disclosed July 22, 2025. Fix: global semaphore limiting concurrent gossip_timestamp_filter requests. Alternative: set ignore-historical-gossip-filters=true.
Could VLS have stopped it?
No, but it can raise the alarm. VLS does not prevent a node process from being DoS'd. This is an availability attack, but prolonged downtime can become a fund theft vector if HTLC CLTV deadlines expire while the node is offline. That second part is visible to the signer: VLS knows each HTLC's CLTV expiry from the commitments it validates and follows block height through its own chain view, so it can flag approaching deadlines even while the node is down.
How VLS could have helped
- Not applicable: the vulnerability is in LND's gossip message handling, not in a signing request that VLS would validate.
- Detection and alerting: VLS's heartbeat acts as a dead-man's switch: when the node stops responding, the missing heartbeat raises an operator alert. Because the signer knows the HTLC deadlines and the current block height, the operator can be warned in time to intervene (e.g., force-close from a recovery node) before deadlines expire. VLS cannot take that protective action on its own.
Sources: disclosure writeup, disclosure thread
"Onion Bomb" parsing DoS (CVE-2024-38359)
A crafted onion packet with the length field set to UINT32_MAX causes LND to allocate up to 4 GB of memory per packet. Multiple packets can crash even 128 GB nodes in seconds.
A crafted onion packet with the length field set to UINT32_MAX causes LND to allocate up to 4 GB of memory per packet. Multiple packets can crash even 128 GB nodes in seconds.
- Impact: CVSS 6.5 MEDIUM. Instant OOM crash. Crashed 128 GB nodes in seconds. Attacker identity hidden via onion routing. Affects LND < 0.17.0, fixed in 0.17.0.
- Bug class: input validation and bounds checking failure during onion packet processing.
- Spectrum fit: Availability attack (orthogonal to custody, but downtime can amplify risk like missed HTLC deadlines).
Background
Discovered by Matt Morehouse via fuzz testing. Affects LND < 0.17.0, fixed in 0.17.0 (not backported to 0.16.x). LND did not validate the length field in onion packet payloads before allocating memory.
Attack
The attacker crafts an onion packet with the encoded length field set to UINT32_MAX. When the victim decodes the forwarding instructions, LND allocates up to 4 GB of memory per packet. Sending multiple packets simultaneously crashes nodes with even 128 GB of RAM in just a few seconds. The attacker's identity is hidden by onion routing.
Results
Instant crash. The victim remains offline as long as the attack persists. The attack is trivial and cheap to execute. Reported June 20, 2023; fix merged August 23, 2023; LND 0.17.0 released October 3, 2023; publicly disclosed June 18, 2024. Fix: max onion payload allocation reduced from 4 GB to 64 KB. Unpatched mitigation: --rejecthtlc flag.
Could VLS have stopped it?
No, but it can raise the alarm. VLS does not prevent a node process from being DoS'd. This is an availability attack, but prolonged downtime can become a fund theft vector if HTLC CLTV deadlines expire while the node is offline. That second part is visible to the signer: VLS knows each HTLC's CLTV expiry from the commitments it validates and follows block height through its own chain view, so it can flag approaching deadlines even while the node is down.
How VLS could have helped
- Not applicable: the vulnerability is in LND's onion packet processing, not in a signing request that VLS would validate.
- Detection and alerting: VLS's heartbeat acts as a dead-man's switch: when the node stops responding, the missing heartbeat raises an operator alert. Because the signer knows the HTLC deadlines and the current block height, the operator can be warned in time to intervene (e.g., force-close from a recovery node) before deadlines expire. VLS cannot take that protective action on its own.
Witness block parsing degraded-state bug (CVE-2022-39389)
A bug in btcd (LND's Bitcoin wire parsing dependency) causes LND to enter a "half-alive" state where it can still route payments and forward HTLCs but becomes blind to on-chain events, creating risk of fund loss if CSV or CLTV deadlines expire unnoticed.
A bug in btcd (LND's Bitcoin wire parsing dependency) causes LND to enter a "half-alive" state where it can still route payments and forward HTLCs but becomes blind to on-chain events, creating risk of fund loss if CSV or CLTV deadlines expire unnoticed.
- Impact: CVSS 8.2 HIGH (GitHub) / 6.5 MEDIUM (NIST). Node appears functional but misses on-chain events. Fund loss possible if breach or HTLC deadlines expire. Affects LND < 0.15.4-beta, fixed in 0.15.4-beta.
- Bug class: dependency bug (btcd wire parsing) leading to degraded "half-alive" node behavior.
- Spectrum fit: Level 2-3 operators (chain blindness can cause missed deadlines and fund loss).
Background
The bug is in btcd (< 0.23.3), LND's dependency for Bitcoin transaction parsing. When btcd encounters a transaction with too many witness items, it fails with "too many witness items to fit into max message size" and LND enters a degraded state. Published November 17, 2022.
Attack
The node enters a "half-alive" state: it can still route payments, forward HTLCs, and close channels, but it cannot open new channels and cannot detect on-chain events. The operator may not realize anything is wrong. If a counterparty attempts a breach or an HTLC's CLTV deadline expires during this blindness window, funds can be lost.
Results
Fund loss possible in deadline-driven scenarios while the node is blind. Fix: update btcd to v0.23.3 (LND PR #7004), released in LND 0.15.4-beta.
Could VLS have stopped it?
No. This is a dependency parsing bug causing chain monitoring blindness. VLS cannot fix btcd's wire parsing or force the node to act on chain events.
How VLS could have helped
- Not applicable: the vulnerability is in LND's Bitcoin wire parsing dependency (btcd), not in a signing request that VLS would validate.
- Independent chain view (detection only): VLS's txoo oracle receives blockchain data independently of btcd, so the signer would still see on-chain events (breaches, force-closes) even while LND is blind. However, VLS cannot broadcast protective transactions on its own.
Sources: GitHub advisory (CVE-2022-39389), NVD record (CVE-2022-39389)
POS app exposed LN node credentials (CVE-2022-32984)
BTCPay Server's public Point of Sale app embedded the store's xpub in the HTML source code. When using an external Lightning node, Lightning credentials were also exposed. An attacker could view source to extract them.
BTCPay Server's public Point of Sale app embedded the store's xpub in the HTML source code. When using an external Lightning node, Lightning credentials were also exposed. An attacker could view source to extract them.
- Impact: CVSS 7.5 HIGH. Xpub always leaked if POS was public. Lightning node credentials leaked when using an external (non-internal) node. No confirmed exploitation. Affects BTCPay v1.3.0-v1.5.3, fixed in v1.5.4.
- Bug class: sensitive data exposure in client-visible HTML (CWE-200).
- Spectrum fit: Entry point and escalation risk (credential exposure can become node control, which can become theft in hot-wallet models).
Background
Reported by Antoine Poinsot on May 28, 2022. Patched the same day in BTCPay Server v1.5.4. $5,000 bounty awarded (highest BTCPay had paid at the time). The vulnerability was introduced in v1.3.0 (October 29, 2021) and affected all versions through v1.5.3.
Attack
An attacker views the HTML source of a publicly exposed POS app. The store's xpub is always present in the source. If the store uses an external Lightning node (not the internal one), the Lightning node credentials are also embedded in the HTML. With these credentials, the attacker can access the Lightning node's API.
Results
Credential exposure can enable node compromise depending on deployment. Without VLS, this could lead directly to fund theft. Disclosed May 28, 2022; patched same day (v1.5.4). No confirmed exploitation.
Could VLS have stopped it?
Yes, for preventing fund loss. VLS cannot prevent the credential leak itself, but if leaked credentials lead to node compromise, VLS holds the signing keys separately. Stolen node access does not become stolen funds.
How VLS could have helped
- Key separation: VLS holds signing keys in a separate process. Leaked node credentials do not give the attacker access to signing keys.
- Velocity limits: even if the attacker gains node access, VLS caps total outgoing value per time window.
- Policy validation: VLS validates every signing request against protocol rules and policy bounds, rejecting anything out of spec.
Sources: NVD record (CVE-2022-32984), GitHub advisory
Common patterns
- Concurrency bugs become liquidity drains when users can trigger sends and the system does not have signer-enforced caps.
- Fee policy is a security boundary. On Lightning, routing fees are attacker-influencable value.
- Automation multiplies mistakes. A single ambiguity in payment status can become repeated payouts at machine speed.
- Web vulnerabilities often come first. If wallet authority sits inside the same blast radius, SSRF and similar bugs can become spend authority.
- Some failures are on-chain dynamics, not "key theft." Those still matter, and they still demand upgrades and strong ops response.
Acknowledgments
Nearly half the vulnerabilities in this index were discovered by Matt Morehouse, who has systematically audited LND, LDK, and Eclair through code review and fuzz testing. His work has made Lightning meaningfully safer. If you find this index useful, consider supporting his research.
Submit an incident
If you know of a real Lightning incident or a disclosed theft-capable vulnerability that belongs here, send:
- Primary source link (issue, postmortem, advisory, disclosure)
- What broke (bug class)
- Exploit path (what the attacker actually did)
- Impact (sats, downtime, affected versions)
- Fix and mitigation