CVE-2026-115448: Apache ZooKeeper: Unbounded recursion in snapshot serialization allows a client to render the server unrecoverable
Uncontrolled recursion in Apache ZooKeeper. The server serializes its data tree to a snapshot by recursing one stack frame per znode level, with no depth bound. A client permitted to create znodes (the default root ACL is open) can build a chain of nested znodes deep enough that taking a snapshot exhausts the JVM stack and kills the snapshot thread; sizes stay within jute.maxbuffer, so existing limits do not prevent it. This is a denial of service that becomes persistent: on restart the server rebuilds the deep tree from its transaction log and fails again while taking the startup snapshot, so it does not return to service, and recovery can entail data loss. The same log affects a leader and its followers, so it can spread across an ensemble.
This issue affects Apache ZooKeeper 3.8.0 through 3.8.7 and 3.9.0 through 3.9.6. Users are recommended to upgrade to 3.8.8 or 3.9.7, which fix the issue. As a workaround, use ACLs and authentication to restrict znode creation rather than relying on the default open root ACL.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache ZooKeeperto a version that resolves this vulnerability.Fixed in 3.8.8 - Configuration
Use ACLs and authentication to restrict znode creation instead of relying on the default open root ACL.
Apache ZooKeeper znode creation ACLs and authentication = Restrict znode creation to authenticated and authorized clients
Event History
Frequently Asked Questions
Which deployments are most exposed to this issue?
ZooKeeper 3.8.0 through 3.8.7 and 3.9.0 through 3.9.6 are affected. Deployments using the default open root ACL are especially exposed because an unauthenticated client can create the deeply nested znodes needed to trigger the failure.
What does an attacker need to exploit it?
The attacker needs permission to create znodes and network access to the ZooKeeper server. No authentication or special privileges are required when the default root ACL remains open.
Why can this outage persist after restarting ZooKeeper?
The deep znode tree is retained in the transaction log. During restart, ZooKeeper rebuilds that tree and can fail again when taking its startup snapshot, preventing it from returning to service and potentially requiring recovery involving data loss.
What can be done if an upgrade cannot be applied immediately?
Use authentication and ACLs to restrict who can create znodes, rather than relying on the default open root ACL. Upgrade affected 3.8 installations to 3.8.8 or affected 3.9 installations to 3.9.7 when possible.
Can this affect an entire ZooKeeper ensemble?
Yes. The same transaction log content can affect both the leader and followers, allowing the condition to spread across the ensemble.