Three separate teams that build the software running Bitcoin’s Lightning Network shipped critical security patches inside the same two-week stretch this month. Lightning Development Kit (LDK), Core Lightning (CLN), and ACINQ’s Eclair each disclosed bugs that could have let an attacker divert funds, crash a node, or strand a channel balance. As of September 23, 2026, none of the three has a confirmed loss attached to it. That’s the headline most coverage buried: a payments network carrying somewhere between $410 million and $485 million in public capacity had three separate near-misses in the space of 15 days, and the patches beat the exploits to market.
The pattern matters beyond Bitcoin circles. Lightning is one of the oldest production payment networks built on cryptographic state channels, and its implementations are maintained by small, independent teams rather than one company. When three of them find serious bugs at roughly the same time, it raises a fair question: is this a coincidence of increased scrutiny, or a sign the underlying protocol has aged into a phase where its edge cases are finally getting found? Both, most likely. Here’s what actually happened, implementation by implementation, and what it means for anyone running a Bitcoin Lightning node or building on top of one.
The September Patch Wave: Three Bugs, Three Teams, One Pattern
The Lightning Development Kit team shipped LDK v0.2.6 on September 9, 2026. Nine days later, on September 14, ACINQ released Eclair 0.14.3. Core Lightning’s fixes landed across two release channels: a denial-of-service patch that shipped in version 25.09, and a follow-up security release, 26.06.7, for operators still on the prior major branch. In between, on September 15, Core Lightning’s maintainers posted a separate warning telling node runners to disable experimental features entirely while they investigated a distinct issue that could put funds at risk. That fourth item, unlike the other three, was still open at time of publication.
None of the four disclosures carries a CVE number as of this writing. That’s not unusual for Lightning-specific bugs, which tend to get tracked through each project’s own security advisories and the Bitcoin Optech newsletter rather than the CVE database, but it does make the scope harder to quantify from the outside. What’s consistent across all three implementations is the shape of the problem: each bug lives in the logic that handles channel state changes, mid-life fee negotiation, or graceful shutdown and restart, not in the base cryptography. Lightning’s signature scheme and onion routing held up fine. The plumbing around it is where the cracks showed.
LDK v0.2.6: A Splice Fee Flaw and a Bug That Bricked Restarts
LDK, maintained by Spiral and used as the toolkit underneath products including Breez’s SDK and Cash App’s Lightning integration, patched two distinct problems in v0.2.6. The first was a splice fee allocation flaw: under specific conditions, a malicious channel peer could manipulate the fee accounting during a splice (Lightning’s mechanism for resizing a channel without closing it) to redirect a portion of the counterparty’s funds toward itself. The second was a state-loading bug tied to duplicate payment hashes inside the ChannelManager object, the component that tracks a node’s channel state on disk. Hit that bug, and a node could fail to reload its own saved state after a shutdown, effectively locking an operator out of their own channel until manual recovery.
The LDK team said neither issue produced a reported loss or known exploitation before the patch shipped. That framing matters: this was a responsible-disclosure outcome, not an incident report. Any application built on LDK’s toolkit was technically exposed until it upgraded, which is the uncomfortable part of building on a shared library. A bug in the underlying kit becomes every downstream wallet’s problem simultaneously, and the fix only helps once each app actually ships the update to users.
Core Lightning: A Memory-Exhaustion Bug and an Unfinished Investigation
Core Lightning’s fix addressed a denial-of-service path that developer Erick Cestari flagged through a responsible disclosure posted to the Delving Bitcoin forum, according to Bitcoin Optech Newsletter #421. The bug affected CLN versions before 25.09: an attacker could complete the BOLT 8 encrypted handshake with a target node (no open payment channel required), send ping messages that requested an oversized pong response, then simply stop reading from the TCP socket. The victim node would keep buffering the unread response until it ran out of memory and crashed. The fix landed in pull request #8525 and shipped in the 25.09 release, with a parallel 26.06.7 build backporting the same protection to nodes still on the earlier major version.
What’s still unresolved is the September 15 warning. Core Lightning’s team told operators running experimental features to turn them off while they chased down a separate issue that could put funds at risk, without specifying, publicly, exactly which feature or how. That’s a meaningfully different posture than the other three disclosures: it’s a live investigation with the fix not yet in hand, rather than a patch note describing a closed bug. Anyone running CLN with experimental flags enabled should treat that advisory as current until Core Lightning’s maintainers post a resolution.
ACINQ Eclair 0.14.3: Closing Three Doors on Channel Manipulation
Eclair, the implementation ACINQ built and the one underneath its own Phoenix wallet, got the broadest patch of the three. Version 0.14.3, released September 14, fixed three separate peer-triggered vulnerabilities touching channel closures, splicing, and on-the-fly channel funding. The common thread was adversarial fee proposals and state manipulation: a peer could exploit the bugs to push local balances toward miners as fees, or to strand funds mid-transition during a cooperative close, a splice, or an on-the-fly funding event. As with LDK and CLN, no confirmed dollar loss has surfaced, and no CVE number has been assigned to the Eclair issues.
The Eclair patches are worth reading alongside LDK’s splice bug rather than in isolation. Splicing, the feature that lets users resize a channel without an on-chain close and reopen, is relatively new across Lightning implementations, and two of the three teams found fee-related bugs in their splice-handling code within the same month. That’s a signal the splicing code path, still one of the newer additions to the protocol stack, needs more adversarial testing before it’s treated as mature.
Lightning Implementation Comparison: LDK vs Core Lightning vs Eclair
The three projects aren’t interchangeable. They’re written by different teams, in different languages, with different downstream users, which is part of why a bad month for one doesn’t automatically mean a bad month for the others. Here’s how the September patches stack up side by side.
| Implementation | Patched Version | Release Date | Vulnerability Type | Reported Losses | Known Downstream Users |
|---|---|---|---|---|---|
| Lightning Development Kit (LDK) | v0.2.6 | Sept. 9, 2026 | Splice fee diversion; ChannelManager restart failure | None reported | Breez SDK, Cash App Lightning |
| Core Lightning (CLN) | 25.09 / 26.06.7 | Sept. 4-9, 2026 | Memory-exhaustion DoS via oversized pong requests | None reported | Blockstream infrastructure, routing nodes, LSPs |
| ACINQ Eclair | 0.14.3 | Sept. 14, 2026 | Adversarial fee proposals during close, splice, on-the-fly funding | None reported | Phoenix Wallet |
| Core Lightning (separate advisory) | Unresolved | Warning issued Sept. 15, 2026 | Unspecified, tied to experimental features | Investigation ongoing | Nodes running experimental flags |
LDK’s advantage is distribution: it’s a Rust library other companies embed into their own products, which means a single patch can protect many wallets at once, assuming they update promptly. Core Lightning’s plugin architecture and C codebase give it flexibility that also widens its experimental-feature surface, which is exactly where the unresolved September 15 warning sits. Eclair’s scope is narrower since ACINQ controls both the implementation and its flagship wallet, but that also means a bug in Eclair hits ACINQ’s own users directly rather than through an intermediary that might patch on a different schedule.
Why Nobody Lost Money (This Time)
Every one of these four disclosures followed the same script: a researcher or the maintaining team found the bug, reported it privately, and a patch shipped before public exploitation. That’s responsible disclosure working close to as designed. It’s worth separating this pattern from the DeFi side of crypto security, where losses tend to get discovered only after an attacker has already drained funds. Lightning’s smaller, more concentrated developer community, and the fact that exploiting most of these bugs required either running a malicious peer node or timing an attack against a specific channel operation, gave defenders a narrower and more visible attack surface to monitor.
That’s a genuinely different threat model from the one dominating broader crypto security news this year. According to a report covered on this site, compromised private keys overtook smart contract code flaws as the costliest attack vector in DeFi through the first eight months of 2026, with losses topping $1.3 billion. The September Lightning bugs sit on the opposite end of that spectrum: pure code flaws in protocol logic, caught and fixed before a key or a signature was ever compromised. Both categories of risk are real. They just require different defenses, and conflating them tends to produce bad advice.
Lightning Network by the Numbers: A Shrinking, Consolidating Footprint
The vulnerability wave lands on a network that’s smaller today than it was at its peak. Public node counts have fallen from roughly 20,700 at their 2022 high to somewhere between 17,000 and 17,400 reachable nodes as of September 2026, according to mempool.space-based crawls referenced in Spark’s mid-2026 state-of-the-network research. Public channel capacity has swung between roughly 3,700 and 5,600 BTC over the course of the year, with a May 2026 snapshot putting it at approximately 4,898 BTC across about 41,080 channels. At Bitcoin’s September 23, 2026 price of roughly $86,600, that range works out to somewhere between $410 million and $485 million in visible, on-chain-anchored capacity, a small fraction of Bitcoin’s roughly $1.74 trillion total market capitalization.
| Metric | 2022 Peak | September 2026 | Change |
|---|---|---|---|
| Public reachable nodes | ~20,700 | ~17,000-17,400 | Down roughly 16-18% |
| Public channel count | N/A (not directly comparable) | ~41,080 | Consolidating into fewer, larger channels |
| Public capacity (BTC) | N/A (era of lower BTC price) | ~4,898 (range 3,700-5,600 over 2026) | Volatile, not a clean trend |
| Public capacity (USD, at time-of-period BTC price) | N/A | ~$410M-$485M | Small relative to BTC’s ~$1.74T market cap |
The falling node count doesn’t necessarily mean Lightning usage is shrinking. It more likely reflects consolidation: fewer hobbyist nodes, more capacity concentrated in professional routing operators and liquidity providers who can afford to run well-connected, well-capitalized channels. That consolidation cuts both ways for security. Fewer, better-resourced operators are generally faster to apply patches like the ones released this month. But it also means an exploit against a major routing node or a widely used wallet’s backend carries more concentrated risk than it would have in a more evenly distributed network.
Historical Context: Lightning’s Track Record on Disclosed Vulnerabilities
This isn’t Lightning’s first vulnerability cycle, and the comparison to past incidents is useful for judging how seriously to take this one. The most cited prior case is the replacement-cycling attack class, first publicly flagged in developer discussions in December 2022 by researcher Antoine Riard. That class of bug, eventually catalogued as CVE-2023-40231 through CVE-2023-40234, exploited how Bitcoin’s transaction replacement rules interact with Lightning’s HTLC (hashed timelock contract) settlement process. Major implementations shipped mitigations after the disclosure, and no verified real-world theft has been publicly linked to that attack class since the patches went out, a track record the September 2026 bugs are on pace to match so far.
This site has covered two other Lightning-specific incidents that offer contrast. BTCPay Server’s Lightning macaroon bug showed how a flaw in credential handling, rather than the core protocol, could drain funds from merchant nodes, and that one was patched within a day of disclosure. Core Lightning’s earlier 14-day lockdown incident affected roughly 3,750 BTC worth of channel liquidity during an extended precautionary freeze, a reminder that even a non-exploited bug can impose real costs through downtime rather than theft. Set against those two episodes, September’s patch wave is closer in severity to the 2022-2023 replacement-cycling cycle: multiple disclosed bugs, no confirmed losses, and a response measured in days rather than weeks.
Channel Jamming: The Known Problem Nobody Has Fully Solved
It’s worth naming the Lightning vulnerability that didn’t get patched this month, because it’s arguably the network’s longest-running unsolved issue. Channel jamming is a denial-of-service technique where an attacker routes payments to themselves through a target’s channels and deliberately withholds confirmation, tying up liquidity and HTLC slots (capped at 483 per channel direction under current protocol rules) until the payment’s timelock expires. Unlike the September bugs, which were discrete, patchable code flaws, jamming is closer to a structural tradeoff in how Lightning routes payments, and no implementation has shipped a complete fix as of late 2026. It’s a useful baseline for judging the new bugs: those got fixed in days because they were bugs. Jamming persists because it’s closer to a design constraint.
Market Impact: A Reputational Risk More Than a Financial One
Given the dollar figures involved, roughly half a billion in public capacity against a Bitcoin market cap in the trillions, the September patch wave was never going to move Bitcoin’s price. Its real impact is reputational and operational, concentrated in the businesses that depend on Lightning working reliably: exchanges offering instant BTC deposits and withdrawals, wallet providers marketing Lightning as a fast-payment rail, and merchant processors that rely on Lightning settlement. Three disclosures inside two weeks, even with zero losses, is the kind of cluster that shows up in enterprise risk reviews and vendor security questionnaires well before it shows up in a price chart.
The more durable effect is likely to be process-level. Expect Lightning implementation teams to lean harder into coordinated disclosure windows, cross-implementation security audits, and, potentially, a push to formally assign CVE numbers to Lightning-specific bugs so the severity is easier to track from outside the developer community. None of the three disclosures this month went through the CVE process, which made it genuinely harder for wallet providers and businesses to triage their own exposure quickly.
What Wallets and Companies Are Actually Exposed
Exposure runs through which implementation sits underneath a given product, and that mapping isn’t always visible to end users. Phoenix Wallet, built and maintained by ACINQ, runs directly on Eclair, so its users were exposed to the 0.14.3 bugs until ACINQ shipped and users updated. Breez’s SDK and Cash App’s Lightning integration are both built on LDK, meaning the splice fee and restart bugs were, in principle, present anywhere those products embedded the affected LDK version before September 9. Core Lightning’s user base skews toward routing node operators, liquidity service providers, and infrastructure run by companies like Blockstream rather than a single consumer-facing wallet, which is part of why its September 15 warning read more like an operator alert than a consumer one.
That distribution pattern is itself worth flagging: a bug in a widely embedded toolkit like LDK has a larger, harder-to-map blast radius than a bug in a self-contained implementation like Eclair, even when the two bugs are comparable in technical severity. Anyone running a node built on any of the three should confirm their version against the fixed release before treating the incident as closed.
How to Check If Your Node Needs the Patch
Checking your running version takes under a minute on any of the three implementations. Run the relevant command below and compare the output against the fixed versions in the table above.
# Core Lightning
lightning-cli getinfo | grep version
# Eclair (via its API)
curl -s -u ":your-eclair-password" http://localhost:8080/getinfo | grep version
# LDK-based apps typically expose version through the app itself,
# not a standalone CLI -- check your wallet's settings or release notesIf your node reports a version older than CLN 25.09/26.06.7 or Eclair 0.14.3, update before reopening any channels that were closed or spliced during the vulnerability window. LDK-based app users should check their wallet provider’s release notes directly, since the library itself doesn’t expose a simple CLI version check the way node-facing implementations do.
Predictions: Where Lightning Security Goes From Here
- Expect at least one of the three implementations to formally request CVE assignments for these bugs within the next quarter, driven by enterprise wallet partners who need standardized severity scoring for their own security reviews.
- Splice-related code will likely see a dedicated audit push across at least two implementations before the end of 2026, given that two of the three September bugs touched splicing logic.
- The unresolved Core Lightning experimental-features warning from September 15 is likely to resolve into either a disabled-by-default posture for those features or a narrowly scoped patch within the next four to six weeks, based on how quickly the team moved on the DoS fix.
- Node counts will likely keep drifting down through the rest of 2026 as consolidation continues, even as total capacity stays roughly flat or grows, following the pattern already visible in 2026’s data.
- Watch for at least one major wallet provider to publicize a faster patch-adoption SLA or automatic-update commitment in response to this cluster, positioning it as a competitive trust signal against rivals.
The Takeaway for Node Operators and Businesses
Three critical bugs across three implementations in two weeks sounds alarming in isolation, and it should prompt every operator to check their version immediately. But the more useful read is that Lightning’s disclosure-and-patch machinery worked close to as intended in three of the four cases, and the fourth is still being actively worked rather than sitting unaddressed. That’s a meaningfully better outcome than a comparable cluster of bugs discovered only after an attacker had already found them first. The network is smaller and more concentrated than it was at its 2022 peak, which cuts patch-adoption speed in a good direction even as it raises the stakes of any single unpatched node. For anyone building on or depending on Lightning, the practical move is simple: update now, watch the still-open Core Lightning advisory, and treat a missing CVE number as a gap in tooling rather than a reason to discount the risk.
Frequently Asked Questions
Was any Bitcoin actually stolen in the September 2026 Lightning bugs?
No. As of September 23, 2026, none of the four disclosures across LDK, Core Lightning, and Eclair has a confirmed loss attached to it. All three patched bugs were fixed before public reports of exploitation, and the fourth, Core Lightning’s September 15 warning, remains under investigation.
What’s the difference between LDK, Core Lightning, and Eclair?
All three are independent software implementations of the Lightning Network protocol. LDK is a Rust library other companies embed into their own wallets and apps, such as Breez and Cash App. Core Lightning is a standalone node implementation in C, popular with routing operators and infrastructure providers like Blockstream. Eclair is ACINQ’s implementation, used both by professional operators and by ACINQ’s own Phoenix wallet.
Do I need to close my Lightning channels because of this?
No. The recommended action is to update to the patched version, not to close channels. Closing and reopening channels involves on-chain fees and, during the vulnerability window, may not have added meaningful protection since the bugs required a malicious counterparty to actively exploit specific operations.
Why don’t these Lightning bugs have CVE numbers?
Lightning implementation teams have historically tracked vulnerabilities through their own security advisories and community channels like Bitcoin Optech’s newsletter rather than the formal CVE database. That’s different from, say, the CVE-2023-40231 through CVE-2023-40234 series assigned to the 2022-2023 replacement-cycling bugs, which did go through the CVE process.
How big is the Lightning Network in 2026?
Public data points to roughly 17,000-17,400 reachable nodes and public channel capacity that has ranged between about 3,700 and 5,600 BTC over the course of 2026, with a May 2026 snapshot at approximately 4,898 BTC across roughly 41,080 channels. At Bitcoin’s September 23, 2026 price near $86,600, that’s somewhere between $410 million and $485 million in visible capacity.
Is channel jamming related to these September bugs?
No, they’re distinct issues. Channel jamming is a known, long-running denial-of-service technique tied to how Lightning routes payments and HTLC slot limits, and it remains unresolved across the network in 2026. The September bugs were discrete, patchable code flaws in specific implementations, unrelated to jamming.
Which wallets were affected by the LDK bugs?
Products built on LDK, including Breez’s SDK and Cash App’s Lightning integration, were technically exposed to the splice fee and restart bugs until they updated to the patched LDK version released September 9, 2026. Individual wallet providers control when they ship that update to their own users, so exposure duration varied by product.
Should businesses stop offering Lightning payments because of this?
Nothing in the September disclosures suggests that. All three patched bugs were caught and fixed through responsible disclosure before exploitation, which is closer to the security process working than failing. Businesses should confirm their infrastructure runs a patched version and continue watching Core Lightning’s still-open experimental-features advisory.
