CVE-2026-24281: Apache ZooKeeper Auth Bypass Vulnerability

CVE-2026-24281 Overview

CVE-2026-24281 is an improper certificate validation flaw [CWE-295] in Apache ZooKeeper's ZKTrustManager. The hostname verification logic falls back to a reverse DNS (PTR) lookup when IP Subject Alternative Name (SAN) validation fails. An attacker who controls or spoofs PTR records can impersonate ZooKeeper servers or clients using a certificate that matches the PTR name. Exploitation still requires the attacker to present a certificate trusted by ZKTrustManager, which raises the bar for successful abuse. Apache addressed the issue in ZooKeeper 3.8.6 and 3.9.5 by adding a configuration option to disable reverse DNS lookup in the client and quorum protocols.

Critical Impact

Attackers controlling PTR records and holding a trusted certificate can impersonate ZooKeeper peers, breaking confidentiality and integrity of cluster communications.

Affected Products

• Apache ZooKeeper versions prior to 3.8.6 (3.8.x branch)
• Apache ZooKeeper versions prior to 3.9.5 (3.9.x branch)
• Deployments using ZKTrustManager with TLS-secured client or quorum protocols

Discovery Timeline

• 2026-03-07 - CVE-2026-24281 published to NVD
• 2026-03-10 - Last updated in NVD database

Technical Details for CVE-2026-24281

Vulnerability Analysis

Apache ZooKeeper uses ZKTrustManager to validate TLS peer identities during client and quorum communications. When the remote peer presents a certificate, the manager attempts to match the peer's IP address against the certificate's IP SAN entries. If the IP SAN check fails, the implementation does not abort the handshake. Instead, it performs a reverse DNS (PTR) lookup on the peer's IP and re-attempts hostname validation against the resolved name.

This fallback behavior introduces a trust dependency on DNS infrastructure. An attacker who can manipulate PTR responses, such as through a compromised resolver, a malicious authoritative server for an in-addr.arpa zone, or DNS spoofing, can force ZKTrustManager to validate against an attacker-controlled name. If the attacker also holds a certificate issued for that PTR name and chained to a CA trusted by the ZooKeeper truststore, the TLS session succeeds.

Root Cause

The root cause is insecure fallback logic in certificate hostname verification [CWE-295]. The trust manager treats reverse DNS results as authoritative identity material, even though PTR records are not bound to the certificate's intended IP or DNS SAN scope. This violates RFC 6125 guidance, which discourages reverse DNS as a means of TLS identity verification.

Attack Vector

Exploitation requires network position to influence DNS responses observed by the ZooKeeper node and possession of a certificate trusted by the target's ZKTrustManager. The attacker injects a PTR record mapping their IP to a hostname covered by the certificate, then initiates or intercepts a quorum or client connection. The trust manager fails IP SAN validation, falls back to PTR resolution, and accepts the spoofed identity. The complexity is high because the certificate must already chain to a trusted CA, but the impact spans server impersonation, client impersonation, and quorum membership abuse.

No public proof-of-concept code is available for this issue. Technical specifics are described in the Apache Mailing List Discussion and the Openwall OSS-Security Update.

Detection Methods for CVE-2026-24281

Indicators of Compromise

• Unexpected TLS handshakes on ZooKeeper client port 2181 or quorum ports 2888/3888 from hosts outside the documented cluster inventory.
• DNS query logs showing PTR lookups from ZooKeeper nodes immediately preceding successful TLS sessions with unfamiliar peers.
• New or unrecognized certificate subjects or issuer chains presented to ZKTrustManager that do not match the cluster's certificate management baseline.

Detection Strategies

• Audit ZooKeeper TLS handshake logs for cases where IP SAN validation failed but the connection still succeeded via hostname fallback.
• Correlate authoritative DNS changes for in-addr.arpa zones with subsequent ZooKeeper authentication events.
• Inventory issued certificates and flag any certificate whose CN or DNS SAN resolves to a host that should not participate in ZooKeeper communications.

Monitoring Recommendations

• Forward ZooKeeper server and quorum logs to a centralized analytics platform and alert on TLS validation anomalies.
• Monitor egress DNS traffic from ZooKeeper hosts and alert on PTR responses pointing to external or unexpected domains.
• Track CA-issued certificates via Certificate Transparency feeds for names that resolve into your ZooKeeper network ranges.

How to Mitigate CVE-2026-24281

Immediate Actions Required

• Upgrade Apache ZooKeeper to version 3.8.6 or 3.9.5 across all ensemble members and clients.
• Enable the new configuration option introduced in the patch to disable reverse DNS lookup in client and quorum protocols.
• Rotate or constrain CA trust in ZKTrustManager truststores so only certificates issued for legitimate ZooKeeper nodes are trusted.

Patch Information

Apache published fixes in ZooKeeper 3.8.6 and 3.9.5. The patch adds a configuration flag that disables the PTR-based hostname fallback for both client and quorum TLS validation. Details are documented in the Apache Mailing List Discussion.

Workarounds

• Issue certificates with explicit IP SANs that match every ZooKeeper node address, eliminating reliance on hostname fallback.
• Restrict the ZooKeeper truststore to a private internal CA that signs only cluster member certificates.
• Segment ZooKeeper traffic onto a dedicated network with strict firewall rules so only known peers can initiate TLS handshakes.

# Configuration example: disable reverse DNS in ZooKeeper TLS validation
# Apply on each ensemble member after upgrading to 3.8.6 or 3.9.5
# Reference: https://lists.apache.org/thread/088ddsbrzhd5lxzbqf5n24yg0mwh9jt2

# zoo.cfg
ssl.hostnameVerification=true
ssl.clientHostnameVerification.reverseDnsLookup=false
ssl.quorum.hostnameVerification=true
ssl.quorum.hostnameVerification.reverseDnsLookup=false