vulnerability / NVI-00017567 / Revision 1
zebrad has mempool transaction admission denial via single-peer inbound queue saturation
GitHub lists this reviewed advisory for zebrad. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.
This report has not inspected your inventory, configuration, deployed build, reachability or evidence. A catalog listing and a severity score do not establish exposure or compromise.
01 / Meaning
Why it matters
Published affected context helps an owner decide what evidence to gather. This report has not examined your application.
5.3 medium
GitHub source severity; exploitability and local consequence require separate evidence.
As of · GitHub Advisory Database
02 / Applicability
The affected context
Affected versions, configuration prerequisites and known exclusions are public. Confirm each one against the deployed service.
zebrad
source listed<= 4.4.1
### Am I affected You are affected if: 1. You run `zebrad` up to and including `v4.4.1`. 2. Your node accepts inbound P2P connections (`network.listen_addr` is set, which is the default). 3. Your node's mempool is active (node is synced near the chain tip). All default configurations are affected. ### Summary A single unauthenticated P2P peer can monopolize all 25 inbound mempool download/verification slots (`MAX_INBOUND_CONCURRENCY`) by advertising fake transaction IDs. While the slots are occupied, all other inbound transactions from honest peers and local RPC `sendrawtransaction` calls are rejected with `MempoolError::FullQueue`. The attacker peer is never scored for misbehavior and is not disconnected, allowing sustained denial of mempool admission. ### Details The mempool download/verification pipeline at `zebrad/src/components/mempool/downloads.rs` uses a single bounded pool of 25 concurrent tasks. Three architectural gaps combine to produce the vulnerability: 1. No per-peer accounting: the 25 slots are shared across all peers with no cap on how many a single peer can hold. 2. No overload signaling: when `FullQueue` is returned, the inbound service at `zebrad/src/comp
03 / Response
What to do next
- investigate
Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database
A fixed release is not deployment evidence.
Check current vendor support and compatibility. After making a change, verify the deployed build and relevant runtime conditions. Keep the evidence, owner and time. An updated lockfile alone does not prove what is running.
04 / Limits
What this report cannot establish
- Customer inventory, deployment, reachability and exploitation have not been inspected.
05 / Provenance
Sources you can inspect
Each assertion retains its source. Mirrored records may repeat one underlying publisher; additional links are not independent corroboration.
- GHSA-4fc2-h7jh-287c ↗
GitHub Advisory Database · vendor advisory
Observed . GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.
Public revision history
Only published revisions appear here. Routine fetches do not create a material-change event.
- Revision 1 ·
First indexed by Null; source disclosure date is shown separately.