How severe is GHSA-443g-gwgp-49x4?

GHSA-443g-gwgp-49x4 has a CVSS score of 3.7/10, rated LOW. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-443g-gwgp-49x4?

GHSA-443g-gwgp-49x4 affects the following packages: zebrad (crates.io), zebra-chain (crates.io). Ecosystems affected: crates.io.

How do I fix GHSA-443g-gwgp-49x4?

Update zebrad to 4.5.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-443g-gwgp-49x4 is resolved across your whole dependency graph.

How do I detect GHSA-443g-gwgp-49x4 in my crates.io dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for zebrad, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-443g-gwgp-49x4 if there is no patch (or I can't update yet)?

Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.

Is GHSA-443g-gwgp-49x4 actively exploited in the wild?

No public exploit code has been indexed for GHSA-443g-gwgp-49x4 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-443g-gwgp-49x4?

GHSA-443g-gwgp-49x4 has an EPSS (Exploit Prediction Scoring System) score of 0.3%, placing it in the 18th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-443g-gwgp-49x4?

GHSA-443g-gwgp-49x4 is classified as CWE-770 (CWE-770). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-443g-gwgp-49x4 published, and has it been updated?

GHSA-443g-gwgp-49x4 was published on July 2, 2026 and was last updated on October 3, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🦀

🦀 crates.io

Not in CISA KEV

LOW severity

zebrad vulnerable to getblocks/getheaders locator CPU amplification via uncapped vector lengthGHSA-443g-gwgp-49x4

LOWFix: ZcashFoundation/zebra#10570

GHSA-443g-gwgp-49x4 is a low-severity (CVSS 3.7) CWE-770 vulnerability in zebrad. A fix is available for zebrad — see the affected versions and patch details below.

Also known asCVE-2026-104436

Published

Jul 2, 2026

Updated

Oct 3, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

Exploitation data as of Oct 14, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-443g-gwgp-49x4.

EPSS Exploitation Probability

via FIRST.org ↗

0.3%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs18th percentile — riskier than 18% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-443g-gwgp-49x4 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 388,997 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected

🦀zebrad🦀zebra-chain

Real-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

Am I affected

You are affected if:

You run zebrad up to and including v4.4.1.
Your node accepts inbound P2P connections.

Summary

The read_getblocks and read_getheaders codec paths accepted block locator vectors up to approximately 65,535 entries (the generic TrustedPreallocate ceiling derived from MAX_PROTOCOL_MESSAGE_LEN), rather than the protocol-specification limit of 101 entries (matching zcashd's MAX_LOCATOR_SZ). Each entry in the locator vector triggers a per-hash chain lookup (HashMap::contains_key + RocksDB::contains_hash) in find_chain_intersection on a tokio blocking-pool thread.

A single maximally-sized getblocks message occupies one blocking-pool thread for approximately 10–65ms. Under sustained load from multiple peers, this can degrade state-read performance for block validation, RPC, and mempool lookups.

Details

The read_headers codec path already implements the correct pattern: it reads the CompactSize count, validates against MAX_HEADERS_PER_MESSAGE = 160 before deserialization, and rejects oversized messages. The read_getblocks and read_getheaders paths were missing this pre-deserialization count check and instead relied on the generic block::Hash::max_allocation() bound, which allows (MAX_PROTOCOL_MESSAGE_LEN - 1) / 32 = 65,535 hashes.

A legitimate block locator is logarithmic in chain length (approximately 30 hashes for the current ~3M-block Zcash chain). Zebra's own send-side cap is MAX_FIND_BLOCK_HASHES_RESULTS = 500.

The practical impact requires significant attacker bandwidth (approximately 2 MiB per request) and multiple Sybil peers to meaningfully degrade the blocking pool, which limits real-world exploitability.

Patches

Patched in Zebra 4.4.2. The fix caps block::Hash::max_allocation() at MAX_BLOCK_LOCATOR_LENGTH = 101, matching zcashd's MAX_LOCATOR_SZ. This causes the deserializer to reject oversized locators before any allocation or iteration occurs.

Workarounds

No specific workaround is needed. Existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits) constrain the practical impact.

Impact

Under sustained load from multiple Sybil peers, oversized locator vectors can occupy blocking-pool threads and degrade state-read performance. The effect is bounded by connection limits and requires significant attacker bandwidth.

Credit

Vulnerability identified by @dingledropper, who submitted the fix in PR #10570. Downstream CPU/blocking-pool impact analysis contributed by @ouicate.

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
🦀crates.io	`zebrad`	all versions	4.5.0`cargo update -p zebrad --precise 4.5.0`
🦀crates.io	`zebra-chain`	all versions	8.0.0`cargo update -p zebra-chain --precise 8.0.0`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for zebrad, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update zebrad to 4.5.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-443g-gwgp-49x4 is resolved across your whole dependency graph.
Workarounds
Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.

Frequently Asked Questions

### 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. ### Summary The `read_getblocks` and `read_getheaders` codec paths accepted block locator vectors up to approximately 65,535 entries (the generic `TrustedPreallocate` ceiling derived from `MAX_PROTOCOL_MESSAGE_LEN`), rather than the protocol-specification limit of 101 entries (matching zcashd's `MAX_LOCATOR_SZ`). Each entry in the locator vector triggers a per-hash chain lookup (`HashMap::contains_key` + `RocksDB::contains_hash`) in `find_chain_intersection