Skip to main content
← Vulnerabilities

Apache ZooKeeper: ACL enforcement bypass allows unauthorized operations to commit after an ACL revocation

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

6.0MediumCNA
Exploited
No known exploitation
Fix
No fix listed
Who is exposed
Not reported
24Pcve.now Index 24 of 100 · methodology v3 · provisional
  • Exploitation?/40Exploitation: unknown (data gap). No CISA SSVC exploitation rating yet
  • Exposure3/25Reachable over the network · Data gap: No advisory context yet
  • Reach10/20Affects Maven packages
  • Severity6/10CVSS 6.0
  • No patch5/5No patch listed yet

What would change the score

  • Would score about 79 if added to CISA KEV
  • Would score about 74 if CISA's SSVC rates exploitation active
  • Would score about 43 if advisories confirm default setups are exposed

CVE-2026-100235 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It is rated CVSS 6.0 (medium) and affects Apache ZooKeeper; no fixed version is listed yet.

Published
Last modified
Published
Not listed in CISA KEV
24/100 · provisional
None on Exploit-DB, Metasploit or GitHub

Summary

Apache ZooKeeper, a coordination service for distributed systems, can let a client that already has access perform writes or deletes after its permission has been revoked, by exploiting a timing window during ACL changes. The attack can be carried out remotely by a client that needs to log in with low privileges, and it allows the attacker to modify data they should no longer be able to change.

Read the original description

Incorrect authorization due to a time-of-check to time-of-use (TOCTOU) race condition in the setACL request handling of Apache ZooKeeper. When a node's ACL is changed via setACL, the pending change is not published to the server's outstanding change record for that node. Any request that is prepared (and authorized) after the setACL is submitted but before it commits is therefore checked against the previous, pre-revocation ACL, yet is applied to the data tree after the ACL change has taken effect. A client that currently holds a permission can use this window to perform operations requiring that permission through and after its revocation — for example, committing writes or deletes after losing write access, or re-granting itself full permissions, which persistently defeats the revocation. In deployments transitioning from the default OPEN_ACL_UNSAFE ACL to a restrictive ACL, any unauthenticated client can exploit this during the transition. This issue affects Apache ZooKeeper up to and including 3.9.6. Users are recommended to upgrade to version 3.8.8 or 3.9.7, which fixes the issue.

Impact

  • Widely used

    175 packages depend on org.apache.zookeeper:zookeeper.Source: deps.dev

Timeline

  1. CVE published
  2. First seen by cve.now
  3. Record last updated

Affected versions

  • org.apache.zookeeper:zookeeperMaven

    From 3.9.0 · through 3.9.6; From 3.8.0 · through 3.8.7

Evidence 2

  1. Advisory
  2. Link

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

FAQ

Questions about CVE-2026-100235

Is CVE-2026-100235 being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data

Which versions are affected by CVE-2026-100235?

org.apache.zookeeper:zookeeper (Maven): from 3.9.0 through 3.9.6; from 3.8.0 through 3.8.7.Source: cve.now feed data