Hi,
The following vulnerabilities were published for zookeeper.
CVE-2026-115448[0]:
| 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.
https://www.openwall.com/lists/oss-security/2026/11/03/13
CVE-2026-100235[1]:
| 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.
https://www.openwall.com/lists/oss-security/2026/11/03/9
CVE-2026-100252[2]:
| Improper Authorization vulnerability in Apache ZooKeeper. When SASL
| authentication is enabled on the client port, the server's SASL
| callback handler grants every authorization identity (authzid) that
| a client requests, without checking it against the principal the
| client authenticated as. The server then tries to replace the
| requested identity with a canonical form of the authenticated
| principal, derived from the zookeeper.security.auth_to_local rules.
| If no rule applies to the principal, canonicalization fails and the
| error is only logged. The client-requested authzid then becomes the
| session's SASL identity for all ACL checks. An authenticated client
| whose principal is not covered by the auth_to_local rules can
| therefore claim any SASL identity. With the default rules, this
| includes any Kerberos principal from a realm other than the server's
| default realm, such as a principal from a cross-realm trusted realm.
| The client then gets the permissions granted to that identity in
| sasl ACLs. If the requested identity matches a configured
| zookeeper.superUser, it gets superuser access to the whole data
| tree. Users are recommended to upgrade to version 3.8.8 or 3.9.7,
| which fixes the issue.
https://www.openwall.com/lists/oss-security/2026/11/03/10
CVE-2026-100300[3]:
| Improper handling of exceptional conditions in the quota subsystem
| of Apache ZooKeeper allows an attacker able to write under the
| /zookeeper/quota subtree — unauthenticated on default deployments,
| where that subtree is world-writable — to crash the server's
| critical request-processing thread and render the on-disk data
| directory permanently unbootable. 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.
https://www.openwall.com/lists/oss-security/2026/11/03/11
CVE-2026-100302[4]:
| Allocation of Resources Without Limits or Throttling in the
| multiRead request handler of Apache ZooKeeper allows a remote
| attacker to crash the server (denial of service) with a single small
| request. The multiRead handler places no limit on the number of
| bundled read operations or on the cumulative size of the response it
| builds in memory. Because each operation's result is fully
| materialized and retained before serialization, a request that is
| small on the wire — within the jute.maxbuffer limit — but that
| references a large znode many times can force the server to allocate
| far more heap than the request size implies, exhausting the JVM heap
| and terminating the server with an OutOfMemoryError. Neither
| jute.maxbuffer nor largeRequestMaxBytes prevents this, as both bound
| only the inbound request, not the response. This issue affects
| Apache ZooKeeper from 3.7.0 through 3.9.6. Users are recommended to
| upgrade to version 3.9.7, which enforces configurable limits on the
| multiRead operation count and cumulative response size.
https://www.openwall.com/lists/oss-security/2026/11/03/12
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-115448
https://www.cve.org/CVERecord?id=CVE-2026-115448
[1] https://security-tracker.debian.org/tracker/CVE-2026-100235
https://www.cve.org/CVERecord?id=CVE-2026-100235
[2] https://security-tracker.debian.org/tracker/CVE-2026-100252
https://www.cve.org/CVERecord?id=CVE-2026-100252
[3] https://security-tracker.debian.org/tracker/CVE-2026-100300
https://www.cve.org/CVERecord?id=CVE-2026-100300
[4] https://security-tracker.debian.org/tracker/CVE-2026-100302
https://www.cve.org/CVERecord?id=CVE-2026-100302
Please adjust the affected versions in the BTS as needed.