zebrad's mempool download and verification pipeline uses a bounded pool of 25 concurrent slots shared across all inbound peers without per-peer limits. An attacker can monopolize all slots by sending fake transaction IDs in inv messages, causing the node to queue download tasks that time out after 20 seconds. Because the overload condition is not signaled to the peer connection layer and misbehavior is not attributed, the attacker is never disconnected and can sustain the denial of mempool transaction admission. This affects all default configurations where inbound P2P connections are accepted and the mempool is active. The vulnerability is addressed in zebrad 4.5.0 by implementing per-peer slot accounting, surfacing overload signals, and attributing misbehavior to peers.

The vulnerability causes denial of mempool transaction admission for all honest inbound peers and local RPC clients while the attack is ongoing. This prevents new transactions from entering the mempool but does not affect block validation, chain synchronization, consensus, funds, or on-disk state. The attacker requires only a single TCP connection and minimal bandwidth to sustain the attack. The node recovers immediately once the attack stops.

An official fix is available in zebrad version 4.5.0. This update adds per-peer queue accounting limiting each peer to a fraction of the total mempool slots, surfaces overload signals to the peer connection layer, and attributes misbehavior to peers to enable disconnection. There is no complete configuration workaround; reducing inbound peer count does not prevent a single peer from saturating all slots. Users should upgrade to zebrad 4.5.0 or later to fully mitigate this issue.