The vulnerability in zebrad's mempool download pipeline arises from a bug in handling timeout errors during transaction verification. When a verification task times out at the 73-second RATE_LIMIT_DELAY boundary, the error returned (tokio::time::error::Elapsed) carries no transaction ID, so the corresponding cancel_handles map entry is never removed. This map entry includes the full deserialized transaction, which can be large (up to ~9 MB). Because entries accumulate without garbage collection or eviction, memory usage grows unboundedly, leading to eventual out-of-memory process termination. The fix involves wrapping the timeout future to preserve the transaction ID on error and removing the cancel_handles entry on timeout. The vulnerability affects zebrad versions prior to 4.5.0 and requires inbound P2P connections and an active mempool to be exploitable.

The vulnerability causes a gradual, unbounded memory leak in zebrad nodes, leading to eventual out-of-memory termination or severe degradation due to swap pressure. The leak is triggered by unauthenticated inbound P2P traffic and accumulates at approximately 685 KB/s per connection in worst-case scenarios. There is no impact on consensus, no loss of funds, and no on-disk data corruption. The node continues normal operation until memory exhaustion occurs. An attacker must sustain traffic for hours to exhaust typical server memory.

A patch is available that fixes the memory leak by ensuring the transaction ID is preserved on timeout errors and the corresponding cancel_handles entry is removed. Operators should upgrade to zebrad version 4.5.0 or later. There is no configuration-level workaround; restarting the node clears accumulated entries but does not prevent recurrence. Operators running in memory-constrained environments should be aware of potential OOM kills until patched.