CVE-2026-100235: Apache ZooKeeper: ACL enforcement bypass allows unauthorized operations to commit after an ACL revocation
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 OPENACLUNSAFE 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.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache ZooKeeperto a version that resolves this vulnerability.Fixed in 3.8.8 - Upgrade
Upgrade
Apache ZooKeeperto a version that resolves this vulnerability.Fixed in 3.9.7
Event History
Frequently Asked Questions
Who can exploit this issue?
A client must have the relevant permission under the ACL in effect before revocation and submit an operation in the interval after setACL is submitted but before it commits. During a transition from OPEN_ACL_UNSAFE to a restrictive ACL, an unauthenticated client can exploit that interval.
What could an attacker do during the race window?
They can commit operations that require permissions they are losing, including writes or deletes. A client losing ACL-administration capability may also re-grant itself full permissions, causing the access to persist after the intended revocation.
Which ZooKeeper versions are affected and what versions fix it?
Apache ZooKeeper versions up to and including 3.9.6 are affected. Upgrade to 3.8.8 or 3.9.7 to obtain the fix.