Core Lightning Security Vulnerability: What Node Operators Must Do Now

If you run your own Lightning node on the Core Lightning software, exactly one task is due today: the update to version 26.06.7. Blockstream says it shipped this release on August 28, 2026. It closes several confirmed security vulnerabilities, and every older release has counted as unsupported since then. If you cannot update straight away, restart the node with the --offline switch instead. Either takes a few minutes, and either is more effective than the reaction most people reach for first: switching the machine off.

If you hold Bitcoin on an exchange, in an ordinary wallet or in an app without running a node yourself, the warning does not concern you directly. What is meant is the machine that manages your payment channels. Anyone who runs none has nothing to update. It is still worth a look: the episode shows how quickly a reported programming error turns into a deadline with a date, and it is repeating itself at short intervals right now.

What happened: Core Lightning confirms vulnerabilities and ships an emergency update

Core Lightning, CLN for short, is one of several software implementations of the Lightning network. The Lightning network is a second layer above the Bitcoin blockchain: two parties jointly lock an amount in a transaction and then settle between themselves as often as they like, without writing each payment into the blockchain individually. That locked connection is called a payment channel. The software that manages such a channel, monitors it and defends it in a dispute is called a node.

In late August the CLN team reported publicly that it had spent weeks working through an unusually high number of vulnerability reports generated with the help of AI tools. Several of them turned out to be genuine. The project's instruction on its own channel was terse and ran counter to first instinct: on no account shut the node down, restart it with --offline instead, because that switch blocks connections to other nodes and thereby closes the attack path.

Accounts of the exact sequence diverge, and that is worth mentioning, because the assessment of how long the holes stood open hangs on it. The trade outlet CryptoSlate dates the arrival of the first AI-generated reports to August 13 and an initial announcement by the project to August 23. Other reports, among them the one by TFTC, put the public warning at August 26 and speak of roughly ten days of lead time. The end of that chain is documented and undisputed: on August 28 the repaired release was available as a signed program file.

No losses have been reported so far

According to the state of reporting at the time of disclosure, there were no confirmed losses of funds and no known case in which anyone actually exploited one of the holes. That is a snapshot rather than an all-clear: the technical core of the flaws stays under wraps until mid-September, and only after that can anyone check independently how large the window really was.

Am I affected? The answer depends on who runs your node

The warning applies to the Core Lightning software. Other implementations of the Lightning network are not named in the project's notice. For you the question can be answered along a simple line:

• You run your own node on Core Lightning, on a small home server, a rented machine or a ready-made package such as Umbrel or Start9: you are the addressee. Update or --offline, today.
• You run your own node on a different implementation: this warning does not speak to you. General update discipline remains sensible anyway, because notices of this kind are currently arriving at short intervals.
• You use a Lightning wallet on your phone whose node someone else runs: then the duty to update lies with that provider, not with you. You can recognise such offerings by the fact that you never update any software and never pay for a channel opening yourself. Which wallet takes which route is sorted out in our comparison of software wallets.
• You hold Bitcoin only on an exchange or on a hardware device without using Lightning: the episode does not touch your balance.

This distinction matters more than it sounds. Warnings of this kind are quickly shortened into reports about the entire Lightning network. The circle of addressees is narrower: it covers the operators of one particular piece of software in one particular release.

Version 26.06.7: why older releases are no longer supported

The repaired release carries the number 26.06.7. The project's note on it is short and hard: releases before 26.06.7 are no longer supported. That does not mean an older node comes to a halt, because technically it keeps running. It means no more security repairs will arrive for those builds and that a known attack path stays open once the source code is published.

Precision pays off on the date, because the figures diverge slightly: Blockstream's blog entry is dated August 28, 2026, while in the Umbrel app store the same release carries August 29. The difference comes from the route through the package sources and changes nothing about the substance. What matters is the number, not the day.

The next regular release, numbered 26.09, is still planned for the end of September according to the project. Anyone moving to 26.06.7 now will therefore have to do it again in a few weeks. That argues for setting up the update route cleanly once instead of hunting for it each time.

Verifying the signature: how to establish that the program file comes from the project

The project's instruction, translated literally, reads: verify the signatures of the program files, install, restart. That order is not decoration. A signature is a cryptographic endorsement with which the developers confirm that a file comes from them unaltered. Without that check a security update would make the ideal bait: the user expects a new file, actively looks for it and installs it with elevated privileges.

In this case the reason is unusually concrete. Because the source code is being withheld, nobody can trace what sits inside the file during the first two weeks. The signature is therefore, for the time being, the only indication of provenance. Anyone updating through a ready-made package does not download it personally and leaves that check to the package provider, which shifts the task rather than removing it.

The second check comes later

As soon as the source code is out in the open, the software can be rebuilt from it and compared with the file that has been running for two weeks. If the two match, it is retrospectively documented that the signed file contained nothing other than what the project published. Anyone can take that second step, and the project's assurance rests on precisely that.

What the --offline switch on a Lightning node actually turns off

The --offline switch is a start-up option of the node software. The project describes its effect as follows: it removes the attack path by taking away any means for attackers to address the node at all, while the program keeps running and keeps reading the blockchain in order to detect attempted fraud.

In practice that means the node accepts no more connections from outside and opens none itself. You can neither send nor receive payments, and other people's routed payments no longer pass through you. Everything happening on the blockchain, by contrast, your node still sees, and it can react to it.

The price is therefore stated plainly: the availability of your channels ends for as long as the switch is set. For a private node that is an inconvenience. For a node through which other people's payments regularly run, it is a loss of income. CryptoSlate points out that enough delayed updates and shut-down nodes could noticeably reduce routing capacity in parts of the network.

Why switching the machine off is worse than the offline mode

Here lies the point at which well-meant advice does damage. The obvious reaction to a security warning is: turn the device off. On a Lightning node that is the worse of two options, and the reason lies in the construction of payment channels.

A payment channel is secured by the last jointly signed balance. Either side can close the channel unilaterally at any time via the blockchain, which is known as a force close. If a counterparty submits an old balance more favourable to itself in the process, that is an attempted fraud. A challenge period protects against it: within an agreed window the injured side may submit a penalty transaction and in that case receives the entire contents of the channel.

That period runs in block time rather than calendar time, and it runs regardless of whether your machine is on. A node that has been switched off does not read the blockchain, does not notice the attempted fraud and misses the deadline. That is exactly what the project means by saying a shut-down node cannot do this job. The offline mode, by contrast, leaves the program running and the chain being read and takes away only the connections.

Anyone using a watchtower has a buffer

A watchtower is a monitoring service that observes the blockchain on your behalf and submits the penalty transaction in the event of fraud while your own node sleeps. Anyone who has set up such a service is better placed during a downtime. You should not rely on it, because many private nodes run without one, and setting it up is no incidental step.

Umbrel and Start9: how the security update reaches one-click nodes

Many private nodes run on ready-made packages with an interface rather than on the command line. There you will not find --offline as a button in the dashboard; it is a start-up option of the application. The route through the app store therefore has a story of its own here, and it can be read off the Umbrel entry.

An interim release numbered 26.06.6-patch.1 appeared there first, on August 27. Its note explained that the node kept running and kept watching the Bitcoin blockchain, but for the time being could not send, receive or forward Lightning payments. The instruction attached to it was clear: leave Core Lightning running and do not remove it, the next update would appear as usual once the repair was ready.

On August 29 came 26.06.7, with the note that this was an important security update and that the node would automatically reconnect to the Lightning network afterwards. For users of such packages that means two things. The offline mode may already have arrived automatically, without anyone flipping a switch. And full functionality returns only with the second update. If you have been wondering for a few days why a payment will not go through, here is the explanation.

Source code only on September 11: what lies behind the embargo

An embargo in this context is an agreed blackout period during which the technical details of a vulnerability are not published. That is customary between reporter and vendor ahead of the repair. Here the case is different: the repair has already shipped, and the source code nevertheless stays under wraps until September 11, 2026, fourteen days after delivery.

The reasoning is practical. From a published repair the flaw it fixes can be reverse engineered. Whoever holds the source code sees which lines have changed and often knows sooner than the defender where the attack begins. TFTC's report attributes this reasoning to CLN lead developer Christian Decker: the technical details are being held back precisely in order to stop attackers from building a working exploit out of them.

Against that it can be argued that open-source software derives its very verifiability from the fact that anyone can read along. For two weeks a file is running on the nodes whose contents nobody outside the project can follow. Both sides have an argument, and both refer to the same period. The dispute can be settled only after September 11, when a comparison between the source code and the delivered file becomes possible.

AI-generated vulnerability reports: the pattern behind the emergency

The trigger of this episode is as remarkable as its course. The flaws did not come out of a planned audit. They arrived as a flood of reports generated with AI tools. Part of it was waste, part of it was genuine, and telling the two apart cost the project weeks.

For software maintained by volunteers that is a new burden. Whoever receives reports has to examine every single one, because a genuine finding overlooked would be the most expensive mistake of all. At the same time the effort on the side of those producing such reports falls towards zero. The balance between attack and defence shifts noticeably as a result.

Core Lightning is no isolated case in this. TFTC places the episode in a series and names August 3 as an earlier example, when the swap service Boltz suspended its swaps citing AI-assisted attacks. Anyone following recent weeks knows the pattern from the hardware corner too: we recently described how BitBox02 closed three security vulnerabilities with firmware 9.26.5 and why, with Coldcard, the old seed should not be reused in every case after a firmware update. How quickly you install a security update has thereby moved from a fringe topic to a routine.

What the incident means for the way you store Bitcoin

An episode like this does not imply that self-custody is a mistake. What follows from it is a division that pays off independently of this case: a Lightning node is a device permanently attached to the network, accepting connections from strangers and needing keys while it operates. Such a system remains a hot system, however carefully it is maintained.

From that follows a plain split of your holdings. What belongs in the payment channel is the amount you actually need for payments. Everything beyond that belongs in storage whose keys never sit on a machine with a network connection, of the kind our comparison of hardware wallets describes. The homework that goes with it is backing up the recovery words, on which we have gathered what steel, passphrase and multisig really achieve.

The second conclusion concerns speed. Between the warning and the repaired release lay roughly two days according to the available figures. Anyone who hears nothing of the warning in that time, because they follow neither the project nor their package source, drops out of the window. A notification route that has been set up belongs to the equipment of self-run infrastructure rather than to its comforts.

Checking the Core Lightning vulnerability: what to take away

1. Check your node's version today and update to 26.06.7. If that is not possible right away, restart with --offline and catch up on the update afterwards. If you are not sure at all which software sits behind your Lightning payment, the comparison of software wallets clears that up.
2. Separate hot and cold holdings cleanly. What you need for payments stays in the channel, the rest moves to storage without a permanent network connection. Which devices manage that is set out in the hardware wallet comparison.
3. Put September 11 on your list. That is the day the source code is published, and only then can the file that has been running be checked and the reach of the vulnerabilities be judged. Tools for keeping holdings and events in view are collected in our overview of analytics platforms.

The solid evidence sits in the project's notice on release 26.06.7 (Blockstream, August 28, 2026) and in the Umbrel app store entry with the notes on both updates (Umbrel App Store).

(As of August 30, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)