CVE-2024-23944

What it actually does

Missing ACL enforcement when persistent watchers trigger on child znodes allows an authenticated client to receive full znode paths for nodes beneath a watched parent without authorization checks.

Why it matters to the business

Organizations running ZooKeeper may leak sensitive identifiers embedded in znode paths such as usernames or login IDs to any client that can attach a watcher to a parent node, increasing risk of reconnaissance or targeted attacks.

How an attack unfolds

An attacker who already possesses read access to a parent znode issues an addWatch command; the server later fires watch events for child znodes without performing ACL checks and delivers the complete child paths to the watcher owner.

How to fix it

Upgrade Apache ZooKeeper to 3.9.2 or 3.8.4; the fixes are present in commit e454e8c7283100c7caec6dcae2bc82aaecb63023 and later releases. Verify the running version after upgrade and restart the ensemble.

How to confirm the fix worked

Confirm the server reports version 3.9.2 or 3.8.4; attempt to attach a persistent watcher as a low-privilege client and verify that child paths under restricted parents are no longer delivered.

Typical attack path

1. Obtain ZooKeeper client credentials with read access to a target parent znode
2. Issue addWatch API call against the parent
3. Wait for or trigger creation/deletion of child znodes
4. Receive watch notifications containing full child paths

How to detect it

Search ZooKeeper server logs for repeated addWatch requests from the same client session followed by watch event deliveries; correlate with client IP or authenticated user to identify watchers attached to parents the user should not traverse.

What your security team should do

• Schedule upgrade to 3.9.2 or 3.8.4 within the next maintenance window
• Audit existing ACLs on znodes that may contain sensitive path segments
• Enable ZooKeeper audit logging to capture addWatch operations
• Review client connection logs for unexpected persistent watchers