There is something deeply uncomfortable about the security warning Core Lightning operators received this week.
The developers aren’t saying, “Here’s the bug. Here’s the patch. Compile it yourself.”
They’re effectively saying:
We found real problems. We’re fixing them. When the security release arrives, verify our signatures and install the binaries. We’ll show you exactly what changed later.
Later means fourteen days.
For almost any other piece of software, that might sound like a fairly boring responsible-disclosure procedure.
For Bitcoin software, it’s different.
We spend years telling people not to trust binaries blindly. Verify signatures. Prefer reproducible builds. Read the code if you can. Build from source. Reduce trust wherever possible.
And now one of the major Lightning implementations is deliberately creating a window where operators are being asked to install a fix before the source patches and technical details become public.
At first glance that sounds backwards.
Once you understand why they’re doing it, though, the decision becomes much harder to criticize.
Because publishing the source doesn’t only help defenders verify the fix.
It can also tell an attacker exactly where to look.
And that is what makes these next fourteen days interesting.
The story didn’t begin with an exploit draining Lightning nodes.
As far as we know today, no such thing has happened.
Core Lightning said it had been receiving a large number of AI-generated vulnerability reports from multiple sources. Its small development team, helped by open-source contributors, spent days validating and triaging them.
Some were real.
That’s the first detail worth slowing down for.
“AI-generated vulnerability report” can mean almost anything today. Give a sufficiently capable model a codebase and ask it to find security bugs and it can produce an impressive pile of plausible-looking problems.
The difficult part starts afterward.
Can you reproduce it?
Can a remote peer trigger it?
Does it require some unrealistic state?
Does it crash one subdaemon or the entire node?
Can it affect funds?
Is it already known?
Is it even a vulnerability?
Someone still has to answer those questions.
In this case, the CLN team says that after doing that work, several of the reports turned out to describe genuine issues requiring a coordinated fix.
That’s about as far as we can responsibly go today.
We don’t know the complete vulnerability classes.
We don’t have the full source patches.
We don’t have public details sufficient to reproduce the bugs.
And I haven’t seen evidence that these newly reported vulnerabilities have been exploited in the wild.
That information is intentionally missing.
The missing information is part of the security strategy.
Imagine CLN publishes a normal release.
The binary appears.
The source appears.
There are a handful of small changes buried inside thousands of lines of code.
For an attacker, that’s useful information.
They don’t need somebody to publish a tutorial called How to Exploit Core Lightning.
They can compare the vulnerable release with the fixed release.
What changed?
Where did developers suddenly add validation?
Which message is now rejected?
Why did this boundary check appear?
Why did this state transition change?
A security patch can be a confession.
It tells you where the old code was wrong.
Patch diffing isn’t new. Security researchers and attackers have done it for years.
What is changing is the speed.
The same AI tools that can scan a repository for suspicious code can also inspect a patch, reason about why it exists and potentially accelerate the process of turning a fix into something exploitable.
So CLN has a deployment problem.
Publish everything immediately and operators get maximum transparency.
Attackers get exactly the same transparency.
And the attacker doesn’t need to beat every node operator.
He only needs to beat the ones who haven’t upgraded yet.
That’s what the fourteen-day embargo is trying to prevent.
The plan is straightforward, but unusual enough that Bitcoiners should understand what they’re accepting.
Core Lightning intends to distribute a point release as signed binaries first.
The source patches, reproducible-build material and technical details behind the vulnerabilities are expected to follow after a fourteen-day embargo.
That gives node operators time to move onto patched software before everybody can inspect exactly what was fixed.
Normally the open-source security process looks something like:
Find → fix → publish → verify → deploy.
This time it’s closer to:
Find → fix → sign → deploy → wait → publish → fully verify.
That doesn’t eliminate verification.
It postpones part of it.
And that’s an important distinction.
You’re not supposed to download some random binary from a Telegram message because somebody says it’s safe.
You can still verify the developer signatures.
What you cannot immediately do is inspect all of the source behind the security changes and independently establish why those changes were necessary.
Authentication is available immediately.
Full transparency isn’t.
For fourteen days you’re verifying who gave you the medicine, not yet every ingredient inside it.
This is where the story becomes more interesting to me than the vulnerabilities themselves.
“Don’t trust, verify” is probably the most repeated sentence in Bitcoin after “not your keys, not your coins.”
I use it all the time.
But sometimes we turn good principles into slogans and stop thinking about what they actually mean.
Verification isn’t binary.
When I run my own node, I’m independently verifying Bitcoin’s consensus rules.
When I verify a software signature, I’m checking that the file I downloaded is the one signed by the developer whose key I expect.
When I reproduce a build, I’m checking whether the published source actually produces the binary I’m being offered.
When I audit the source myself, I’m doing something else again.
Those are different guarantees.
During this embargo, CLN operators won’t have all of them at once.
That is a trust trade-off.
We should call it one.
But immediate disclosure creates another trade-off.
It gives every honest operator the ability to inspect the fix immediately.
It also gives every attacker exactly the same ability.
Open-source software doesn’t know whether the person reading the diff is a node operator trying to protect 20 channels or someone trying to find the fastest path to an exploit.
Once the patch is public, it’s public for everybody.
Normally that’s one of open source’s greatest strengths.
During an active security migration, it can also work against you.
If this story sounds familiar to regular readers, it should.
Two weeks ago I wrote about the shutdown of Boltz after the team described an environment where attackers could iterate faster than a small development team could find and patch problems.
That story bothered me because the problem wasn’t simply that attackers had AI.
Defenders have AI too.
The problem was pace.
Small open-source teams have finite attention. Automated systems don’t get tired, don’t sleep and don’t mind generating another hundred possible attack paths overnight.
Core Lightning now gives us another version of the same problem.
Boltz was about keeping up with attacks.
CLN is about keeping up with reports, verifying which ones are real, fixing them and then deploying those fixes before someone else weaponizes the information.
Different project.
Same pressure.
Related: AI vs AI: How Boltz’s Shutdown Reveals Bitcoin’s New Threat Model
There was some confusion when the warning started circulating.
Some people interpreted it as: shut your CLN node down.
That’s not the useful distinction here.
If you can’t upgrade, the guidance is to restart lightningd with:
--offline
A Lightning node isn’t a web server you can unplug and forget about.
You have state tied to payment channels, and protecting those channels includes continuing to observe what happens on Bitcoin.
A completely powered-down node isn’t watching the chain.
Offline mode instead removes ordinary Lightning peer connectivity. You’re not routing payments or interacting normally with peers, but the node can continue monitoring Bitcoin.
That’s an important operational distinction:
Offline doesn’t necessarily mean off.
During a security event, reducing the network-facing attack surface while preserving on-chain monitoring can be much safer than simply pulling the plug.
And it points to something broader about Lightning that I think gets lost when we make the UX too invisible.
Lightning is hot infrastructure.
If you run a node, sovereignty comes with operational responsibility.
There’s another part of this story I think is being framed badly.
The obvious headline is:
AI finds Bitcoin vulnerabilities.
Nice headline.
Incomplete story.
AI generated reports.
Humans still had to determine whether those reports described reality.
Suppose an AI agent can inspect a repository overnight and return 200 potential vulnerabilities.
For the person running the agent, that’s an enormous productivity gain.
Now put yourself on the other side.
You’re maintaining the project.
You don’t get to patch 200 things because a model says they’re dangerous.
You have to triage them.
Understand the code path.
Reproduce the issue.
Figure out whether it’s remotely reachable.
Check whether the proposed fix breaks something else.
Coordinate with other developers.
Test the release.
Communicate with operators.
And if the software controls money, “the model thinks this patch works” isn’t exactly an acceptable review process.
This creates an asymmetry I think open-source projects are going to struggle with:
AI can scale vulnerability discovery faster than small teams can scale vulnerability triage.
The marginal cost of generating another plausible report is collapsing.
The cost of responsibly proving that report is real isn’t.
This is the part that makes the fourteen-day decision easier to understand.
AI isn’t defensive technology.
It isn’t offensive technology either.
It’s leverage.
Give an agent the vulnerable release and the patched release.
Then ask:
What security-relevant code changed?
What inputs reach this function?
Why was this validation added?
Can the previous behavior be triggered remotely?
Generate test cases against the old version.
That doesn’t magically produce a working exploit.
There is still a large gap between “this looks suspicious” and reliable exploitation.
But that gap is getting cheaper to explore.
Historically, publishing a security patch created a race between humans reading the patch.
We’re moving toward a race between automated systems reading it.
Seen from that angle, the fourteen-day embargo looks less like secrecy.
It looks like a firewall made out of time.
A temporary one.
I understand withholding the vulnerable code paths.
I’m less comfortable with security information living mainly in places operators have to actively follow.
Early information about this incident spread through Discord, social media and third-party reporting before the normal public disclosure artifacts were available.
There’s an obvious reason not to publish a CVE containing enough detail to reproduce an embargoed vulnerability.
But there is a big difference between hiding how to exploit something and hiding that operators need to act.
A good emergency advisory can be boring:
Security release coming.
These are the supported versions.
This is what operators should do.
These are the signing keys.
This is the canonical download location.
This is when the embargo ends.
No exploit details required.
Because think about who runs Lightning infrastructure.
It’s not just the guy with six terminals open who follows every CLN developer on Nostr.
There are routing nodes.
Businesses.
LSPs.
Developers who integrated CLN months ago and moved onto something else.
People who automate infrastructure specifically so they don’t have to stare at it every morning.
Responsible disclosure isn’t only about keeping information away from attackers.
It’s about getting the right information to defenders before attackers can use it.
Those are two different problems.
There’s a reason I keep coming back to infrastructure dependencies in recent articles.
Bitcoin lets us remove an extraordinary amount of trust.
But “remove trust” and “have no dependencies” aren’t the same thing.
Your node depends on software.
Your Lightning channels depend on software.
Your hardware wallet depends on entropy being generated correctly.
Your Nostr identity depends on protecting a key.
Even infrastructure specifically designed around sovereignty has components that need to work as intended.
The goal isn’t pretending those dependencies don’t exist.
The goal is making them replaceable, auditable and unable to take custody from you.
That’s one reason projects built around open protocols interest me more than another polished custodial app.
A good example is Mostro, where Bitcoin trades are coordinated over Nostr and settled using Lightning rather than putting a centralized exchange in custody of both your identity and your coins.
For European users, MostroEuropa is one coordinator available on that network. It supports P2P Bitcoin trading without the normal KYC exchange account and without handing custody of the Bitcoin leg to a centralized platform.
That doesn’t magically make every dependency disappear.
It changes their nature.
And that’s the direction I want Bitcoin infrastructure moving: dependencies I can understand and replace, rather than intermediaries I need permission from.
MostroEuropa:
https://mostroeuropa.shadowbip.com/
Telegram community:
https://t.me/MostroEuropaCommunity
If you want the deeper technical explanation of how the coordinator model works, I covered it separately here:
I Built a P2P Bitcoin Coordinator for Europe. Here’s Why, and How to Use It.
Back to CLN.
“Signed binaries” sounds reassuring because it is reassuring.
But signatures answer one specific question:
Did the expected developer sign this file?
They don’t answer:
Is this software safe?
A buggy binary can have a valid signature.
A malicious binary can have a valid signature.
A compromised build environment can produce something signed by the expected key.
That’s not an argument against signatures.
It’s an argument for knowing what your security mechanism actually guarantees.
For these fourteen days, operators who upgrade are placing additional trust in CLN’s maintainers.
I don’t see a reason to pretend otherwise.
What matters is that the additional trust is:
limited, explicit and temporary.
The source is supposed to arrive.
The build information is supposed to arrive.
Then the community gets to verify what was distributed during the emergency.
That’s fundamentally different from proprietary software where “trust us” is permanent.
When the embargo expires, Bitcoiners should actually perform the verification we’re always talking about.
Compare the source.
Reproduce the builds.
Inspect the patches.
Confirm that the binaries distributed during the emergency correspond to the source eventually published.
The interesting test of this disclosure model comes after the embargo.
Earlier this month I wrote about two completely different Bitcoin failures: the BIP-110 fork and the Coldcard vulnerability.
The common thread was simple.
A safeguard existing isn’t enough.
You need to know what it’s actually safeguarding.
A hardware wallet can tell you it’s generating keys securely. That claim is only useful if the underlying entropy is actually good.
A UASF can use the same mechanism associated with 2017. That doesn’t magically reproduce the economic consensus that made the 2017 UASF credible.
And now:
A signed binary can prove who signed it.
It cannot prove that the code is safe.
Again, the answer isn’t to throw away the safeguard.
It’s to stop asking safeguards to guarantee things they were never designed to guarantee.
Related: Two Bitcoin Failures, One Week Apart — And the Lesson Most People Are Missing
Right now we’re missing the most interesting evidence.
That’s intentional.
When the embargo lifts, we’ll finally be able to ask the questions that can’t honestly be answered today.
How serious were these vulnerabilities?
Which components were affected?
Could they threaten funds?
Availability?
Privacy?
Were they remotely exploitable?
How difficult would exploitation have been?
Would publishing a normal source patch really have given attackers a useful map?
And ultimately:
Was withholding the source for fourteen days proportionate to the risk?
Maybe the answer will clearly be yes.
Maybe we’ll inspect the changes and conclude the embargo was excessive.
That’s fine.
Responsible disclosure shouldn’t become a religion either.
We should judge the decision when we have the evidence.
Today we don’t.
And filling that gap with speculation because “critical Lightning vulnerability” makes a better headline doesn’t help anybody.
This part is simple.
I’d follow the official CLN security guidance rather than screenshots and second-hand interpretations.
When the security release becomes available, I’d verify its signature before installing it.
If I wasn’t willing or able to install the binary-only release before source publication, I’d use the recommended offline mode rather than casually leaving the node exposed.
I wouldn’t reconnect because someone on social media says the vulnerability “probably isn’t serious.”
We don’t know that.
I also wouldn’t panic and assume every CLN node is about to lose its funds.
We don’t know that either.
The whole point of the embargo is that there are things we deliberately don’t know yet.
Security sometimes works that way.
I don’t think this incident proves open source is broken.
I don’t think it proves Lightning is broken.
And it definitely doesn’t prove AI can now autonomously audit Bitcoin infrastructure better than experienced security researchers.
What it shows is that the environment open-source security operates in is changing.
We built disclosure norms in a world where finding vulnerabilities was expensive.
Reading a large codebase was expensive.
Comparing patches was expensive.
Exploring a hundred possible attack paths was expensive.
Those things still require expertise.
But AI is reducing the cost of parts of that process.
For defenders.
For legitimate researchers.
For people flooding maintainers with garbage.
And for attackers.
Interestingly, this is happening at the same time that another part of the Lightning ecosystem is trying to make AI agents economic participants rather than security researchers.
Same technology.
Same network.
Completely different direction.
I wrote about that side of the story here:
AI Agents Are Starting to Pay in Bitcoin. Here’s How Lightning Makes It Possible.
AI could increase Lightning payment volume while simultaneously increasing the security workload required to keep Lightning implementations safe.
That’s a tension worth watching.
That’s ultimately what I take from the CLN decision.
If publishing a patch gives thousands of operators two weeks less time than the attacker, transparency has a cost.
If withholding it prevents independent verification, secrecy has a cost too.
There is no perfect answer.
The job is to minimize both.
For fourteen days, an open-source Bitcoin project is effectively telling operators:
Trust us a little more than usual. We’ll give you the evidence afterward.
As a Bitcoiner, that sentence makes me uncomfortable.
Good.
It should.
We built this ecosystem specifically to reduce the number of people we need to trust.
But reducing trust doesn’t mean pretending trade-offs don’t exist.
It means identifying them.
Limiting them.
Making them explicit.
And, whenever possible, giving them an expiration date.
Core Lightning’s fourteen-day embargo does exactly that.
Whether it was the right trade-off will become much easier to judge when the clock runs out.
Until then, I don’t think the most important part of this story is that AI found bugs.
It’s that AI may be forcing open-source security teams to reconsider when transparency becomes safe.
We’ve spent years saying:
Don’t trust. Verify.
This incident adds an uncomfortable footnote:
Sometimes, verify fourteen days later.
If you want to follow the wider thread behind this article:
AI vs AI: How Boltz’s Shutdown Reveals Bitcoin’s New Threat Model — what happens when automated attackers start moving faster than small Bitcoin infrastructure teams.
Two Bitcoin Failures, One Week Apart — And the Lesson Most People Are Missing — Coldcard, BIP-110 and why a security mechanism is only as good as what it actually verifies.
AI Agents Are Starting to Pay in Bitcoin. Here’s How Lightning Makes It Possible. — the other side of AI + Lightning: autonomous economic agents rather than vulnerability research.
Nostr and Lightning: The Protocol Stack That Could Replace Everything — why these open protocols matter beyond any single application.
Looking for a non-custodial, no-KYC way to trade Bitcoin P2P over Lightning and Nostr?
MostroEuropa:
https://mostroeuropa.shadowbip.com/
Telegram community:
https://t.me/MostroEuropaCommunity
Start small. Hold your own keys. Verify what you can.
This article reflects publicly available information as of August 28, 2026. The technical details of the Core Lightning vulnerabilities remain under embargo. Once the source patches are released, I’ll revisit them and look at what was actually fixed.
⚡ Zap me: zap@shadowbip.com
🐙 GitHub: https://github.com/shadowbipnode
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.