Bitcoin Core 32.1, Core Lightning security updates, and three checks worth making after your next upgrade.
I run my own Bitcoin infrastructure because I want fewer dependencies, not because I enjoy collecting servers. A node lets me verify Bitcoin's rules. Lightning adds the ability to move value without asking a custodian for permission. But neither of those benefits means much if I stop paying attention to how the software is exposed, what can talk to it, and which credentials are still floating around.
The last couple of weeks have made that especially clear.
Bitcoin Core 32.1 arrived on October 27, 2026. On October 28, the project published three vulnerability disclosures involving memory exhaustion and an unusual undo-file overflow scenario, with Project Loupe's AI-assisted scanning contributing to their discovery. Bitcoin Core also updated its disclosure approach for vulnerabilities that are easy to rediscover.
Then, on November 4, Core Lightning released v26.06.10, with security fixes involving channel opening, HTLC resolution, remote commands, and authorization mechanisms such as runes and commando.
None of this means that Bitcoin's consensus rules have failed. It does mean that the software and operational infrastructure around those rules need attention.
Here are three checks I think deserve a place in every self-hosted operator's routine.
1. Verify the software that's actually running
It sounds obvious, but checking an installed binary is not always the same as checking the running service. It's easy to end up with an updated package and an old process, especially when Docker images, different installation prefixes, or multiple services are involved.
For a Bitcoin Core instance accessible through your configured CLI:
bitcoin-cli getnetworkinfo
For Core Lightning:
lightning-cli getinfo
Record the versions reported by the running daemons, along with the deployment method and release source. If you use containers, identify the running image rather than assuming a moving latest tag means you've updated.
Also distinguish between a maintained branch with current security backports and an unsupported release. The newest major version is not the only possible secure configuration, but an abandoned installation needs a plan.
2. Map what can reach your privileged interfaces
A firewall doesn't automatically tell you which applications can spend funds or access sensitive node information.
Your setup might include a Bitcoin wallet, an Electrum server, a Lightning dashboard, a monitoring agent, a remote phone client, and a reverse proxy. Each of those connections has a different purpose and a different level of authority.
On Linux, one useful starting point for inspecting listening network sockets is:
ss -lntup
This is not a complete exposure audit: Unix sockets, tunnels, firewall policy and reverse-proxy routes require separate checks. A service listening only on localhost may still be reachable through another component.
For each integration, ask two questions: What can it read? What can it do? Reading channel status is very different from initiating a payment or accessing administrative RPC methods.
If you cannot explain why a component has a particular permission, that is worth investigating before it becomes an incident.
3. Treat Lightning runes like real credentials
Core Lightning runes can authorize remote RPC calls. They are not harmless configuration strings, and the v26.06.10 security release specifically gives operators reasons to review them.
Inventory the runes you have issued and identify which application each one belongs to. Check whether permissions are narrower than full administrative access, whether the intended remote node identity is restricted where appropriate, and whether obsolete credentials can be revoked.
The showrunes command can help with a local inventory, but do not paste its raw output into public logs, screenshots or AI chats: it may expose the actual credentials.
This is the sort of problem that a successful binary update does not solve automatically. A patched daemon can still be surrounded by permissions you granted months ago and forgot about.
AI changes the timing, not the responsibility
AI-assisted vulnerability discovery is worth taking seriously without turning it into a headline about machines breaking Bitcoin. If some bugs become cheaper to rediscover, disclosure timing and operator response matter more. That is the practical takeaway from Bitcoin Core's recent policy change.
The useful habit is not panic-upgrading without preparation. It's maintaining an inventory, verifying releases, understanding who has access, and checking the running system after an update.
I went deeper into the October Bitcoin Core disclosures, the November Core Lightning fixes, and the operational consequences in a new investigation on Shadowbip. The reporting and context are publicly readable; the expanded seven-step audit playbook is reserved for paid subscribers.
AI Is Finding Bitcoin Bugs. Is Your Node Ready? — read the investigation
I'm interested in hearing from other operators: what's the most common security oversight you've found on an otherwise fully updated Bitcoin or Lightning node?
Shadowbip writes about Bitcoin infrastructure, privacy, Lightning, Nostr, and self-sovereignty. This article is an operator-oriented overview, not a claim of independent exploit reproduction or a security audit of anyone else's system.
Top comments (0)