Vulnerabilities exploitable today
355,262in current view
Single score combining CVSS, KEV membership and EPSS. Every CVE with its own record — timeline from publication to active exploitation.
In KEV catalog1,657
New KEV · 24H0
Exploit Today ≥ 701,602
Distribution · last window
- Critical2,724
- High11,017
- Medium7,317
- Low696
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2025-59015—7.1%
——2——CVE-2023-54302—7.1%
——2——CVE-2023-54301—7.1%
——2——CVE-2023-54066—7.1%
——2——CVE-2025-31068—7.1%
——2——CVE-2023-54252—7.1%
——2——CVE-2023-54248—7.1%
——2——CVE-2025-43332—7.1%
——2——CVE-2026-601227.8 HIG7.1%
——2gpsd through release-3.27.5, fixed at commit 4c06658, contains a code injection vulnerability in the gpsprof utility that allows an attacker who controls GPS input data to execute arbitrary OS commands by injecting malicious content into the SKY.satellites[].used field, which is inserted unsanitized into a gnuplot heredoc data block. Attackers can supply a used value containing the string EOD to terminate the heredoc early and append gnuplot system() calls, achieving OS command execution as the user running gpsprof when the generated plot script is processed by gnuplot in polar mode.5dCVE-2023-54251—7.1%
——2——CVE-2026-106297.4 HIG7.1%
——2SIP signaling stack in Verizon IMS (unspecified version) implements SIP signaling without IPsec integrity protection (missing Security-Client/Security-Server headers and ESP traffic), which allows an on-path attacker to compromise confidentiality, integrity, and authenticity of VoLTE signaling via passive monitoring and active manipulation of unsecured SIP messages over the radio and core network.13dCVE-2025-22571—7.1%
——2——CVE-2025-47633—7.1%
——2——CVE-2019-1667—7.1%
——2——CVE-2021-3162—7.1%
——2——CVE-2019-25620—7.1%
——2——CVE-2025-47624—7.1%
——2——CVE-2025-22557—7.1%
——2——CVE-2022-4945—7.1%
——2——CVE-2024-45165—7.1%
——2——CVE-2026-56761—7.1%
——2——CVE-2025-24479—7.1%
——2——CVE-2024-386287.8 HIG7.1%
——2In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.
Hang on to the control IDs instead of pointers since those are correctly
handled with locks.5hCVE-2022-23091—7.1%
——2——CVE-2025-44003—7.1%
——2——CVE-2026-456833.8 LOW7.1%
——2OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, the Java TLS ioctl probe reads user-controlled ioctl pointers with bpf_probe_read instead of bpf_probe_read_user. An instrumented local process can therefore point OBI at kernel memory and cause that memory to be copied into telemetry. This issue has been patched in version 0.9.0.13dCVE-2023-22409—7.1%
——2——CVE-2026-59643—7.1%
——2In Bouncy Castle for Java before 1.85, OpenPGP inline-signature policy failures silently ignored. This issue also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 2.0.13.1dCVE-2025-49067—7.1%
——2——CVE-2025-2029—7.1%
——2——CVE-2026-39956—7.1%
——2——CVE-2026-59639—7.1%
——2In Bouncy Castle for Java before 1.85, CMS verifySignatures returns true for SignedData with zero signers. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.12 (1.0.X series), 2.0.12 (2.0.X series) and 2.1.12 (2.1.X series).1dCVE-2026-63836—7.1%
——2In the Linux kernel, the following vulnerability has been resolved:
batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd
The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in
batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics.
((mss * 8) ** 2) / (cwnd * 8)
In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the
left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around
and be 0 - resulting in:
((mss * 8) ** 2) / 0
This is of course invalid and cannot be calculated. The calculation should
must be simplified to avoid this overflow:
(mss ** 2) * 8 / cwnd
It will keep the precision enhancement from the scaling (by 8) but avoid
the overflow in the divisor.
In theory, there could still be an overflow in the dividend. It is at the
moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an
imminent problem. But allowing it to use the whole u32 bit range, would
mean that it can still use up to 67 bits. To keep this calculation safe for
32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits -
or in other words: must never be larger than 16383.8dCVE-2023-32633—7.1%
——2——CVE-2026-63834—7.1%
——2In the Linux kernel, the following vulnerability has been resolved:
batman-adv: tp_meter: restrict number of unacked list entries
When the unacked_list is unbound, an attacker could send messages with
small lengths and appropriated seqno + gaps to force the receiver to
allocate more and more unacked_list entries. And the end either causing an
out-of-memory situation or increase the management overhead for the (large)
list that significant portions of CPU cycles are wasted in searching
through the list.
When limiting the list to a specific number, it is important to still
correctly add a new entry to the list. But if the list became larger than
the limit, the last entry of the list (with the highest seqno) must be
dropped to still allow the earlier seqnos to finish and therefore to
continue the process. Otherwise, the process might get stuck with too high
seqnos which are not handled by batadv_tp_ack_unordered().8dCVE-2026-12860—7.1%
——2In Bouncy Castle for Java before 1.85, RSA PKCS#1 verification skips last two hash bytes in NULL-omitted path. This issue also affects Bouncy Castle for Java LTS before 2.73.12.1dCVE-2025-39369—7.1%
——2——CVE-2022-20598—7.1%
——2——CVE-2026-480409.1 CRI7.1%
——2The netty incubator codec.bhttp is a java language binary http parser. The library implements Oblivious HTTP (RFC 9458) using BoringSSL's HPKE C library via JNI. When deriving native memory addresses for cryptographic operations versions prior to 0.0.22.Final provide a fallback path for direct ByteBufs that do not expose their memory address through `hasMemoryAddress()`. This fallback occurs when `sun.misc.Unsafe` is unavailable to Netty — for example, when the JVM is started with `-Dio.netty.noUnsafe=true`, when a SecurityManager restricts Unsafe access, or when running on non-HotSpot JVMs. In these configurations, Netty's default `PooledByteBufAllocator` returns `PooledDirectByteBuf` instances for which `hasMemoryAddress()` returns false. Under the enabling JVM configuration, an unauthenticated network attacker can cause the OHTTP gateway to corrupt memory belonging to other concurrent connections and disclose the contents of adjacent pooled direct buffers by triggering cryptographic operations with crafted OHTTP requests. The corruption occurs regardless of whether the AEAD tag verification succeeds, as BoringSSL zeroizes the output buffer on failure. The information disclosure path provides the attacker with the encryption key needed to extract the leaked data. This violates the confidentiality and integrity of all connections sharing the same Netty buffer arena. Version 0.0.22.Final fixes the issue.13dCVE-2024-53751—7.1%
——2——