Core Lightning Warns of Attacks on Unpatched Bitcoin Nodes

Core Lightning 26.06.8 patches channel-loss bugs

The 26.06.8 release contains fixes for responsibly reported vulnerabilities. Its publication date is September 22, although the corresponding changelog section is dated September 19. The October alert is a subsequent warning about targeting, rather than a new release announcement.

Core Lightning runs Lightning payment channels, where participants exchange updated balances without recording every payment on Bitcoin’s blockchain. Closing a channel brings the relevant balance state back on-chain. Correctly tracking which state remains valid is essential to protecting the money committed to it.

The version-specific changelog identifies a unilateral-close bug after a splice that could broadcast a revoked commitment, losing channel funds to a penalty. A splice changes a channel’s funding while preserving its operation. A revoked commitment represents a superseded balance state.

Under Lightning’s on-chain rules, a counterparty can claim funds from a revoked commitment through the penalty mechanism. That protection against publishing old balances can become a loss mechanism if software publishes the wrong state itself.

Other fixes address a crafted payment-error response that could crash the sender’s node and unauthenticated requests that could exhaust memory in the REST plugin. These are different failure modes. The warning does not establish which one attackers are using, or that every patched flaw enables theft.

The release keeps dual funding experimental and discourages zero-confirmation channels with untrusted peers. Its fixes are available without a source-code embargo, although maintainers temporarily withheld some tests to make reverse engineering harder while operators upgraded.

The issue is also distinct from Bitcoin Core’s PSBT signing safeguard. That repair concerns what a wallet signature authorizes. The current warning concerns software managing Lightning channels and cannot be used to imply a new flaw in Bitcoin’s base consensus rules.

Three splice outputs total 3,043,561 sats

An October 1 Start9 Community report describes three remote-initiated splices followed by on-chain closures and outputs the operator could not resolve. The post identifies 1,229,771, 1,229,171 and 584,619 sats and reports running the packaged version 26.06.8:3.

Daily Crypto Briefs checked the named outputs and their subsequent spending transactions. The first, second and third spends select the revocation branch of their channel scripts, consistent with penalty collection. The input amounts sum to the reported 3,043,561 sats, before spending fees.

Those records substantiate the amounts and spending path. They do not independently prove that the poster owned those balances, identify an attacker, establish the installed version when the channels failed, or attribute the transactions to a specific software flaw. The post’s statement that funds had not been moved also needs reconciliation with the spending records.

The packaged-version claim does not establish that 26.06.8 is ineffective. The public evidence leaves open the timing of the upgrade and the original failure, as well as the cause of the channel state. A maintainer diagnosis would be needed to connect those details.

The loss-impact check also searched for victim reports, transaction evidence and estimates from TRM Labs, Chainalysis and Elliptic. No corroborated aggregate loss assessment tied to the October alert was identified. That evidentiary limit should not be described as proof of zero losses.

Confirmed loss figures from Coldcard’s separate theft waves cannot be transferred to this incident. The hardware-wallet seed issue involved different software, exposure and victim evidence.

Core Lightning operators urged to verify upgrades

The immediate instruction is to move beyond the versions named in the warning. Operators can check the running process with lightning-cli getinfo; the official command documentation includes a version field. Checking that process is more useful than assuming a downloaded package has already taken effect.

Core Lightning’s installation documentation distinguishes binaries, Docker images and third-party service packages. Operators using a managed interface need to follow its distribution-specific update instructions and confirm the restarted service reports the intended build.

The August security cycle provides relevant context. Blockstream published 26.06.7 on August 28 and delayed the matching source for 14 days. That older upgrade advice has been overtaken by the October warning naming 26.06.7 itself among versions that should be replaced.

The older release record also documents a distribution mistake: between August 28 at 16:04 UTC and September 1, some Docker tags served images that reported 26.06.7 but lacked its fixes. Maintainers replaced those images and published correct digests. This is historical evidence of a package problem, not an instruction to reinstall that superseded release.

It illustrates why operators should check both the running version and the provenance of the package they installed. Neither a version label nor a patch announcement establishes how many nodes are protected. The October warning supplies no adoption percentage, so the share of exposed Core Lightning infrastructure cannot be calculated from it.

Lightning infrastructure is also drawing new payment demand, including Utexo’s planned USDT Lightning access. New applications still depend on the maintenance and correct operation of their underlying node software; the announcement does not identify Utexo as affected.

Alternative.me showed 70, classified as Greed, against 65 the previous day. This Bitcoin-focused market sentiment measure does not assess node security.

The next material evidence would be a maintainer account of the targeted flaw, independently attributed losses and a diagnosis of reported channel failures. Until then, the established operational development is an urgent upgrade warning, with the scale and outcome of the reported attacks still unresolved.