Attackers Are Hunting Unpatched Lightning Nodes. Run the CLN Checklist

If you run a Core Lightning node, stop reading in a moment and check your version. On October 1 the project posted an urgent security update saying it had received reports of attackers targeting nodes running v26.06.7 or earlier, and urging operators to upgrade immediately. That sentence is doing a lot of work. It does not say which vulnerability is being used. It does not say whether any node has lost funds. What it does tell you is that the window between "we fixed it" and "they are exploiting it" has closed, and that anyone still running an older release is now the low-hanging fruit.

How September built up to this

The warning did not come out of nowhere. On August 13, the Core Lightning team said it had been flooded with AI-generated vulnerability reports, and that triage had confirmed multiple genuine vulnerabilities among the noise. Their advice at the time was to upgrade or run the daemon with the --offline flag. Two weeks later, on August 28, version 26.06.7 shipped with security fixes, with the details withheld from the public until September 11. The 26.04 branch was declared end of life at the same time.

Then the problem refused to stay closed. On September 15 and 16 the team warned that an unresolved problem around experimental features remained. On September 22, version 26.06.8 arrived, patching a set of responsibly disclosed vulnerabilities credited to the Bitcoin Red Team and a dozen independent researchers. Among them: a bug that could crash a node, a memory exhaustion issue in the REST interface, and a channel-closing bug that could trigger a penalty transaction and cost an operator actual funds. Separately, the 25.09 branch received a backport in September, PR #8525, fixing a denial-of-service in the BOLT 8 handshake caused by oversized pong messages, as documented in Bitcoin Optech newsletter #421.

What Core Lightning has not said

Now read this part twice. Core Lightning has not disclosed which vulnerability the attackers are using. It has not confirmed any losses, and no victim has come forward publicly. There are no CVEs assigned to any of this; Lightning bugs are tracked through project advisories and Bitcoin Optech rather than the CVE system, so do not expect a numbered entry to search for. That uncertainty is exactly why the threshold matters: you cannot evaluate whether your node is exposed when nobody will say what the attack looks like. The only safe assumption is that anything at 26.06.7 or earlier, and anything on the dead 26.04 branch, is fair game.

The checklist, in order

First, establish what you are actually running. lightningd --version tells you before you touch anything else, and the getinfo RPC call tells you again from inside a running daemon, which matters because the binary on disk and the daemon in memory are not always the same. If you see 26.06.8 or later, you are on the patched side of the line. If you see 26.06.7 or anything lower, or you are on the 26.04 branch, you are inside the warning window and should keep going.

Second, get the release the right way. Download the signed release tarball from the official Core Lightning repository, verify the Git tag with git tag -v, and check the SHA-256 checksum of the tarball against the published value. Verifying signatures takes a minute and it is the difference between installing a fix and installing whatever the mirror you hit was serving. This matters more than usual right now, because attackers who know everyone is rushing to upgrade will be ready for people who download carelessly.

Third, a detail that trips people up: you do not need to stop the daemon to protect yourself if you cannot upgrade immediately. Running --offline disconnects the node from the network while keeping the daemon and your channels intact, which is what the project itself advised on August 13. Stopping lightningd entirely risks missing channel obligations you would rather not miss. Offline mode is the safer pause button.

Fourth, close the side doors. The experimental-features problem the team flagged in mid-September was still open after the first fix release, and experimental code is where the bugs keep living. Unless you specifically need an experimental feature, disable it. The same logic applies to the REST interface: one of the September 22 fixes was a memory exhaustion bug in exactly that interface. If you run it, bind it to localhost so only local processes can reach it. A REST socket reachable from the wider network is an invitation.

Fifth, verify that the fix actually took. After upgrading, run lightningd --version again, or call getinfo against the restarted daemon. A surprising number of "upgrades" fail silently: the package manager rebuilt one binary while systemd restarted another, or the daemon kept running from the old installation directory. The version check after the restart is the step that catches it, and it costs you five seconds.

The bigger picture

Step back and the September story is almost a parable about software security in 2026. A wave of AI-generated reports buried real vulnerabilities in noise, the maintainers burned triage time separating signal from slop, and by the time the fixes were sequenced and released, real attackers were already moving. The defenders were drowning in fake reports while the actual exploits went to work. Everyone running a Lightning node is downstream of that fight whether they read a single changelog or not.

The checklist is deliberately boring, and that is the point. Check the version, verify the download, upgrade, use --offline if you must wait, kill the experimental features, keep REST on localhost, and check the version again. A Lightning node holds funds that can be penalized out of existence if its software misbehaves during a channel close. Running a patched, verified release is the minimum the situation demands. The attackers have already done their homework; make sure you have done yours.

Sources: Core_LN on X, urgent security update (Oct 2026); crypto.news, "Bitcoin Lightning security alert"; Bitcoin Optech newsletter #421; The Bitcoin Manual, "CLN's AI-triggered security crisis"; Cointelegraph via TradingView, "Core Lightning warns". This article is for education only and is not security or legal advice.