btcd Inbound Transport Handshake Resource Exhaustion

Impact

btcd accepted an inbound TCP socket and ran the transport handshake before the connection counted against the server’s maxpeers limit. A remote host could therefore hold many inbound sockets in the pre-peer state, occupying accepted sockets and handshake goroutines beyond the configured limit and refusing service to honest inbound peers.

With --v2transport enabled (available from v0.25.0), the responder also performed asymmetric cryptography (key generation, ElligatorSwift ECDH, cipher setup) on each candidate v2 handshake before admission, adding CPU amplification. The socket accounting gap applied regardless of that flag.

There is no fund-loss path. Service recovers when the attacker disconnects.

Severity

Scored against the Lightning Labs severity taxonomy:

Dimension	Score	Reasoning
Impact	Low	Transient, operator-recoverable service disruption.
Attack Vector	High	Network. Any host that can reach the P2P listener; no peer relationship required.
Exploitability	High	The attacker controls the socket lifecycle and reliably enters the pre-peer path.
Virality	Low	Sustained per-victim connections; nothing propagates.

Result: T3. Rule 3 (Impact = Low, base T3); no promotion because Virality is not High. A reachable non-viral DoS is T3 regardless of how trivially it triggers.

Patches

Fixed in btcd v0.26.2 via btcd#2576, which caps accepted inbound sockets against the maxpeers budget at the listener, bounds pending handshakes per source before any transport work is performed, and rate-limits v2 responder key setup. Users should update to v0.26.2 or later.

Disclosure timeline

• Identified internally by the Lightning Labs security team on 2026-07-13.
• Fix merged 2026-07-22; released in btcd v0.26.2 on 2026-07-24.
• Public disclosure: 2026-09-21.