{"items":[{"id":"NVI-00017810","kind":"vulnerability","title":"zebrad vulnerable to getblocks/getheaders locator CPU amplification via uncapped vector length","revision":1,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected."],"lifecycle":"active","identifiers":["GHSA-443g-gwgp-49x4"],"plain_summary":"GitHub lists this reviewed advisory for zebrad, zebra-chain. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.","source_ids":["sr-6b1342a6bb8bf47ce67699b2acdffb59"],"action_type":"investigate","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null}],"schema_version":"1.1.0","source_metrics":[{"kind":"CVSS","as_of":"2026-07-02T19:34:21.000Z","value":"3.7 low","meaning":"GitHub source severity; exploitability and local consequence require separate evidence.","source_id":"sr-6b1342a6bb8bf47ce67699b2acdffb59"}],"why_it_matters":"Published affected context helps an owner decide what evidence to gather. This report has not examined your application.","related_sources":[{"id":"sr-6b1342a6bb8bf47ce67699b2acdffb59","url":"https://github.com/advisories/GHSA-443g-gwgp-49x4","basis":"vendor_advisory","notes":"GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.","title":"GHSA-443g-gwgp-49x4","publisher":"GitHub Advisory Database","observed_at":"2026-11-05T03:47:42.887Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-6b1342a6bb8bf47ce67699b2acdffb59"],"technology":"zebrad","known_exclusions":[],"conditions_summary":"### 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 ins","public_affected_ranges":["< 4.5.0"]},{"certainty":"source_listed","source_ids":["sr-6b1342a6bb8bf47ce67699b2acdffb59"],"technology":"zebra-chain","known_exclusions":[],"conditions_summary":"### 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 ins","public_affected_ranges":["< 8.0.0"]}],"null_published_at":"2026-11-05T19:10:21.470Z","source_updated_at":"2026-07-02T19:34:21.000Z","source_disclosed_at":"2026-07-02T19:34:21.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"First indexed by Null; source disclosure date is shown separately.","null_first_observed_at":"2026-11-05T03:47:42.887Z"}],"next_cursor":null,"snapshot_revision":"42594"}