Apache ZooKeeper CVE-2026-24281: Reverse DNS fallback risks explained

CVE-2026-24281 is an important severity issue in Apache ZooKeeper where TLS hostname verification can fall back to reverse DNS (PTR) lookups when IP-based Subject Alternative Name (SAN) validation fails. This creates a security gap: if an attacker can influence PTR records and can present a certificate trusted by ZooKeeper’s trust manager, they may be able to impersonate a ZooKeeper peer (server) or a client. (zookeeper.apache.org)

This affects ZooKeeper 3.8.0 to 3.8.5 and 3.9.0 to 3.9.4. Apache recommends upgrading to 3.8.6 or 3.9.5, which introduces a configuration option to turn off reverse DNS lookup for both client and quorum TLS protocols. (zookeeper.apache.org)

Why reverse DNS fallback is risky in identity checks

Reverse DNS (PTR) records are designed for operational convenience, not as an authoritative identity control. In many real environments, PTR ownership sits with:

• an ISP or cloud provider,
• a central DNS team separate from the application owners,
• automation that is optimised for inventory/CMDB accuracy rather than adversarial integrity.

The moment a security decision depends on PTR, you have a dependency on a data source that is often less protected than certificates, private keys, or forward DNS zones.

In this CVE, PTR becomes part of the decision flow for “who am I talking to?”, which is exactly the kind of security-critical action for which reverse DNS should not be used.

What actually goes wrong in ZooKeeper’s TLS verification path

ZooKeeper’s ZKTrustManager performs hostname verification during TLS handshakes. The vulnerable behaviour is:

1. The peer connects using an IP address (common in service-to-service traffic, quorum communications, and some load-balanced designs).
2. ZooKeeper attempts to validate the presented certificate against the expected identity.
3. If IP SAN validation fails, ZKTrustManager falls back to reverse DNS: it performs a PTR lookup on the IP and then attempts hostname verification against the returned name. (zookeeper.apache.org)
4. If an attacker can spoof/control that PTR mapping and can present a trusted certificate for the PTR-derived hostname, the TLS identity check can be satisfied for the wrong endpoint. (zookeeper.apache.org)

Two points matter for realistic risk assessment:

• This is not “PTR spoofing alone”. The attacker also needs a certificate that chains to a CA trusted by the ZooKeeper trust configuration (or otherwise trusted by the deployed truststore). Apache explicitly calls this out, raising the bar. (openwall.com)
• It is still a meaningful bypass in targeted environments. Compromised internal PKI, mis-issued certificates, overly broad enterprise truststores, or certificates minted for “hostnames we own” can turn this into a practical impersonation route.

Exploit mechanics (a concrete scenario)

To make the mechanics tangible, imagine a ZooKeeper ensemble in which quorum members connect over TLS using IPs (or clients connect by IP due to service discovery patterns).

An attacker’s path could look like this:

1. Gain influence over reverse DNS for an IP that ZooKeeper will connect to (or can attract traffic to). This could be through cloud provider PTR settings, compromised DNS infrastructure, or mis-delegation.
2. Set PTR(IP) = zk-prod-1.example.internal (a hostname the attacker can obtain a certificate for, or already has a certificate for).
3. Present a certificate with a SAN/CN that matches zk-prod-1.example.internal, signed by a CA that the ZooKeeper truststore trusts.
4. Trigger a connection that causes IP SAN validation to fail, thereby triggering the PTR fallback path.
5. ZooKeeper accepts connections based on the PTR-derived name, enabling impersonation of a server or client depending on the direction of trust and on whether hostname verification is enabled.

The key takeaway for CISOs and security managers: the failure mode is not “TLS is broken”; it’s “identity binding is weaker than assumed because the software consults PTR when the certificate isn’t suitable for IP identity”.

Who is affected and what is fixed

The Apache securit y advisory lists the impacted ranges and provides

Upgrade first (recommended baseline)

Apache’s recommendation is straightforward: upgrade to 3.8.6 or 3.9.5. (zookeeper.apache.org)

That upgrade includes the backported fix tracked under ZOOKEEPER-4986. (issues.apache.org)

Disable reverse DNS lookup in TLS verification.

In the 3.8.6 line, ZooKeeper introduces:

• ssl.allowReverseDnsLookup
• ssl.quorum.allowReverseDnsLookup

There are also Java system property equivalents:

• zookeeper.ssl.allowReverseDnsLookup
• zookeeper.ssl.quorum.allowReverseDnsLookup (mail-archive.com)

Important operational detail: the documented defaults differ between client and quorum contexts (client defaults to false, quorum defaults to true), so do not assume you are protected unless you set this intentionally. (mail-archive.com)

Treat this as a hardening control, not merely a CVE “toggle”. If your certificates are missing required SAN entries today, fix the certificates rather than leaning on PTR as a compensating control. Apache’s documentation notes reverse DNS lookups are expensive and unnecessary in most cases, and recommends ensuring certificates include the required SANs (including SAN:IP where appropriate). (mail-archive.com)

Validation checklist for security and platform teams

After patching and configuration changes, validate the control in a way that aligns to how ZooKeeper is actually used in your estate:

1. Inventory connection patterns
   
   • Are clients/quorum members connecting by hostname, IP, or both?
   • Are there load balancers or service meshes terminating TLS?

• Audit certificates
  
  • Do server and client certs contain the correct SANs for the way connections are initiated?
  • If you connect by IP, do you have SAN:IP entries?
• Test negative cases
  
  • Attempt a TLS connection where the certificate lacks IP SAN while connecting by IP.
  • Confirm the connection fails (rather than succeeding via PTR-derived identity).
• Review truststores
  
  • Overly broad trust (for example, trusting large internal roots for convenience) increases the probability that an attacker can obtain a “trusted” certificate that matches the spoofed PTR hostname.

What this CVE teaches (beyond ZooKeeper)

CVE-2026-24281 is a classic example of a security principle that keeps reappearing across stacks:

• Fallback logic tends to become “feature logic”.
• “Helpful” resolution behaviours (reverse DNS, auto-discovery, implicit trust) quietly expand the identity boundary.
• Once a control path consults DNS for identity, you inherit DNS’ threat model—even if you still use TLS.

For leadership stakeholders, the governance lesson is simple: require teams to document and test identity assumptions (hostname vs IP, SAN completeness, truststore scope) during platform design reviews, not after a CVE drops.

Quick reference (what to do now)

1. Upgrade ZooKeeper to 3.8.6 or 3.9.5. (zookeeper.apache.org)
2. Set ssl.allowReverseDnsLookup=false and ssl.quorum.allowReverseDnsLookup=false (or the equivalent Java system properties) based on your deployment model and risk appetite. (mail-archive.com)
3. Re-issue certificates with correct SANs (especially SAN:IP if IP connections are unavoidable). (mail-archive.com)
4. Confirm via testing that “connect-by-IP + missing IP SAN” does not succeed via PTR fallback.

If you share your ZooKeeper deployment pattern (client vs quorum TLS, connect-by-hostname vs IP, and whether you manage PTR internally or via a provider), I can suggest a more precise hardening profile and validation plan.