An unauthenticated attacker can inject arbitrary fake log lines into Apache ZooKeeper's operational log by sending a crafted addauth("ensemble", ...) request containing newline characters (\n). When the ensemble name doesn't match, EnsembleAuthenticationProvider.handleAuthentication() logs the raw, unsanitized name via LOG.warn(). Because SLF4J's {} placeholder preserves embedded newlines, the attacker can forge complete log entries — with arbitrary timestamps, log levels, class names, and messages — that are visually indistinguishable from genuine ZooKeeper log output.
This issue affects Apache ZooKeeper: from 3.9.0 through 3.9.5, from 3.8.0 through 3.8.6.
Users are recommended to upgrade to version 3.8.7 or 3.9.6, which fixes the issue.
When audit logging is enabled (zookeeper.audit.enable=true), an unauthenticated attacker can inject arbitrary fields into Apache ZooKeeper's audit log by sending a digest authentication request with tab characters (\t) embedded in the username. Because the audit log uses tab-separated key=value format, the injected tabs are parsed as legitimate field separators, allowing the attacker to spoof audit results (e.g., injecting result=success), forge operation types, and corrupt forensic evidence.
A log injection vulnerability in Apache ZooKeeper allows a client that can call setACL to inject forged key-value fields into zookeeperaudit.log. When audit logging is enabled, the server serializes attacker-controlled digest ACL ids into the acl= audit field without escaping tab characters. Because audit events are emitted as tab-separated key=value records, a crafted ACL id can make one successful setAcl event appear to contain forged fields such as operation=delete and znode=/forged. This undermines the integrity of downstream audit parsing, alerting, and incident response.
This issue affects Apache ZooKeeper: from 3.9.0 through 3.9.5, from 3.8.0 through 3.8.6.
Users are recommended to upgrade to version 3.9.6 or 3.8.7, which fixes the issue.
The deleteContainer opcode (0x14/20) is processed without verifying the caller's ACL permissions, allowing any authenticated client to delete specific znodes in the data tree regardless of the ACL restrictions on the znode or its parent. This opcode is considered internal-only and the official client doesn't have API for it, but a client that can open a plain TCP session on the ZooKeeper client port (2181 by default) - with NO authentication and NO ACL permissions - can delete any empty persistent znode (including regular persistent nodes, container nodes, and TTL nodes) by issuing the raw protocol OpCode deleteContainer (20). The deleteContainer request path completely skips both the session check and the DELETE ACL check that are enforced by the regular delete (OpCode 2) path. This is an authorization bypass / ACL enforcement bug.
This issue affects Apache ZooKeeper: from 3.9.0 through 3.9.5, from 3.8.0 through 3.8.6.
Users are recommended to upgrade to version 3.9.6 or 3.8.7, which fixes the issue.
Apache ZooKeeper quorum TLS fails to enforce peer hostname verification in FIPS-mode deployments. When sslQuorum=true, zookeeper.fips-mode=true, ssl.quorum.hostnameVerification=true, and ssl.quorum.clientHostnameVerification=true are enabled, the Java SSLSocket quorum path accepts a CA-trusted peer certificate whose SAN does not match the connected host. A malicious or misissued peer certificate can therefore join quorum traffic, participate in leader election, and enter replication flows.
Users are recommended to upgrade to version 3.8.7 or 3.9.6, which fixes the issue.
Information disclosure via SetWatches reconnect replay in Apache ZooKeeper due to missing ACL check. An attacker can discover ACL-restricted paths by registering exists-watches on non-existent paths, then reconnecting after the paths are created with restricted ACLs. Issue is caused by incomplete fix for CVE-2024-23944 (ZOOKEEPER-4799). The fix added ACL checking to WatchManager.triggerWatch(). However, DataTree.setWatches() — the SetWatches/SetWatches2 reconnect replay handler — still calls watcher.process(event) with null ACL, bypassing the check entirely. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical.
Users are recommended to upgrade to version 3.9.6, 3.8.7 which fixes the issue.
Severity: critical
Affected versions:
- Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.9.0 through 3.9.5 - Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.8.0 through 3.8.6
Description:
Information disclosure via SetWatches reconnect replay in Apache ZooKeeper due to missing ACL check. An attacker can discover ACL-restricted paths by registering exists-watches on non-existent paths, then reconnecting after the paths are created with restricted ACLs. Issue is caused by incomplete fix for CVE-2024-23944 (ZOOKEEPER-4799). The fix added ACL checking to WatchManager.triggerWatch(). However, DataTree.setWatches() — the SetWatches/SetWatches2 reconnect replay handler — still calls watcher.process(event) with null ACL, bypassing the check entirely. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical.
Users are recommended to upgrade to version 3.9.6, 3.8.7 which fixes the issue.
Credit:
NGUYEN HONG QUAN <hongquanvp11 () gmail com> (reporter) n0mi1k <nomilksec () gmail com> (reporter)
References:
https://zookeeper.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-59739
Severity: important
Affected versions:
- Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.9.0 through 3.9.5 - Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.8.0 through 3.8.6
Description:
Apache ZooKeeper quorum TLS fails to enforce peer hostname verification in FIPS-mode deployments. When sslQuorum=true, zookeeper.fips-mode=true, ssl.quorum.hostnameVerification=true, and ssl.quorum.clientHostnameVerification=true are enabled, the Java SSLSocket quorum path accepts a CA-trusted peer certificate whose SAN does not match the connected host. A malicious or misissued peer certificate can therefore join quorum traffic, participate in leader election, and enter replication flows.
Users are recommended to upgrade to version 3.8.7 or 3.9.6, which fixes the issue.
Credit:
Erichen <chenyoulong20g () ict ac cn> (reporter)
References:
https://zookeeper.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-59969
Severity: critical
Affected versions:
- Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.9.0 through 3.9.5 - Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.8.0 through 3.8.6
Description:
The deleteContainer opcode (0x14/20) is processed without verifying the caller's ACL permissions, allowing any authenticated client to delete specific znodes in the data tree regardless of the ACL restrictions on the znode or its parent. This opcode is considered internal-only and the official client doesn't have API for it, but a client that can open a plain TCP session on the ZooKeeper client port (2181 by default) - with NO authentication and NO ACL permissions - can delete any empty persistent znode (including regular persistent nodes, container nodes, and TTL nodes) by issuing the raw protocol OpCode deleteContainer (20). The deleteContainer request path completely skips both the session check and the DELETE ACL check that are enforced by the regular delete (OpCode 2) path. This is an authorization bypass / ACL enforcement bug.
This issue affects Apache ZooKeeper: from 3.9.0 through 3.9.5, from 3.8.0 through 3.8.6.
Users are recommended to upgrade to version 3.9.6 or 3.8.7, which fixes the issue.
Credit:
K <sec-reports () outlook com> (reporter) z f <tinkerzf () gmail com> (reporter) 布豪 <1958304602 () qq com> (finder)
References:
https://zookeeper.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-79993
Severity: important
Affected versions:
- Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.9.0 through 3.9.5 - Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.8.0 through 3.8.6
Description:
When audit logging is enabled (zookeeper.audit.enable=true), an unauthenticated attacker can inject arbitrary fields into Apache ZooKeeper's audit log by sending a digest authentication request with tab characters (\t) embedded in the username. Because the audit log uses tab-separated key=value format, the injected tabs are parsed as legitimate field separators, allowing the attacker to spoof audit results (e.g., injecting result=success), forge operation types, and corrupt forensic evidence.
A log injection vulnerability in Apache ZooKeeper allows a client that can call setACL to inject forged key-value fields into zookeeperaudit.log. When audit logging is enabled, the server serializes attacker-controlled digest ACL ids into the acl= audit field without escaping tab characters. Because audit events are emitted as tab-separated key=value records, a crafted ACL id can make one successful setAcl event appear to contain forged fields such as operation=delete and znode=/forged. This undermines the integrity of downstream audit parsing, alerting, and incident response.
This issue affects Apache ZooKeeper: from 3.9.0 through 3.9.5, from 3.8.0 through 3.8.6.
Users are recommended to upgrade to version 3.9.6 or 3.8.7, which fixes the issue.
Credit:
Youlong Chen Institute of Computing Technology <chenyoulong20g () ict ac cn> (reporter)
References:
https://zookeeper.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-84439
Severity: moderate
Affected versions:
- Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.9.0 through 3.9.5 - Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.8.0 through 3.8.6
Description:
An unauthenticated attacker can inject arbitrary fake log lines into Apache ZooKeeper's operational log by sending a crafted addauth("ensemble", ...) request containing newline characters (\n). When the ensemble name doesn't match, EnsembleAuthenticationProvider.handleAuthentication() logs the raw, unsanitized name via LOG.warn(). Because SLF4J's {} placeholder preserves embedded newlines, the attacker can forge complete log entries — with arbitrary timestamps, log levels, class names, and messages — that are visually indistinguishable from genuine ZooKeeper log output.
This issue affects Apache ZooKeeper: from 3.9.0 through 3.9.5, from 3.8.0 through 3.8.6.
Users are recommended to upgrade to version 3.8.7 or 3.9.6, which fixes the issue.
Credit:
Youlong Chen Institute of Computing Technology <chenyoulong20g () ict ac cn> (finder)
References:
https://zookeeper.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-84501
Hostname verification in Apache ZooKeeper ZKTrustManager falls back to reverse DNS (PTR) when IP SAN validation fails, allowing attackers who control or spoof PTR records to impersonate ZooKeeper servers or clients with a valid certificate for the PTR name. It's important to note that attacker must present a certificate which is trusted by ZKTrustManager which makes the attack vector harder to exploit. Users are recommended to upgrade to version 3.8.6 or 3.9.5, which fixes this issue by introducing a new configuration option to disable reverse DNS lookup in client and quorum protocols.
Improper handling of configuration values in ZKConfig in Apache ZooKeeper 3.8.5 and 3.9.4 on all platforms allows an attacker to expose sensitive information stored in client configuration in the client's logfile. Configuration values are exposed at INFO level logging rendering potential production systems affected by the issue. Users are recommended to upgrade to version 3.8.6 or 3.9.5 which fixes this issue.
Improper handling of configuration values in ZKConfig in Apache ZooKeeper 3.8.5 and 3.9.4 on all platforms allows an attacker to expose sensitive information stored in client configuration in the client's logfile. Configuration values are exposed at INFO level logging rendering potential production systems affected by the issue. Users are recommended to upgrade to version 3.8.6 or 3.9.5 which fixes this issue.
Hostname verification in Apache ZooKeeper ZKTrustManager falls back to reverse DNS (PTR) when IP SAN validation fails, allowing attackers who control or spoof PTR records to impersonate ZooKeeper servers or clients with a valid certificate for the PTR name. It's important to note that attacker must present a certificate which is trusted by ZKTrustManager which makes the attack vector harder to exploit. Users are recommended to upgrade to version 3.8.6 or 3.9.5, which fixes this issue by introducing a new configuration option to disable reverse DNS lookup in client and quorum protocols.
Severity: important
Affected versions:
- Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.9.0 through 3.9.4 - Apache ZooKeeper (org.apache.zookeeper:zookeeper) 3.8.0 through 3.8.5
Description:
Hostname verification in Apache ZooKeeper ZKTrustManager falls back to reverse DNS (PTR) when IP SAN validation fails, allowing attackers who control or spoof PTR records to impersonate ZooKeeper servers or clients with a valid certificate for the PTR name. It's important to note that attacker must present a certificate which is trusted by ZKTrustManager which makes the attack vector harder to exploit. Users are recommended to upgrade to version 3.8.6 or 3.9.5, which fixes this issue by introducing a new configuration option to disable reverse DNS lookup in client and quorum protocols.
This issue is being tracked as ZOOKEEPER-4986
Credit:
Nikita Markevich <markevich.nikita1 () gmail com> (reporter)
References:
https://zookeeper.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-24281 https://issues.apache.org/jira/browse/ZOOKEEPER-4986
Improper permission check in ZooKeeper AdminServer lets authorized clients to run snapshot and restore command with insufficient permissions.
This issue affects Apache ZooKeeper: from 3.9.0 before 3.9.4.
Users are recommended to upgrade to version 3.9.4, which fixes the issue.
The issue can be mitigated by disabling both commands (via admin.snapshot.enabled and admin.restore.enabled), disabling the whole AdminServer interface (via admin.enableServer), or ensuring that the root ACL does not provide open permissions. (Note that ZooKeeper ACLs are not recursive, so this does not impact operations on child nodes besides notifications from recursive watches.)
Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical.
Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue.
Apache ZooKeeper could allow a remote authenticated attacker to obtain sensitive information, caused by a flaw in persistent watchers handling. By attaching a persistent watcher to a parent, an attacker could exploit this vulnerability to obtain information of the full path of znodes, and use this information to launch further attacks against the affected system.
Authorization Bypass Through User-Controlled Key vulnerability in Apache ZooKeeper. If SASL Quorum Peer authentication is enabled in ZooKeeper (quorum.auth.enableSasl=true), the authorization is done by verifying that the instance part in SASL authentication ID is listed in zoo.cfg server list. The instance part in SASL auth ID is optional and if it's missing, like 'eve@EXAMPLE.COM', the authorization check will be skipped. As a result an arbitrary endpoint could join the cluster and begin propagating counterfeit changes to the leader, essentially giving it complete read-write access to the data tree. Quorum Peer authentication is not enabled by default. Users are recommended to upgrade to version 3.9.1, 3.8.3, 3.7.2, which fixes the issue. Alternately ensure the ensemble election/quorum communication is protected by a firewall as this will mitigate the issue. See the documentation for more details on correct cluster administration.
End of life: 1/19/2024, End of support: 7/19/2023, Latest version: 3.7.2
End of life: 1/19/2024, End of support: 7/19/2023, Latest version: 3.7.2
Impact If a Content-Length header is present in the original HTTP/2 request, the field is not validated by Http2MultiplexHandler as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodec and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.
In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked.
An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. A sample attack request looks like:
POST / HTTP/2 :authority:: externaldomain.com Content-Length: 4
asdfGET /evilRedirect HTTP/1.1 Host: internaldomain.com
Users are only affected if all of this is true: HTTP2MultiplexCodec or Http2FrameCodec is used Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects These HTTP/1.1 objects are forwarded to another remote peer.
Patches This has been patched in 4.1.60.Final
Workarounds The user can do the validation by themselves by implementing a custom ChannelInboundHandler that is put in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec.
References Related change to workaround the problem: https://github.com/Netflix/zuul/pull/980
End of life: 12/30/2022, End of support: 3/7/2022, Latest version: 3.6.4
End of life: 12/30/2022, End of support: 3/7/2022, Latest version: 3.6.4
A flaw was found in Apache ZooKeeper. A lack of permission checks while retrieving ACLs allows unsalted hash values to be disclosed for unauthenticated or unprivileged users.
End of life: 6/1/2022, End of support: 3/27/2021, Latest version: 3.5.10
End of life: 6/1/2022, End of support: 3/27/2021, Latest version: 3.5.10
No authentication/authorization is enforced when a server attempts to join a quorum in Apache ZooKeeper before 3.4.10, and 3.5.0-alpha through 3.5.3-beta. As a result an arbitrary end point could join the cluster and begin propagating counterfeit changes to the leader.
Two four letter word commands “wchp/wchc” are CPU intensive and could cause spike of CPU utilization on ZooKeeper server if abused, which leads to the server unable to serve legitimate client requests.
Upstream issue:
https://issues.apache.org/jira/browse/ZOOKEEPER-2693
References:
https://vulners.com/exploitdb/EDB-ID:41277