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.
Published: 2026-11-04
Score: 6 Medium
EPSS: n/a
KEV: No
Impact: Unauthorized access to ZooKeeper nodes via ACL revocation bypass
Action: Patch Immediately
AI Analysis

Impact

A time‑of‑check to time‑of‑use race condition in the ACL handling of Apache ZooKeeper permits a client to prepare and authorize operations after an ACL change has been submitted but before it is committed. The pending change is not treated as part of the node's outstanding change record, so subsequent requests are checked against the previous ACL yet applied after the revocation. This flaw allows an attacker to write or delete data, or grant themselves persistent permissions, even after the ACL has been revoked, compromising the confidentiality, integrity, and availability of the data tree.

Affected Systems

All deployments of Apache ZooKeeper up to and including version 3.9.6 are vulnerable. This includes installations that transition from the default OPEN_ACL_UNSAFE ACL to a restrictive ACL in a production environment.

Risk and Exploitability

The vulnerability scores a CVSS score of 6, indicating moderate severity. The EPSS score is unavailable, and it is not listed in CISA’s KEV catalog. The likely attack vector involves a remote client that has temporary ACL permissions—particularly an unauthenticated client during a ACL transition—that exploits the short window between setACL submission and commit to perform unauthorized operations.

Generated by OpenCVE AI on November 4, 2026 at 12:21 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade Apache ZooKeeper to version 3.8.8 or 3.9.7, which contains the necessary fix.
  • Restrict or delay the execution of setACL requests during ACL transitions so that all pending changes are fully committed before new operations are authorized.
  • Immediately revoke any OPEN_ACL_UNSAFE ACLs during transitions to a restrictive ACL and audit all client permissions to ensure they match the intended policy.
  • Continuously monitor and audit znode creation, modification, and deletion events for any unauthorized changes that may indicate exploitation.

Generated by OpenCVE AI on November 4, 2026 at 12:21 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 04 Nov 2026 13:00:00 +0000

Type Values Removed Values Added
First Time appeared Apache
Apache zookeeper
Vendors & Products Apache
Apache zookeeper

Wed, 04 Nov 2026 12:30:00 +0000

Type Values Removed Values Added
References

Wed, 04 Nov 2026 11:00:00 +0000

Type Values Removed Values Added
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.
Title Apache ZooKeeper: ACL enforcement bypass allows unauthorized operations to commit after an ACL revocation
Weaknesses CWE-367
References
Metrics cvssV4_0

{'score': 6, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N'}

Subscriptions

Apache Zookeeper
cve-icon MITRE

Status: PUBLISHED

Assigner: apache

Published:

Updated: 2026-11-04T11:09:04.801Z

Reserved: 2026-09-25T15:55:12.809Z

Link: CVE-2026-100235

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-11-04T11:17:04.960

Modified: 2026-11-04T14:10:09.713

Link: CVE-2026-100235

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-11-04T12:45:13Z

Weaknesses
  • CWE-367

    Time-of-check Time-of-use (TOCTOU) Race Condition