The zebrad client versions up to and including 4.4.1 accept getblocks and getheaders messages with block locator vectors far exceeding the protocol-specified maximum of 101 entries, allowing up to 65,535 entries due to missing pre-deserialization count checks. Each locator entry triggers a costly chain lookup on a blocking-pool thread, causing CPU amplification and potential degradation of state-read performance under sustained load from multiple peers. The vulnerability is mitigated by the patch in zebrad 4.4.2, which caps the maximum locator vector length to 101, rejecting oversized messages before processing. Exploitation requires high bandwidth and multiple Sybil peers, and existing connection limits and load shedding reduce practical exploitability.

The vulnerability can cause blocking-pool threads to be occupied for 10–65ms per oversized getblocks message, degrading performance of block validation, RPC, and mempool lookups under sustained attack from multiple peers. There is no direct confidentiality, integrity, or availability compromise beyond degraded performance. The impact is limited by connection limits and the bandwidth required to send large messages, resulting in a low severity impact.

A patch is available in zebrad version 4.4.2 that enforces the correct maximum locator vector length of 101 entries, rejecting oversized messages before deserialization. Users should upgrade to version 4.4.2 or later to remediate this vulnerability. No additional workarounds are necessary as existing backpressure and connection limit mechanisms constrain the impact.