8 results (0.003 seconds)

CVSS: 9.1EPSS: 0%CPEs: 1EXPL: 0

When using IPAuthenticationProvider in ZooKeeper Admin Server there is a possibility of Authentication Bypass by Spoofing -- this only impacts IP based authentication implemented in ZooKeeper Admin Server. Default configuration of client's IP address detection in IPAuthenticationProvider, which uses HTTP request headers, is weak and allows an attacker to bypass authentication via spoofing client's IP address in request headers. Default configuration honors X-Forwarded-For HTTP header to read client's IP address. X-Forwarded-For request header is mainly used by proxy servers to identify the client and can be easily spoofed by an attacker pretending that the request comes from a different IP address. Admin Server commands, such as snapshot and restore arbitrarily can be executed on successful exploitation which could potentially lead to information leakage or service availability issues. • https://lists.apache.org/thread/b3qrmpkto5r6989qr61fw9y2x646kqlh • CWE-290: Authentication Bypass by Spoofing •

CVSS: 5.3EPSS: 0%CPEs: 3EXPL: 0

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. Divulgación de información en el manejo de observadores persistentes en Apache ZooKeeper debido a la falta de verificación de ACL. • http://www.openwall.com/lists/oss-security/2024/03/14/2 https://lists.apache.org/thread/96s5nqssj03rznz9hv58txdb2k1lr79k • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •

CVSS: 9.1EPSS: 1%CPEs: 6EXPL: 0

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. • http://www.openwall.com/lists/oss-security/2023/10/11/4 https://lists.apache.org/thread/wf0yrk84dg1942z1o74kd8nycg6pgm5b https://lists.debian.org/debian-lts-announce/2023/10/msg00029.html https://security.netapp.com/advisory/ntap-20240621-0007 https://www.debian.org/security/2023/dsa-5544 https://access.redhat.com/security/cve/CVE-2023-44981 https://bugzilla.redhat.com/show_bug.cgi?id=2243436 • CWE-639: Authorization Bypass Through User-Controlled Key •

CVSS: 5.9EPSS: 16%CPEs: 8EXPL: 0

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. 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. • https://github.com/Netflix/zuul/pull/980 https://github.com/netty/netty/commit/89c241e3b1795ff257af4ad6eadc616cb2fb3dc4 https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpj https://lists.apache.org/thread.html/r02e467123d45006a1dda20a38349e9c74c3a4b53e2e07be0939ecb3f%40%3Cdev.ranger.apache.org%3E https://lists.apache.org/thread.html/r040a5e4d9cca2f98354b58a70b27099672276f66995c4e2e39545d0b%40%3Cissues.hbase.apache.org%3E https://lists.apache.org/thread.html/r04a3e0d9f53421fb946c60cc54762b7151dc692eb4e39970a7579052%40%3Ccommits.servicecomb.apache.org • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •

CVSS: 7.5EPSS: 0%CPEs: 31EXPL: 0

An issue is present in Apache ZooKeeper 1.0.0 to 3.4.13 and 3.5.0-alpha to 3.5.4-beta. ZooKeeper’s getACL() command doesn’t check any permission when retrieves the ACLs of the requested node and returns all information contained in the ACL Id field as plaintext string. DigestAuthenticationProvider overloads the Id field with the hash value that is used for user authentication. As a consequence, if Digest Authentication is in use, the unsalted hash value will be disclosed by getACL() request for unauthenticated or unprivileged users. Hay un problema presente en Apache ZooKeeper 1.0.0 a 3.4.13 y 3.5.0-alpha a 3.5.4-beta. • http://www.securityfocus.com/bid/108427 https://access.redhat.com/errata/RHSA-2019:3140 https://access.redhat.com/errata/RHSA-2019:3892 https://access.redhat.com/errata/RHSA-2019:4352 https://issues.apache.org/jira/browse/ZOOKEEPER-1392 https://lists.apache.org/thread.html/053d9ce4d579b02203db18545fee5e33f35f2932885459b74d1e4272%40%3Cissues.activemq.apache.org%3E https://lists.apache.org/thread.html/519eb0fd45642dcecd9ff74cb3e71c20a4753f7d82e2f07864b5108f%40%3Cdev.drill.apache.org%3E https://lists.apache.org/thread.html&#x • CWE-732: Incorrect Permission Assignment for Critical Resource CWE-862: Missing Authorization •