CVE Watch378,068 in full archive

Vulnerabilities exploitable today

378,068in 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,716

New KEV · 24H0

Exploit Today ≥ 701,651

Distribution · last window

Critical
2,293
High
8,417
Medium
6,703
Low
757

Filters

Window

Severity

Flags

Vulnerabilities257,321–257,360 · 378,068

CVECVSSEPSSKEVRExploitTitleMod.

——10——CVE-2023-47626—

31.8%

——10——CVE-2023-25871—

31.8%

——10——CVE-2017-1000242—

31.8%

——10——CVE-2023-25584—

31.8%

——10——CVE-2023-41663—

31.8%

——10——CVE-2025-1592—

31.8%

——10——CVE-2023-51458—

31.8%

——10——CVE-2023-39370—

31.8%

——10——CVE-2024-41856—

31.8%

——10——CVE-2026-852289.1 CRI

31.8%

——10An integer overflow in the tensor buffer validation component in Amazon Deep Java Library (DJL) from 0.13.0 through 0.36.0 on all platforms might allow a remote unauthenticated actor to obtain information from adjacent process memory or cause a denial of service via a crafted tensor payload. To remediate this issue, users should upgrade to version 0.37.0 or above.11d CVE-2026-40348—

31.8%

——10——CVE-2026-806689.8 CRI

31.8%

——10In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use conntrack GC to reap expectations This patch replaces the timer API by GC worker approach for expectations, as it already happened in many other subsystems. Use the existing conntrack GC worker to iterate over the local list of expectations in the master conntrack to reap expired expectations. Check IPS_HELPER_BIT to run GC for expectations, set it on for nft_ct expectation which nevers sets it. Hold the expectation spinlock while iterating over the master conntrack expectation list to synchronize with nf_ct_remove_expectations(). This also performs runtime packet path garbage collection through the expectation insertion and lookup functions while walking over one of the chains of the global expectation hashtables. Unconfirmed conntrack entries are skipped since ct->ext can be reallocated and dying are skipped since those will be gone soon. Set on IPS_HELPER_BIT if the helper ct extension is added, then the new GC worker does not need to bump the ct refcount to check if the ct->ext helper is available. This removes the extra bump on the refcount for expectation timers, this allows to remove several nf_ct_expect_put() calls after the unlink, after this update only refcount remains at 1 while on the expectation hashes. This patch implicitly addresses a race with the existing timer API allowing an expectation to access a stale exp->master pointer which has been already released when expectation removal loses races with an expiring timer, ie. timer_del() reporting false. Add a new NF_CT_EXPECT_DEAD flag to reap this expectation via GC. This is needed by nf_conntrack_unexpect_related() which is called in error paths to invalidate newly created expectations that has been added into the hashes. These expectactions cannot be inmediately released as GC or nf_ct_remove_expectations() could race to make it. On expectation insert, the runtime GC reaps stale expectations before checking the expectation limit set by policy. Set current timestamp in nf_ct_expect_alloc(), then add the expectation policy timeout (or custom timeout specified added on top of this) to specify the expectation lifetime.23d CVE-2023-25588—

31.8%

——10——CVE-2023-29441—

31.8%

——10——CVE-2026-148698.6 HIG

31.8%

——10The terraform-mcp-server before version 1.1.0 is vulnerable to a server-side request forgery issue in the streamable-HTTP transport that may allow an unauthenticated remote client to redirect the server's Terraform API requests, and the server-side authorization token, to an attacker-controlled endpoint. This vulnerability, CVE-2026-14869, is fixed in terraform-mcp-server 1.1.0.53d CVE-2023-41867—

31.8%

——10——CVE-2026-71880—

31.8%

——10Interpretation of untrusted input in template engine in GBIF Integrated Publishing Toolkit versions before 3.3.4 allows remote authenticated attackers to access server-side files and state via template injection21d CVE-2017-15127—

——10——CVE-2019-19082—

31.8%

——10——CVE-2026-476869.9 CRI

31.8%

——10vm2 is an open source vm/sandbox for Node.js. Prior to 3.11.6, handleException() in lib/setup-sandbox.js sanitizes SuppressedError.error, SuppressedError.suppressed, and AggregateError.errors but does not sanitize Error.cause, allowing sandbox code to obtain a powerful host object such as process from an embedder-exposed host function that throws an error with that object as its cause and then execute arbitrary host commands. This issue is fixed in version 3.11.6.12d CVE-2023-30584—

31.8%

——10——CVE-2024-10471—

31.8%

——10——CVE-2026-355627.5 HIG

31.8%

——10Allocation of resources without limits in the parsing components in Amazon Athena ODBC driver before 2.1.0.0 might allow a threat actor to cause a denial of service by delivering crafted input that triggers excessive resource consumption during the driver's parsing operations. To remediate this issue, users should upgrade to version 2.1.0.0.59d CVE-2019-19666—

31.8%

——10——CVE-2024-22058—

31.8%

——10——CVE-2026-793777.5 HIG

31.8%

——10A heap overflow in the a2dp_decoder_sbc.cpp component of Bestechnic Co., Ltd BES2300 Bluetooth Audio SoC firmware v3.x and earlier allows attackers to cause a Denial of Service (DoS) via sending a crafted L2CAP packet.12d CVE-2025-66255—

31.8%

——10——CVE-2026-927906.5 MED

31.8%

——10Higress before 2.2.4 panics when processing a Cookie header segment without an equals sign, causing the plugin wrapper to recover and return a continue action that bypasses AI token rate limiting. Unauthenticated attackers can craft a malformed Cookie header to skip rate limit checks and exceed thresholds intended to restrict costly model backend calls.5d CVE-2026-6148—

31.8%

——10——CVE-2025-5067—

31.8%

——10——CVE-2026-602558.2 HIG

31.8%

——10Vulnerability in the Oracle Coherence product of Oracle Fusion Middleware (component: Core). Supported versions that are affected are 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0 and 15.1.1.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via TCP to compromise Oracle Coherence. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Coherence as well as unauthorized update, insert or delete access to some of Oracle Coherence accessible data. CVSS 3.1 Base Score 8.2 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H).59d CVE-2023-43988—

31.8%

——10——CVE-2024-21121—

31.8%

——10——CVE-2023-51462—

31.8%

——10——CVE-2026-806129.8 CRI

31.8%

——10In the Linux kernel, the following vulnerability has been resolved: net: lwtunnel: Drop skb metadata before LWT encapsulation skb metadata is meant for passing information between XDP and TC. It lives in the skb headroom, immediately before skb->data. LWT programs cannot access the __sk_buff->data_meta pseudo-pointer to metadata. However, LWT encapsulation prepends outer headers, moving skb->data back over the headroom where the metadata sits. On an RX-originated (forwarded) packet that still carries XDP metadata this goes wrong in two different ways, depending on the encap type: 1. Non-BPF LWT encaps (mpls, seg6, ioam6 ...) call skb_push()/skb_pull() and silently overwrite the metadata that sits in the headroom. 2) BPF LWT xmit calls bpf_skb_change_head(), which uses skb_data_move(). That helper expects metadata immediately before skb->data. But since the IP output path runs LWT xmit before neighbour output has built the outgoing L2 header, for forwarded packets skb->data points at the L3 header while skb_mac_header() still points at the old L2 header. skb_data_move() sees metadata ending at skb_mac_header(), not before skb->data, warns and clears metadata: WARNING: CPU: 21 PID: 454557 at include/linux/skbuff.h:4609 skb_data_move+0x47/0x90 CPU: 21 UID: 0 PID: 454557 Comm: napi/iconduit-g Tainted: G O 6.18.21 #1 RIP: 0010:skb_data_move+0x47/0x90 Call Trace: <IRQ> bpf_skb_change_head+0xe6/0x1a0 bpf_prog_...+0x213/0x2e3 run_lwt_bpf.isra.0+0x1d3/0x360 bpf_xmit+0x46/0xe0 lwtunnel_xmit+0xa1/0xf0 ip_finish_output2+0x1e7/0x5e0 ip_output+0x63/0x100 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x9c/0x150 __napi_poll+0x2b/0x190 net_rx_action+0x40b/0x7f0 handle_softirqs+0xd2/0x270 do_softirq+0x3f/0x60 </IRQ> That is what happens, as for how to fix it - a received packet that carries metadata can reach an encap through any of the three LWT redirect modes: LWTUNNEL_STATE_INPUT_REDIRECT ip6_rcv_finish dst_input lwtunnel_input LWTUNNEL_STATE_OUTPUT_REDIRECT ip6_rcv_finish dst_input ip6_forward ip6_forward_finish dst_output lwtunnel_output LWTUNNEL_STATE_XMIT_REDIRECT ip6_rcv_finish dst_input ip6_forward ip6_forward_finish dst_output ip6_output ip6_finish_output ip6_finish_output2 lwtunnel_xmit Every encap funnels through the three LWT dispatch helpers, so drop the metadata there, right before handing the skb to the encap op. This single chokepoint covers all encap types and all three redirect modes: - lwtunnel_input(): seg6, rpl, ila, seg6_local - lwtunnel_output(): ioam6 - lwtunnel_xmit(): mpls, LWT BPF xmit Alternatively, we could clear the metadata right after TC ingress hook. That would require a compromise, however. Metadata would become inaccessible from TC egress (in setups where it actually reaches the hook it tact, that is without any L2 tunnels on path).23d