DEBIAN-CVE-2026-100252: Debian/zookeeper vulnerability
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.authtolocal 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 authtolocal 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.
Affected Software
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 - Upgrade
Upgrade
Apache ZooKeeperto a version that resolves this vulnerability.Fixed in 3.9.7
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments with SASL authentication enabled on the ZooKeeper client port are affected when an authenticated client's principal is not covered by the configured zookeeper.security.auth_to_local rules. Under the default rules, this can include Kerberos principals from realms other than the server's default realm, including cross-realm trusted realms.
What must an attacker be able to do to exploit it?
The attacker must authenticate to the ZooKeeper client port using a principal for which no auth_to_local rule applies. They can then request a SASL authorization identity that has permissions in sasl ACLs and receive those permissions.
How severe can the resulting access be?
Access is limited by the permissions assigned to the identity the client claims in sasl ACLs. If the requested identity matches a configured zookeeper.superUser, the attacker receives superuser access across the entire data tree.
What is the recommended remediation?
Upgrade ZooKeeper to version 3.8.8 or 3.9.7, which fix the issue. Ensure zookeeper.security.auth_to_local rules cover the principals that are permitted to authenticate.