Apache ZooKeeper CVE-2026-100235

Exploitation requires an in-flight setACL operation on a target znode and the attacker's request to be prepared/authorized within the window after that setACL is submitted but before it commits (the TOCTOU race, reflected as AT:P). In the general case the attacker must already hold the permission being revoked (PR:L) - e.g. a client losing write access that continues to issue writes/deletes or re-grants itself permissions. The vendor identifies a specific unauthenticated case: deployments transitioning from the default OPEN_ACL_UNSAFE ACL to a restrictive ACL, where any unauthenticated client can exploit the transition window. Limiting factors: there must be an active ACL change to race, the window is timing-bound, and impact is limited to integrity (unauthorized writes/deletes/ACL changes) - no confidentiality or availability impact is claimed. Updating to 3.8.8 or 3.9.7 is the fix.

This is a moderate-severity authorization-bypass (TOCTOU race) in Apache ZooKeeper's setACL handling, and the available signals point to a real but conditional risk rather than a drop-everything emergency. The only supplied CVSS is the vendor's CVSS 4.0 base score of 6.0 (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): network-reachable, low attack complexity, but with Attack Requirements Present (AT:P) - consistent with the race-condition window the description relies on - and low privileges required (PR:L), impacting integrity only (VI:H; VC/VA = N). No CVSS 3.1 vector, EPSS score, or SSVC exploitation/automatable values were provided, so probabilistic exploitation likelihood cannot be quantified from this input. The vuln.today Decision label is 'awaiting_data', i.e. not yet prioritized as act_now or emergency. There is no CISA KEV listing and no verified exploit code in the references (only the oss-security advisory and the vendor site), so exploitation status is: no public exploit identified at time of analysis. A notable conflict/nuance: the official vector encodes PR:L (authenticated, holding some permission), yet the description explicitly states that in deployments transitioning from the default OPEN_ACL_UNSAFE ACL to a restrictive ACL, any unauthenticated client can exploit the window - so the PR:L metric understates the worst-case (transition) scenario, where authentication is effectively not required. Net: prioritize for patching on ensembles that undergo ACL tightening or rely on ACL revocation for security, but the AT:P race requirement and the need for an in-flight setACL limit opportunistic mass exploitation.

An administrator tightens a znode's ACL via setACL (for example revoking a client's write access, or migrating a tree from OPEN_ACL_UNSAFE to a restrictive ACL). A client that still held the old permission submits write/delete/setACL requests timed to land in the window after the setACL is submitted but before it commits; those requests are authorized against the stale pre-revocation ACL yet applied after the change takes effect, letting the client persist writes or even re-grant itself full permissions. No public exploit code is identified at time of analysis; exploitation depends on hitting the race window (AT:P) around an active ACL change.