CVE-2026-100235 in ZooKeeper
Summary
by MITRE • 11/04/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in Apache ZooKeeper represents a critical security flaw rooted in a time-of-check to time-of-use race condition within the access control list management subsystem. This specific implementation error occurs during the processing of setACL requests, where the system fails to atomically update both the authorization state and the pending change record that tracks outstanding operations for a given node. In distributed systems like ZooKeeper, maintaining consistency between immediate permission checks and persistent data modifications is paramount. When an administrator or client initiates a request to modify the ACLs of a specific znode, the server begins processing this administrative command but does not immediately propagate the new access restrictions to the queue of pending changes associated with that node. This creates a temporal window where the authorization logic remains stale relative to the actual state of the data tree being modified by concurrent operations.
From a technical perspective, the core issue lies in the sequencing of events during transaction commit phases. When a setACL request is submitted, it triggers a change in the server's access control configuration for that node. However, any subsequent requests that were already prepared and authorized under the previous ACL rules are not re-evaluated against the new restrictions before being applied to the data tree. Consequently, these operations pass their initial authorization checks based on legacy permissions but are executed after the revocation has technically taken effect in the broader system state. This discrepancy allows a client holding valid permissions at the moment of submission to perform actions that should be prohibited under the newly enforced rules once those actions commit. The race condition exploits the gap between the logical check of privileges and the physical application of changes, effectively bypassing the intended security boundaries established by the updated ACLs.
The operational impact of this vulnerability is severe, particularly in environments undergoing a transition from permissive to restrictive access policies. By default, ZooKeeper nodes often utilize an OPEN_ACL_UNSAFE configuration which grants broad permissions to all clients. When administrators attempt to tighten these controls by applying more restrictive ACLs, unauthenticated or previously authorized malicious actors can exploit the TOCTOU window to retain unauthorized access. Specifically, a client that has been granted write or delete privileges can submit such operations just before their rights are revoked. These operations will be processed and committed even though they violate the new security policy. Furthermore, an attacker could leverage this flaw to re-grant themselves full permissions on a node after having lost them, thereby persistently defeating revocation efforts. This undermines the integrity of access control mechanisms and can lead to unauthorized data modification, deletion, or privilege escalation within the ZooKeeper ensemble.
This vulnerability aligns with CWE-367, which defines time-of-check to time-of-use race conditions as a class of software errors where security checks are performed at one point in time but rely on system state that may change before the action is completed. In the context of MITRE ATT&CK, this behavior facilitates techniques associated with privilege escalation and defense evasion, specifically under tactics such as Persistence or Impact depending on whether the attacker uses the window to maintain access or disrupt services. The ability to bypass ACL revocation effectively allows an adversary to persist in a compromised environment despite administrative countermeasures being applied.
To mitigate this risk, organizations running Apache ZooKeeper must upgrade immediately to version 3.8.8 or 3.9.7, where the atomicity of setACL operations has been corrected to ensure that pending changes are properly synchronized with updated access control states. Until an upgrade is feasible, administrators should exercise extreme caution when modifying ACLs on active nodes and consider implementing additional monitoring for unusual patterns of write or delete activity during permission transitions. It is also advisable to review existing security policies to minimize the window of exposure by reducing reliance on broad default permissions wherever possible. Regular audits of access control configurations combined with strict adherence to upgrade schedules are essential strategies for maintaining robust security postures in distributed coordination services.