I was halfway through a coffee when the wording of the alert landed. Not a vague “please update when you can.” An urgent note aimed at anyone still running Core Lightning on version 26.06.7 or anything older, with reports that attackers are already looking for those boxes. If you route payments, hold channel capacity, or simply keep a home node humming in a closet, that sentence should interrupt your morning. Lightning is fast when it works. It is also unforgiving when a node is behind on patches and a counterparty, or a stranger probing the network, knows it.
The project has not named the bug being hunted. It has not said whether any funds have actually left a channel. That silence is the uncomfortable part. Operators are being asked to move first and read the postmortem later, which is exactly how serious node software should be handled when the alternative is a penalty transaction or a crashed daemon at the worst possible moment.
Why Older Core Lightning Nodes Are in the Crosshairs
Core Lightning, often shortened to CLN by people who live in the software, told operators to leave 26.06.7 and earlier behind as soon as they can. The trigger was not a theoretical write-up. It was reports of attackers targeting systems that had not taken the latest release. Weeks earlier, another round of fixes had already shipped. The new message is narrower and sharper: the window for “I’ll do it this weekend” is the window attackers prefer.
I’ve found that Lightning warnings get shrugged off until a channel force-closes at 2 a.m. Then the changelog suddenly looks like required reading. This one deserves that attention before the force-close, not after.
What the Project Actually Said, and What It Refused to Say
The public line was blunt. If you are on 26.06.7 or earlier, upgrade to the latest release. No colourful threat model. No proof-of-concept pasted into a forum. No confirmation that a specific September flaw is the one being used.
That gap matters. The warning does not prove the live probes match the bugs fixed in late September. It also does not rule that out. It could be an older issue that never left the wild, or a chain of small mistakes that only bites unpatched builds. Until the team speaks in more detail, the honest position is simple: unpatched nodes are the ones being singled out, and the project will not walk you through the exploit path while people are still upgrading.
Urgent security update: if you are running version 26.06.7 or earlier, upgrade to the latest release as soon as possible.
Core Lightning project notice
Perhaps the most interesting aspect is what was left off the page. No loss figure. No count of affected nodes. No claim that an attack had succeeded. In security work, absence of a body count is not the same as safety. It usually means the team is still sorting signal from noise, or that publishing the method would help the next person more than it helps you.
A Short Map of the Versions That Matter
The year did not start with this alert. It stacked up.
- Late August brought 26.06.7, aimed at flaws confirmed after a flood of vulnerability reports, many of them produced with the help of increasingly capable models scanning open source.
- Source for that release was held back for about two weeks so operators could update before outsiders reverse-engineered the diff.
- Mid-September, the team said it was looking into a possible problem tied to experimental features, with a warning that user funds could be in play.
- On 22 September, 26.06.8 landed with bug fixes and patches for issues reported through responsible disclosure. No embargo on the release itself. A handful of tests stayed private on purpose.
- The October alert then pointed at everything at 26.06.7 or earlier, after reports of active targeting.
If your node still answers with an older version string, you are on the wrong side of that line. Not “a bit behind.” On the list.
What 26.06.8 Was Built to Stop
Release notes credited the Bitcoin Red Team, twelve named researchers and groups, and people who preferred to stay anonymous. The project strongly recommended the install and said there was no embargo period. A small set of tests was kept out of the public drop so it would be harder to walk backward from the tests to the bugs while nodes were still catching up.
The changelog, read without the drama, still shows three kinds of pain.
One fix dealt with a condition that could crash the sender’s node. A crashed sender is not a stolen wallet by itself. It is a node that stops watching, stops responding, and hands timing to whoever is still online. On Lightning, time is a weapon. Miss a deadline and a counterparty can publish a stale state. That is how honest software turns into an expensive lesson.
Another fix covered requests that could chew through memory via the REST interface. Exhaust the process and you get the same practical result as a crash: a daemon that cannot do its job. Memory bugs rarely make headlines until they do. They are boring until the box stops answering peers.
The third class is the one that should make capacity owners sit up. Under certain conditions, a channel-closing bug could leave a user losing funds to a penalty when the channel closed. Not a fee. A penalty. In Lightning, penalties exist to punish publication of an old state. A software flaw that walks you into that outcome is a direct hit on the balance you thought was yours.
The project has not said these exact flaws are the ones under attack now. Treat that as unknown, not as comfort.
How a Channel Penalty Actually Bites
Think of a Lightning channel as a shared notebook that both sides keep updating. The current page is the real balance. Older pages are decoys. The protocol lets either side publish a page on the base chain if the other side vanishes. Publish an old page, and the honest side can claim the whole channel as a penalty, provided they are awake and watching.
A bug in the closing path can scramble which page gets treated as current. In the worst telling, your own node helps the chain see a state that triggers the penalty against you. You did not try to cheat. The software handed the other side, or the protocol’s own justice transaction, a clean shot.
That is why “funds could be lost on close” is a different sentence from “the node might restart.” Restarts are annoying. Penalty losses are permanent in the way Bitcoin is permanent. No support desk reverses a confirmed penalty.
In my experience, operators underestimate this because most closes are cooperative and dull. The dangerous closes are the ones that happen when a peer is offline, a bug fires, or both. Those are exactly the closes a patched release is meant to make boring again.
The August Wave, and Why AI Reports Changed the Tempo
Before September’s patches, developers were already swimming in reports. Models good enough to read a large codebase started producing Common Vulnerabilities and Exposures style write-ups at a volume no small team is built for. Most of that pile was noise. Some of it was not.
The project confirmed multiple issues after that review. Version 26.06.7, dated 28 August, was the response. Source stayed private for roughly two weeks. The idea was simple and slightly uncomfortable: give runners time to install before anyone could diff the fix and invent the attack. The source went public after the embargo, in September.
Is withholding source a perfect strategy? No. Mirrors leak. Impatient operators build from somewhere else. Still, a short blackout is better than publishing a map to the lock while half the network is on holiday. I’ve come to see that delay as a feature of serious maintenance, not a slight against open source purity.
At that stage the team did not claim attackers had already cashed out through the confirmed flaws. The October note changes the temperature. Targeting is no longer a hypothetical. Success and losses remain undisclosed. Those are different facts, and they should stay different until someone shows evidence.
Offline Mode Was the Emergency Brake, Not a Lifestyle
Operators who could not patch immediately were told they could run with an offline setting. The node dropped Lightning peers. It stopped sending, receiving, and routing. The daemon stayed up so it could still watch the Bitcoin chain for channel-related transactions.
That distinction is easy to miss. A fully stopped node does not watch. An offline-but-running node does. If a peer force-closes while you are dark, the watcher is what notices the publish and reacts inside the dispute window. Kill the process entirely and you are hoping the timelock is long enough for you to notice over breakfast.
Offline mode is a seatbelt, not a destination. You lose routing fees, you break invoices, and your peers start to treat you as absent. Use it to buy hours, then upgrade. Sitting in offline mode for weeks because the changelog felt long is how channels die of neglect.
| Node state | Payments and routing | Chain watching | Practical risk |
| Latest release, online | Normal | Active | Lowest, assuming config is sane |
| Old release, online | Normal | Active | Exposed to reported targeting |
| Offline setting, daemon up | Stopped | Active | Temporary shield, no revenue |
| Process fully stopped | Stopped | Absent | Missed justice transactions |
The table is a judgment call, not a formal threat model. It still captures the trade I would make: patched and online beats old and online, and a watching daemon beats a powered-off machine if you cannot patch in the next hour.
Experimental Features and the September Scare
On 16 September the team said it was investigating reports of a potential problem involving experimental features. The issue could affect user funds. Details did not drop the same day. That is a familiar rhythm in this corner of Bitcoin: confirm the blast radius in private, ship the fix, then talk.
Experimental flags are where curious operators get hurt. A feature that is not on by default can still be on in your config because a guide from last year said to try it. If you enabled something marked experimental and then ignored two point releases, you are not a passive victim of the network. You opted into a sharper edge.
I am not arguing for timid software. Lightning only moves when people test new paths. I am arguing for a boring production node. Experimental on a laptop with pocket change is a hobby. Experimental on a routing box with serious capacity is a bet you should be able to explain out loud.
Why Some Tests Stayed Private
Withholding tests sounds shady until you have watched a patch get turned into an exploit over a weekend. A good regression test often describes the bug more clearly than the commit message. Leave that test in the public tree on day one and you have published a recipe while half the fleet is still compiling.
The project kept a small number of tests back for that reason. The release itself was not under embargo. Install was encouraged immediately. The missing tests were a speed bump for people trying to reverse the vulnerability, not a trick to hide the upgrade.
Could a determined reader still find the bug from the diff alone? Sure. Diffs talk. The point was to raise the cost during the hours and days when operators were actually moving. Security is often just a race you try not to lose by much.
A Rough Year for Software Around Lightning
CLN is not the only project that had a bad summer. Context helps, as long as we do not mash separate incidents into one conspiracy.
In August, BTCPay Server warned about an active Lightning exploit on installs that had not reached 2.4.2. The flaw exposed LND administrator macaroon credentials on vulnerable setups. An administrator macaroon is not a cute cookie. It carries broad permission over the linked Lightning wallet. Steal it and you may not need a protocol bug at all. You walk in through the front door the software left open.
Funds were drained from some affected nodes. A recovery bounty followed, 10 percent, capped at 3 BTC if everything stolen came back. Every release before 2.4.2 was in scope, including release candidates of that version. On-chain wallets were not part of the flaw. That split is worth remembering: Lightning credentials and on-chain keys are neighbours, not the same key.
Days earlier, Zeus Wallet took infrastructure offline after a cyberattack. The team said the incident was contained within hours, kept systems down for an audit, and did not believe customer funds were lost or put at risk. The investigation had not identified a vulnerability in Lightning node software itself. Users whose Lightning service provider channels closed during the outage were told replacement channels would follow once service returned.
Different failures. One was a credential leak in server software sitting in front of LND. One was an infrastructure hit on a wallet project, with funds reportedly untouched. The CLN alert is a third shape: node software, older versions, reported targeting, undisclosed method. Lumping them together as “Lightning is broken” is lazy. Ignoring the pattern of 2026 maintenance is also lazy.
Bitcoin Core Had Its Own Quiet Patch
Security work was not confined to payment channels. In May, Bitcoin Core disclosed a high-severity issue that could let a miner remotely crash vulnerable nodes. Tracked as CVE-2024-52911, it affected releases after 0.14.0 and before 29.0. The fix was already in 29.0 before the public write-up.
The bug lived in the script interpreter during block validation. A crafted invalid block could make a node touch memory after it had been freed. Triggering it required a block with enough proof of work to matter at the tip, so the attack was expensive. Remote code execution was treated as possible but unlikely, given limits on block data.
Why mention a chain bug in a Lightning article? Because your CLN process is only as calm as the bitcoind it trusts. A node that falls over on a weird block stops watching channels at the same moment the chain is doing something unusual. Stack old Lightning software on old Bitcoin software and you have built a museum exhibit, not a payment node.
Who Should Care, Beyond Full-Time Routers
The obvious audience is the operator with public channels and a fee income they actually notice. They are online, they have peers, and an old binary is a billboard.
The less obvious audience is everyone else.
- A household node that mostly receives a salary or a donation still has channels with real sats on one side or the other.
- A merchant stack that embeds CLN inherits the version the image shipped with, which is often older than the merchant thinks.
- A tutorial follower who cloned a guide in the spring may still be on the tag that guide pinned.
- A friend who “set it and forgot it” after a conference workshop is the classic target. Forgetting is a configuration.
If you do not know your version, you do not get to assume you are fine. Ask the daemon. Write the string down. Compare it to 26.06.7. Newer than that line is the direction the alert wants. Latest is better than merely newer, because point releases exist for a reason.
A Practical Upgrade Path That Does Not Panic the Channels
Panic-upgrading is how people paste the wrong binary over a live database. Slow panic is worse. Here is the order I would actually use, adjusted for a normal self-hosted box rather than a fantasy data centre.
- Read the version from the running process and note open channels, peers, and whether experimental options are on.
- Back up the node directory the way you already should have backed it up. If your backup story is “I will figure it out,” fix that before you touch packages.
- Confirm your Bitcoin backend is itself on a maintained release. A fresh CLN on a prehistoric bitcoind is a half job.
- If you cannot patch within the hour and the alert makes you nervous, prefer the offline setting over killing the process, so chain watching continues.
- Install the latest release from the project’s normal channel, not a random build dropped in a chat.
- Restart, confirm the new version string, and watch logs for peer reconnects and any complaint about a database migration.
- Only then turn experimental flags back on, and only if you still want them.
- Tell your future self the date. A note in the runbook beats a foggy memory in six months.
None of that is exotic. It is the same muscle as updating a router firmware, except the router does not custody a penalty path to your savings.
What “Latest” Should Mean in Practice
People argue about floating tags versus pinned versions. Pinning feels professional until the pin is the vulnerable build. Floating feels careless until you realise Lightning point releases are often the entire security story.
A reasonable middle is a pinned version that you review on a schedule shorter than a season. Weekly is not absurd for a routing node. Monthly is the outer edge I would defend. “When the disk fills up” is not a schedule.
Package delays are real. Distribution repositories lag. Container images lag more. If your only update path is an image someone else rebuilds, you have outsourced the race. Check the tag inside the container, not the date on the blog post that told you to pull it.
Operator habit worth keeping: version string, backup date, Bitcoin backend version, experimental flags. Four lines. Review them when the alert drops, not after a channel vanishes.REST Interfaces, Local Networks, and the Boring Attack Surface
The memory-exhaustion note tied to REST is a reminder that “I only expose the node to my LAN” is not a spell. Laptops get malware. Plugins get broad tokens. A dashboard you installed in 2024 may still be allowed to hammer the API.
If a peer on the public network can crash you, that is one problem. If a process on the same machine can request you into a swap storm, that is another, and it does not require a global adversary. Patch both. Then ask which machines are allowed to speak REST at all.
I would rather a node be slightly inconvenient to administer than convenient for every container on the host. Convenience is how macaroons end up in a web root, which is a lesson the BTCPay incident already taught the ecosystem this year.
Routing Fees Versus Staying Alive
There is a small temptation, if you earn fees, to delay a restart because downtime looks like lost sats. Run the numbers honestly. A few hours offline costs a rounding error next to one penalty on a fat channel. The fee market will not pay you back for a justice transaction that fired against you.
Peers also notice flapping. A clean upgrade window, announced or simply survived, is better than a crash loop caused by a bug you could have left behind. Reputation on Lightning is mostly uptime plus liquidity. A patched node supports both.
If you run multiple nodes, stagger them. Do not reboot the whole fleet in one script the first time you touch a new release. One canary box tells you whether the migration is peaceful. The others can follow after logs look dull, which is the compliment you want.
What We Still Do Not Know
Speculation fills the gap the project left open. Resist the tidy story.
- We do not know which vulnerability, if any of the published ones, is being used.
- We do not know whether reports describe scans, crash attempts, or completed theft.
- We do not know a loss total, because none has been published.
- We do not know how many nodes remain on 26.06.7 or earlier. Public gossip gives hints, not a census you should bet the house on.
Unknown is not a reason to wait. Unknown is the reason the instruction is “upgrade,” not “upgrade if you see symptom X.” Symptom-based patching is how you become the case study.
A Clearer Way to Think About Lightning Risk
Lightning risk is not one dial. It is a stack.
Hot keys sit on a machine that must be online to be useful. That is the bargain. You accept a smaller hot balance so the base chain stays cold. Channel state has to be backed up or derived in a way your implementation supports, or a disk failure becomes a theft by your own peer. Watchtowers, where you use them, are a second pair of eyes for the justice path. Software version is a fourth layer people treat as optional. It is not optional. An old binary can undo careful key hygiene.
The metaphor I keep is a shop with a good safe and a broken shutter. The safe is your seed. The shutter is the node that must stay awake. Patching is oil on the shutter. Skip it and you are arguing about metallurgy while the shutter is stuck open.
A sane Lightning risk split, roughly: Keys and backups you can restore A watcher that outlives your laptop sleep Software that is not the version attackers are naming Capacity you can afford to have online
None of those lines replaces the others. A perfect backup does not save you from a penalty bug if the live state is what the bug corrupts. A perfect version does not save you from a seed phrase in a screenshot. Adults do all four.
After the Upgrade, What “Fine” Looks Like
Green version string is the start. Then you want boring logs. Peers return. Channels stay in their normal states. No surprise force-closes in the hour after restart. REST, if you use it, answers without the process ballooning.
If a channel does close during the window, do not assume the bug. Restarts disturb peers. Some peers are fragile. Read the close reason before you write a thread. Also do not assume innocence. If the close looks like a penalty and you were on the old build at the moment it published, keep the logs. They are the only story you will have.
For the next fortnight I would check the node the way you check a kettle you do not quite trust. Not obsessive. Not absent. A glance at uptime, disk, and peer count beats a dashboard you open only when something is already on fire.
The Social Layer: Guides, Images, and Stale Advice
A lot of Lightning pain is inherited from instructions that froze in time. A video says install this tag. A forum sticky says enable that plugin. A marketplace image says “latest” and was built in spring. The October alert is partly a tax on that freeze.
If you publish guides, update the version pin or take the guide down. Leaving a vulnerable tag in a top search result is how strangers get recruited into the target set. That is not a legal claim. It is a manners claim, and a practical one.
If you follow guides, treat every install command as perishable. The command that was kind in August can be the command the alert is describing in October. Re-read before you paste.
Merchants, Plugins, and the Hidden CLN
Not everyone who runs Core Lightning knows they run Core Lightning. Point-of-sale stacks, donation pages, and self-hosted shops sometimes wrap the daemon so tightly that the version is a footnote in a system panel. Those wrappers helped Lightning reach people who will never open a terminal for fun. They also hide the upgrade button.
If your shop takes Lightning, ask which implementation sits underneath and which release it is on. “The plugin handles it” is not an answer when the plugin’s image is the old release. The BTCPay episode already showed how a layer above the node can leak power over the node. A stale CLN build is the same class of problem from the other direction: the payment path is only as current as its least loved package.
Staff who press the checkout button should not have to parse changelogs. Someone in the shop still should. Put the version check on the same list as card terminal firmware. Dull lists are how small businesses stay solvent.
Capacity, Trust, and the Peer You Cannot Audit
Your peer does not need to be a cartoon villain for an old bug to cost you. They need a channel, a close path, and timing. Sometimes the “attacker” in a report is a scanner farming crashes to map versions. Sometimes it is a counterparty who noticed you advertise an old feature set. The protocol does not require motive to be pure. It requires state to be current and software to enforce that.
Large channels toward unknown peers were always a conscious risk. This alert nudges the dial. If you cannot patch today, shrinking exposure is the adult move: fewer public channels, less capacity on the ones you keep, offline mode if the team’s temporary option still applies to your build. Pride is a bad liquidity strategy.
I have watched operators defend a huge channel because closing it felt like admitting the node was a hobby. The chain does not grade intent. It grades transactions. A smaller channel that survives a bad week beats a trophy channel that funds a penalty.
What a Responsible Disclosure Culture Is Buying You
The 26.06.8 notes named a red team, a dozen researchers, and anonymous reporters. That list is the unglamorous reason your Tuesday can still be boring. Someone read the code, wrote it up in private, and waited for a release instead of posting a crash recipe for clout.
The August flood of model-written reports cut both ways. It found real bugs. It also buried maintainers in lookalikes. If you send reports, send the ones you have actually reasoned about. A thousand automatic tickets do not make a project safer if the humans stop being able to see the real one.
Users rarely see that labour. They see an alert, or they see nothing and assume nothing happened. The nothing is the product. The alert is what you get when the nothing fails.
Questions Worth Asking Before You Go Back to Sleep
Do you know the version string without logging in through a forgotten tunnel? Can you restore a backup on a spare disk this month, not in theory? Is the Bitcoin backend patched for the issues disclosed this year? Are experimental options still on because a blog told you they were cool? Who else can reach the REST port?
If any answer is a shrug, the alert did you a favour. It arrived before the paragraph in someone else’s write-up that uses your node as the example.
And if you already upgraded, good. Tell the group chat the version, not a victory lap. Social proof moves more nodes than a changelog ever will. People copy peers. Be the peer who is current.
The Part That Should Stick
Core Lightning has warned that attackers are targeting nodes on 26.06.7 or earlier, and it wants those operators on the latest release now. The September package already covered crashes, a REST path that could eat memory, and a closing bug that could hand funds to a penalty. August’s release covered a separate batch confirmed after a wave of reports, many of them machine-assisted. Offline mode can keep the chain watcher alive if you cannot patch in the next breath. It cannot collect invoices, and it cannot be your personality.
Nothing public yet proves a theft total, or pins the live probes to one CVE. That is unsettled. The action is not. Old Lightning software is a hot wallet with extra steps, and extra steps do not make it cold. Upgrade, confirm the string, keep the watcher running, and treat the next point release as maintenance rather than news.
Lightning still does the thing people wanted from it: small payments that do not wait on a block. It only keeps doing that for you if the node in the cupboard is the node the maintainers are still willing to defend. Everything else is a story you tell yourself while the version string ages.
