security updates

Core Lightning, the reference client for Bitcoin’s Lightning Network payment layer, released v26.06.9 on Wednesday, October 7. The point release addresses multiple security vulnerabilities and a performance regression that caused nodes to throttle ordinary peer traffic, and introduces ARM64 and ARMv7 binaries for the first time.

• Security fixes span channel reestablishment, splicing, HTLC handling, onion routing, and gossip range queries without embargo.
• Gossip CPU throttle regression in v26.06.8 now fixed; only gossip queries count against peer budget, not ordinary pings.
• Reproducible ARM binaries now available for Ubuntu 22.04, 24.04 and 26.04 alongside existing amd64 builds.

The v26.06.9 release patches vulnerabilities in channel reestablishment, splicing, HTLC handling during shutdown, onion handling, onchaind, gossip range queries, runes and setconfig, alongside remote-crash and hardening fixes. The project withheld tests for the security issues to limit exploit development time and give node operators a window to upgrade before full technical details are published. Node runners who operate the Lightning Network should upgrade as soon as practical; the release is available immediately with no embargo period.

Gossip throttle regression reversed

In v26.06.8, busy nodes began throttling their peers on ordinary gossip messages, pings and onion messages, which delayed channel traffic. The throttling mechanism was designed to protect nodes from resource exhaustion during gossip queries, but it was counting all peer traffic against the CPU budget.

The v26.06.9 release isolates the throttle to gossip queries only, restoring normal peer message handling for pings and onion routing.

ARM binaries and rune permission tightening

Core Lightning now distributes reproducible ARM64 and ARMv7 binaries for Ubuntu 22.04, 24.04 and 26.04, with signed SHA256 manifests for each architecture. Operators running Lightning nodes on ARM-based hardware, including Raspberry Pi nodes and low-power server deployments, can now verify builds against the maintainers’ signatures.

The release tightens access controls on runes, the authentication token system for node APIs. A rune with restrictions can no longer create a new rune without them; createrune and blacklistrune operations now require an unrestricted rune, and invokerune and destroyrune are checked under the same rules.

The listconfigs command now masks sensitive values including wallet paths, Tor service passwords and Bitcoin RPC credentials for all callers, regardless of rune permissions.

Splicing feerate enforcement and downgrade prevention

Splicing, the ability to add or remove liquidity from a Lightning channel without closing it, now enforces the negotiated feerate on the splice transaction itself. Previously, splices could proceed without validating the feerate matched peer negotiation, risking unconfirmed transactions or fee disputes.

Nodes running development builds cannot downgrade to any 26.06.x release because the database schema has evolved past compatibility.

What the release does not clarify

The release notes do not specify which vulnerabilities are critical versus moderate severity, or whether any have been exploited in the wild. The notes also do not state whether the gossip throttle regression affected routing reliability or channel closure times in practice, or provide metrics on how many nodes were affected.

Dual funding remains experimental, and the notes do not commit to a timeline for stabilizing this feature.

The CCS read. This release addresses the most common failure modes in production Lightning nodes: channel reestablishment after disconnection, splice liquidity management, and peer gossip synchronization. The gossip regression fix is material for routing node operators who manage many peers; unintended throttling degrades network reliability. ARM support lowers barriers for distributed node operation on commodity hardware. The rune tightening closes permission escalation paths that could let a restricted token holder bypass rate limits or access sensitive configuration.

The next event is the publication of full technical details on the patched vulnerabilities after sufficient nodes upgrade. Operators should track when the project lifts the security embargo and publishes test vectors and proof-of-concept details, likely in the coming weeks.