WaratekVRT Sign in

Critical CWE-338 CVEs

4 CVEs

Reset
More filters (1)
Columns
CWE CWE-338✕
Overview 4 matches · 0 protected · 0 exploited · 0 CISA KEV · 1 public PoC · 0 EPSS ≥ 0.5
4matches 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 1public PoC25.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 1 25.0% No exploit published 3 75.0%
Critical 4 100.0% High 0 0.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 4 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 1 25.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 3 75.0%
split by peak 2 / year
20182019202020212022202320242025
4 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2025-59390 Critical 2025-11-26 No exploit published No public exploit Apache Druid’s Kerberos authenticator uses a weak fallback secret when the `druid.auth.authenticator.kerberos.cookieSignatureSecret` configuration is not explicitly set. In this case, the secret is generated using `ThreadLocalRandom`, which is not a crypto-graphically secure random number generator. This may allow an attacker to predict or brute force the secret used to sign authentication cookies, potentially enabling token forgery or authentication bypass. Additionally, each process generates its own fallback secret, resulting in inconsistent secrets across nodes. This causes authentication failures in distributed or multi-broker deployments, effectively leading to a incorrectly configured clusters. Users are advised to configure a strong `druid.auth.authenticator.kerberos.cookieSignatureSecret` This issue affects Apache Druid: through 34.0.0. Users are recommended to upgrade to version 35.0.0, which fixes the issue making it mandatory to set `druid.auth.authenticator.kerberos.cookieSignatureSecret` when using the Kerberos authenticator. Services will fail to come up if the secret is not set.
CVE-2025-32754 Critical 2025-04-10 No exploit published No public exploit In jenkins/ssh-agent Docker images 6.11.1 and earlier, SSH host keys are generated on image creation for images based on Debian, causing all containers based on images of the same version use the same SSH host keys, allowing attackers able to insert themselves into the network path between the SSH client (typically the Jenkins controller) and SSH build agent to impersonate the latter.
CVE-2024-29868 Critical 2024-06-24 Mitigation candidate Working exploit published Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) vulnerability in Apache StreamPipes user self-registration and password recovery mechanism. This allows an attacker to guess the recovery token in a reasonable time and thereby to take over the attacked user's account. This issue affects Apache StreamPipes: from 0.69.0 through 0.93.0. Users are recommended to upgrade to version 0.95.0, which fixes the issue.
CVE-2018-16115 Critical 2018-08-29 No exploit published No public exploit Lightbend Akka 2.5.x before 2.5.16 allows message disclosure and modification because of an RNG error. A random number generator is used in Akka Remoting for TLS (both classic and Artery Remoting). Akka allows configuration of custom random number generators. For historical reasons, Akka included the AES128CounterSecureRNG and AES256CounterSecureRNG random number generators. The implementations had a bug that caused the generated numbers to be repeated after only a few bytes. The custom RNG implementations were not configured by default but examples in the documentation showed (and therefore implicitly recommended) using the custom ones. This can be used by an attacker to compromise the communication if these random number generators are enabled in configuration. It would be possible to eavesdrop, replay, or modify the messages sent with Akka Remoting/Cluster.