Apache ZooKeeper CVE-2026-100302

Exploitation requires an authenticated client session to the ZooKeeper ensemble (CVSS PR:L) and the existence of at least one sizable znode that can be referenced repeatedly. The specific trigger is a multiRead request that bundles many bundled read operations - or many references to a large znode - because the multiRead handler imposes no limit on the operation count or on the cumulative in-memory response size, and each result is fully materialized and retained before serialization. The request itself stays small on the wire and within the jute.maxbuffer limit, so neither jute.maxbuffer nor largeRequestMaxBytes limits exploitation (both bound only the inbound request, not the response). Limiting factors: a valid client connection is needed, impact is availability-only (server crash), and ZooKeeper is typically deployed on internal/trusted networks rather than exposed externally.

The vendor-supplied CVSS 4.0 vector (7.1, high: AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H) frames this as a network-reachable, low-complexity, availability-only flaw requiring low privileges (PR:L) - i.e. an authenticated client connection rather than an anonymous one. The impact is confined to availability (VA:H); there is no confidentiality or integrity exposure. The vuln.today decision label is 'awaiting_data', and no EPSS probability, CISA KEV listing, or POC is present in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. These signals are internally consistent rather than conflicting: a high base score driven purely by a crash-the-server effect, with no exploitation telemetry to elevate it. The realistic priority is moderate-but-notable: a single small, standards-compliant request can terminate the JVM with OutOfMemoryError, and because ZooKeeper is a coordination kernel underpinning systems like Kafka, Hadoop, and HBase, a crash can cascade into dependent clusters. Mitigating factors are that exploitation requires an authenticated client session and that ZooKeeper ensembles are usually deployed on internal/trusted networks rather than exposed to the internet. Note that the standard jute.maxbuffer and largeRequestMaxBytes controls do NOT bound this, since they limit only the inbound request, not the server-built response.

An attacker able to open an authenticated client session to the ZooKeeper ensemble sends a single small multiRead request that bundles many read operations all referencing the same large znode. Because each result is fully materialized and retained in heap before serialization, the response balloons far beyond the on-the-wire request size, exhausting the JVM heap and crashing the server with OutOfMemoryError. No public exploit was identified at time of analysis; the attack is low-complexity (AC:L) and network-reachable (AV:N) but requires a valid client connection.