zebrad's mempool download and verification pipeline uses a shared pool of 25 concurrent slots for inbound transaction processing. Due to architectural gaps—no per-peer slot limits, no overload signaling to disconnect peers, and no attribution of verification failures to peers—a single unauthenticated peer can monopolize all slots by sending fake transaction IDs in inv messages. These slots remain occupied until timeouts expire, causing all other inbound transactions and local RPC sendrawtransaction calls to be rejected with a FullQueue error. The attacker is not penalized or disconnected, enabling sustained denial of mempool admission. The vulnerability affects all default configurations with inbound P2P enabled and active mempool. zebrad 4.5.0 fixes this by implementing per-peer slot limits (e.g., 5 of 25 slots per peer), surfacing FullQueue as an overload signal to trigger disconnection, and associating peer identity with verification tasks for misbehavior scoring.

Denial of service on mempool transaction admission for all honest peers and local RPC clients while the attack persists. Block validation and chain synchronization continue unaffected. The attacker requires only a single TCP connection and minimal bandwidth (~1 KB/s). There is no impact on consensus, funds, or on-disk blockchain state. The node recovers immediately after the attack stops.

An official fix is available in zebrad version 4.5.0, which adds per-peer queue accounting, overload signaling, and misbehavior attribution to prevent this denial of service. Users should upgrade to zebrad 4.5.0 or later. There is no complete configuration-level workaround; reducing inbound peer count limits total peers but does not prevent a single peer from saturating mempool slots.