Overview 2 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
2matches
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
2
100.0%
Outside Waratek scope
0
0.0%
Not applicable
0
0.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
2
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
2
100.0%
split by
peak 1 / month
Nov 23Jan 24Mar 24May 24Jul 24Sep 24Nov 24
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2024-51504 | Critical | 2024-11-07 | No exploit published | No public exploit | 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. Users are recommended to upgrade to version 3.9.3, which fixes this issue. |
| CVE-2023-44981 | Critical | 2023-10-11 | No exploit published | No public exploit | 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. |