{"id":"CVE-2026-100235","kind":"vulnerability","aliases":["CVE-2026-100235"],"related":[],"title":"Apache ZooKeeper: setACL race lets clients keep permissions after revocation","description":"Incorrect authorization due to a time-of-check to time-of-use (TOCTOU) race condition in the setACL request handling of Apache ZooKeeper.\n\nWhen 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.\n\nThis 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.","summary":"When a ZooKeeper node's ACL is changed with setACL, requests prepared during the change are checked against the old ACL but applied after it takes effect. A client that holds a permission can use this window to write, delete, or re-grant itself access after losing it.","severity":"medium","cvss":6.0,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["hadoop","kafka","package","self-hosted","zookeeper"],"not_affected_if":["default-config","no-acl-changes"],"how_to_check":"- Check the installed ZooKeeper version, for example `zkServer.sh version` or the `zookeeper` jar version in your deployment.\n- Look for nodes using `OPEN_ACL_UNSAFE` that are being moved to a restrictive ACL, since the description says the window is exploitable during that transition.","fix":"- Apache ZooKeeper `3.8.8` or `3.9.7`; versions up to and including `3.9.6` are affected.","status":"open","published_at":"2026-11-04T11:17:04+00:00","first_seen_at":"2026-11-04T11:26:45+00:00","triaged_at":"2026-11-04T11:27:36+00:00","updated_at":"2026-11-04T11:27:36+00:00","category":"package","confidence":0.7,"triage":{"at":"2026-11-04T11:27:36Z","model":"claude-haiku-5-5","output":{"fix":"- Apache ZooKeeper `3.8.8` or `3.9.7`; versions up to and including `3.9.6` are affected.","reach":"network","title":"Apache ZooKeeper: setACL race lets clients keep permissions after revocation","impact":"medium","summary":"When a ZooKeeper node's ACL is changed with setACL, requests prepared during the change are checked against the old ACL but applied after it takes effect. A client that holds a permission can use this window to write, delete, or re-grant itself access after losing it.","audience":"businesses","category":"package","nicknames":[],"who_cares":["zookeeper","kafka","hadoop","self-hosted"],"confidence":0.7,"fix_status":"available","needs_auth":"unknown","worst_case":"Client keeps write or delete access after ACL revocation","analyst_note":"","how_to_check":"- Check the installed ZooKeeper version, for example `zkServer.sh version` or the `zookeeper` jar version in your deployment.\n- Look for nodes using `OPEN_ACL_UNSAFE` that are being moved to a restrictive ACL, since the description says the window is exploitable during that transition.","plain_action":"","needs_analyst":false,"not_affected_if":["default-config","no-acl-changes"],"who_is_affected":"Deployments running Apache ZooKeeper up to and including 3.9.6 that change node ACLs with setACL, especially those moving from the default OPEN_ACL_UNSAFE to a restrictive ACL, where any unauthenticated client can exploit the window during the transition. Deployments that never change ACLs on live nodes are less exposed.","user_interaction":"no","needs_special_setup":"unknown","severity_if_unknown":"medium"},"cost_usd":0.000739,"input_tokens":4385,"output_tokens":600,"severity_before":"medium"},"analyst_status":null,"analyst_note":null,"search":"'-100235':13A,16A '-2026':12A,15A '3.8.8':246C '3.9.6':238C '3.9.7':248C 'access':69B,193C 'acl':29B,44B,101C,147C,157C,213C,215C,219C 'affect':231C 'apach':1A,95C,232C 'appli':46B,150C 'author':73C,128C 'chang':31B,38B,103C,108C,117C,158C 'check':40B,80C,140C 'client':6A,52B,163C,222C 'commit':137C,186C 'condit':88C 'current':165C 'cve':11A,14A 'data':153C 'default':211C 'defeat':203C 'delet':63B,189C 'deploy':207C 'due':74C 'effect':50B,161C 'exampl':185C 'exploit':224C 'fix':250C 'full':199C 'grant':67B,197C 'hadoop':17B 'handl':93C 'hold':54B,166C 'host':22B 'includ':237C 'incorrect':72C 'issu':230C,252C 'kafka':18B 'keep':7A 'let':5A 'lose':71B,191C 'node':27B,99C,121C 'old':43B 'open':212C 'oper':175C 'outstand':116C 'packag':19B 'pend':107C 'perform':174C 'permiss':8A,56B,168C,178C,200C 'persist':202C 'pre':145C 'pre-revoc':144C 'prepar':35B,126C 'previous':143C 'publish':111C 'race':4A,87C 're':66B,196C 're-grant':65B,195C 'recommend':241C 'record':118C 'request':34B,92C,123C 'requir':176C 'restrict':218C 'revoc':10A,146C,183C,205C 'self':21B 'self-host':20B 'server':114C 'setacl':3A,33B,91C,105C,131C 'submit':133C 'take':49B 'taken':160C 'therefor':139C 'time':78C,83C 'time-of-check':77C 'time-of-us':82C 'toctou':86C 'transit':208C,228C 'tree':154C 'unauthent':221C 'unsaf':214C 'upgrad':243C 'use':58B,85C,170C 'user':239C 'version':245C 'via':104C 'window':60B,172C 'write':62B,187C,192C 'yet':148C 'zookeep':2A,23B,26B,96C,233C","nicknames":[],"mitigations":[],"who_affected":"Deployments running Apache ZooKeeper up to and including 3.9.6 that change node ACLs with setACL, especially those moving from the default OPEN_ACL_UNSAFE to a restrictive ACL, where any unauthenticated client can exploit the window during the transition. Deployments that never change ACLs on live nodes are less exposed.","tier":"C","verified":{},"analyst_revisit_at":null,"fix_status":"available","audience":"businesses","plain_action":null,"pkeys":[],"ptokens":[],"labels":["hadoop","kafka","medium","package","selfhosted","zookeeper"],"campaign_type":null,"first_public_at":"2026-11-04T11:17:04+00:00","kev":null,"cvss_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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","cvss_by":"security@apache.org","poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-100235","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-100235","severity":null,"published_at":"2026-11-04T11:17:04+00:00","modified_at":"2026-11-04T11:17:04+00:00","first_seen_at":"2026-11-04T11:26:45+00:00","fetched_at":"2026-11-04T11:26:45+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}