GHSA-443g-gwgp-49x4: Zebrad Zebrad Vulnerable To Getblocks/getheaders Locator Vulnerability

LOW
CVSS 3.7
CWE-770
Published
Advisory Summary

GHSA-443g-gwgp-49x4 is a LOW (CVSS 3.7) zebrad vulnerable to getblocks/getheaders locator vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) affecting Zebrad libraries in the crates.io ecosystem. The issue involves zebrad vulnerable to getblocks/getheaders locator cpu amplification via uncapped vector length. Remediation is available by upgrading affected packages to version 4.5.0, 8.0.0.

GHSA-443g-gwgp-49x4 at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-443g-gwgp-49x4
Severity LOW
CVSS v3.1 Base Score 3.7
CWE Classification CWE-770: Allocation of Resources Without Limits or Throttling
Affected Product Zebrad
Package Ecosystem crates.io
Published Date
Last Updated

Security Impact

CVSS: 3.7

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability Low (A:L)

How to Fix GHSA-443g-gwgp-49x4

To remediate this vulnerability, upgrade all affected Zebrad dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

zebrad fixed: 4.5.0
Upgrade zebrad to 4.5.0
zebra-chain fixed: 8.0.0
Upgrade zebra-chain to 8.0.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for zebrad

How to Check if You Are Affected

To determine whether your application is affected by GHSA-443g-gwgp-49x4, inspect your project dependencies for Zebrad:

inspect dependencies for zebrad

Analyze the terminal output to locate any version of Zebrad in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.5.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-770: Allocation of Resources Without Limits or Throttling, where the product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. In Zebrad, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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` 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](https://github.com/ZcashFoundation/zebra/pull/10570). Downstream CPU/blocking-pool impact analysis contributed by `@ouicate`.

GHSA-443g-gwgp-49x4 Affected Zebrad Versions

2 component(s)
Fixed Versions:
4.5.08.0.0
Product / Package Ecosystem Affected Versions Fixed Version
zebrad
crates.io
< 4.5.0
4.5.0
zebra-chain
crates.io
< 8.0.0
8.0.0

References

Frequently Asked Questions

What is GHSA-443g-gwgp-49x4?
GHSA-443g-gwgp-49x4 is a security vulnerability in Zebrad involving zebrad vulnerable to getblocks/getheaders locator CPU amplification via uncapped vector length under CWE-770: Allocation of Resources Without Limits or Throttling.
Which Zebrad versions are affected?
Affected versions include releases prior to 4.5.0, 8.0.0 across affected packages: zebrad, zebra-chain.
What version fixes GHSA-443g-gwgp-49x4?
Upgrading to 4.5.0, 8.0.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is zebrad affected?
Yes, zebrad is affected in releases prior to 4.5.0. Upgrade your dependency to 4.5.0 or later.
Is zebra-chain affected?
Yes, zebra-chain is affected in releases prior to 8.0.0. Upgrade your dependency to 8.0.0 or later.
What is the CVSS score of GHSA-443g-gwgp-49x4?
GHSA-443g-gwgp-49x4 has a CVSS v3.1 base score of 3.7 (LOW) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L.
What CWE is associated with GHSA-443g-gwgp-49x4?
GHSA-443g-gwgp-49x4 is classified under CWE-770: Allocation of Resources Without Limits or Throttling (The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.).
How can I check crates.io dependencies for GHSA-443g-gwgp-49x4?
Run the dependency tree command: 'inspect dependencies for zebrad'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-443g-gwgp-49x4",
  "modified" : "2026-07-02T19:34:21Z",
  "published" : "2026-07-02T19:34:21Z",
  "aliases" : [ ],
  "summary" : "zebrad vulnerable to getblocks/getheaders locator CPU amplification via uncapped vector length",
  "details" : "### Am I affected\n\nYou are affected if:\n\n1. You run `zebrad` up to and including `v4.4.1`.\n2. Your node accepts inbound P2P connections.\n\n### Summary\n\nThe `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.\n\nA 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.\n\n### Details\n\nThe `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.\n\nA 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`.\n\nThe 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.\n\n### Patches\n\nPatched 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.\n\n### Workarounds\n\nNo specific workaround is needed. Existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits) constrain the practical impact.\n\n### Impact\n\nUnder 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.\n\n### Credit\n\nVulnerability identified by `@dingledropper`, who submitted the fix in [PR #10570](https://github.com/ZcashFoundation/zebra/pull/10570). Downstream CPU/blocking-pool impact analysis contributed by `@ouicate`.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "zebrad"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "4.5.0"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "zebra-chain"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "8.0.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-443g-gwgp-49x4"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/ZcashFoundation/zebra/pull/10570"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/ZcashFoundation/zebra/commit/8981a1b95d4807cad99e5bb3b94fc8bc723ac033"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/ZcashFoundation/zebra"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-770" ],
    "severity" : "LOW",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-02T19:34:21Z",
    "nvd_published_at" : null
  }
}