GHSA-h9hm-m2xj-4rq9
GHSA-h9hm-m2xj-4rq9 is a security vulnerability in zebrad. O3 Security confirms whether GHSA-h9hm-m2xj-4rq9 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Zebra has Permanent Block Discovery Halt via Gossip Queue Saturation and Syncer Poisoning
Real-World Exposure
zebradReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A composite denial-of-service vulnerability in Zebra's block discovery pipeline allows an unauthenticated remote attacker to permanently halt all new block discovery on a targeted node. The attack exploits three independent weaknesses in the gossip, syncer, and download subsystems — all exercisable from a single TCP connection — to create a monotonically growing block deficit that never self-heals.
Severity
Critical — This is a Denial of Service vulnerability that requires no authentication, no special privileges, and only a single peer connection. The halt is permanent: the node will never recover without operator intervention.
Affected Versions
All Zebra versions prior to 4.4.0.
Description
Zebra discovers new blocks through two complementary paths: a gossip path (peers announce blocks via inv messages, triggering individual block downloads) and a syncer path (Zebra periodically queries peers with FindBlocks/FindHeaders to discover chains of missing blocks). Both paths must function for normal operation.
The gossip path was vulnerable because there was no per-connection rate limit on inv messages. A single connection could send enough sequential inv messages with fake block hashes to fill the entire gossip download queue in under a millisecond. The FullQueue return value was silently ignored, so legitimate block announcements from honest peers were dropped with no warning.
The syncer backup path could be degraded by responding with empty inv to FindBlocks requests and with NotFound to block download requests. Both are valid protocol responses that carried zero misbehavior penalty. The attacker's connection was never banned and never disconnected, allowing the degradation to persist indefinitely.
Combining these two vectors, an attacker could suppress both block discovery paths simultaneously from a single connection, causing the node to fall permanently behind the chain tip.
Impact
Denial of Service
- Attack Vector: Network, unauthenticated. Requires only a single TCP peer connection.
- Effect: Permanent halt of block discovery. The targeted node falls behind the chain tip and never recovers without operator intervention.
- Scope: Any Zebra node reachable by the attacker over the peer-to-peer network.
Fixed Versions
This issue is fixed in Zebra 4.4.0.
The fix drops connections that send empty responses to FindBlocks and FindHeaders messages, preventing attackers from degrading the syncer path without consequence.
Mitigation
Users should upgrade to Zebra 4.4.0 or later immediately.
There are no known workarounds for this issue. Immediate upgrade is the only way to protect against this attack.
Credits
Zebra the researcher who reported this issue through the coordinated disclosure process.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | zebrad | all versions | 4.4.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for zebrad. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update zebrad to 4.4.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h9hm-m2xj-4rq9 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-h9hm-m2xj-4rq9 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-h9hm-m2xj-4rq9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-h9hm-m2xj-4rq9 in your dependencies?
O3 detects GHSA-h9hm-m2xj-4rq9 across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.