Core Lightning Warns Attackers Target Bitcoin (BTC) Nodes on Version 26.06.7 or Earlier

Lightning Nodes Under Active Attack

Core Lightning, an open-source implementation of the blockchain node software behind the Lightning Network, warned operators on Friday that attackers are targeting nodes running version 26.06.7 or earlier, and pointed them to version 26.06.8, which has been available since Sept. 22. The team's official post tells anyone still on an older build to move to the latest release without delay. The warning matters because of where the funds sit: the Lightning Network is a layer-2 payment system built on Bitcoin (BTC), carrying fast, low-cost transfers that settle off the main chain, along with much of the payment activity now grouped under Bitcoin DeFi. For spot holders tracking the Bitcoin price, the blast radius does not reach coins on the base chain, which is secured by proof of work; it runs through payment channels instead. Only operators who run their own Core Lightning nodes need to install the update themselves. The bugs behind the warning can cost operators money in two ways: in the worst case, a faulty channel close hands a node's funds to the other side, while other bugs let attackers crash nodes and knock them offline. The episode is the latest strain on Bitcoin security at the second layer this quarter. Most people who use Lightning through a wallet app never run a node, so the app provider handles the upgrade. Custodial wallets hold coins on behalf of users; if such a provider's node loses funds, the provider takes the first hit, and repayment depends on its own terms, because Lightning carries no deposit insurance. Users of self-custodial wallets keep control of their channel balance, though a crashed provider node could temporarily block their payments.

What Version 26.06.8 Changed

The patch has a longer paper trail. On Sept. 16 the Core Lightning team said it was investigating reports of a potential issue affecting experimental features that could impact user funds, and about six days later it shipped version 26.06.8. The release notes describe fixes for vulnerabilities responsibly reported by a number of sources and credit the Bitcoin (BTC) Red Team alongside 12 other named individuals and groups, plus anonymous reporters. The changelog itemizes the exposed surfaces: flaws that could crash senders' nodes, requests that could exhaust memory in the REST interface, and a channel-closing bug that could cost users money to a penalty. Severity varies by bug. A crash takes a node offline until its operator intervenes; the channel-closing flaw is the one that can move money, and it is the case the urgency leans on. The developers also left out some tests deliberately, a step meant to make reverse-engineering harder while operators upgraded. For an operator, the sequence the release implies is short: identify the running version, pull the latest build from the project, and restart so channels resume under patched code. The Sept. 22 release, in other words, was written for exactly the scenario now playing out. August set the backdrop. The team spent that month working through a high volume of AI-generated Common Vulnerabilities and Exposures (CVE) reports, then shipped version 26.06.7 two days after confirming those flaws. In the same stretch, attackers stole funds through a vulnerability in BTCPay Server, an open-source Bitcoin (BTC) payment processor, that exposed Lightning credentials. The developers have not said which flaw the current attackers are exploiting.

The Upgrade Window Keeps Shrinking

COINOTAG's reading starts from the primary record: the Core Lightning post confirms two facts, active targeting and an upgrade instruction, and it names no victim, no amount and no exploited flaw. That silence is the open edge of this story. Nodes keep keys online to route payments in real time, which is exactly why outdated software gives attackers a direct path to channel funds. The record also fixes one interval: attacks surfaced about 10 days after the patch shipped. If AI-assisted bug discovery keeps compressing that gap, the binding constraint stops being the quality of the fix and becomes how fast voluntary node operators install it.