Vulnerabilities exploitable today
359,665in 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,665
New KEV · 24H0
Exploit Today ≥ 701,608
Distribution · last window
- Critical2,517
- High11,192
- Medium7,126
- Low650
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2025-5175—10.9%
——3——CVE-2025-14021—11.0%
——3——CVE-2023-41994—10.9%
——3——CVE-2022-50772—11.0%
——3——CVE-2024-54121—11.0%
——3——CVE-2026-7965—11.0%
——3——CVE-2022-49880—11.0%
——3——CVE-2025-40363—11.0%
——3——CVE-2025-48397—11.0%
——3——CVE-2025-62246—11.0%
——3——CVE-2018-5835—11.0%
——3——CVE-2025-14632—11.0%
——3——CVE-2025-23308—11.0%
——3——CVE-2022-28655—11.0%
——3——CVE-2026-24347—11.0%
——3——CVE-2026-8699—11.0%
——3A stored Cross-Site Scripting (XSS) vulnerability has been identified in the web-based management interface of Archer C5 v6.8 routers, due to insufficient server-side validation and lack of proper output encoding of user-controlled input in a certain field. An attacker with administrative privileges can inject crafted HTML or JS payloads into the affected field. The payload is stored and later executed when the affected page is rendered in an administrator's browser.Successful exploitation allows execution of arbitrary JavaScript in an admin's browser, potentially leading to session hijacking and unauthorized access to router configuration, possibly resulting in exposure of sensitive data and modification of device settings.
The vulnerability affects ISP-managed firmware variants of the product. Remediation is coordinated through service providers.43dCVE-2025-20361—11.0%
——3——CVE-2026-447517.1 HIG11.0%
——3Application server ABAP does not perform necessary authorization checks for an authenticated user allowing an attacker to execute a report generation command which could overwrite information belonging to another user, resulting in escalation of privileges. This has high impact on integrity with low impact on availability and no impact on confidentiality of the application.23dCVE-2026-41524—11.0%
——3——CVE-2024-56446—11.0%
——3——CVE-2023-2919—11.0%
——3——CVE-2025-49112—11.0%
——3——CVE-2024-47501—11.0%
——3——CVE-2025-57876—11.0%
——3——CVE-2026-57282—11.0%
——3——CVE-2026-1243—11.0%
——3——CVE-2025-54243—11.0%
——3——CVE-2022-49776—11.0%
——3——CVE-2025-23140—11.0%
——3——CVE-2021-34385—11.0%
——3——CVE-2025-62263—11.0%
——3——CVE-2022-49787—11.0%
——3——CVE-2020-25082—11.0%
——3——CVE-2024-477117.8 HIG11.0%
——3In the Linux kernel, the following vulnerability has been resolved:
af_unix: Don't return OOB skb in manage_oob().
syzbot reported use-after-free in unix_stream_recv_urg(). [0]
The scenario is
1. send(MSG_OOB)
2. recv(MSG_OOB)
-> The consumed OOB remains in recv queue
3. send(MSG_OOB)
4. recv()
-> manage_oob() returns the next skb of the consumed OOB
-> This is also OOB, but unix_sk(sk)->oob_skb is not cleared
5. recv(MSG_OOB)
-> unix_sk(sk)->oob_skb is used but already freed
The recent commit 8594d9b85c07 ("af_unix: Don't call skb_get() for OOB
skb.") uncovered the issue.
If the OOB skb is consumed and the next skb is peeked in manage_oob(),
we still need to check if the skb is OOB.
Let's do so by falling back to the following checks in manage_oob()
and add the test case in selftest.
Note that we need to add a similar check for SIOCATMARK.
[0]:
BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959
Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235
CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:93 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959
unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640
unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778
unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996
sock_recvmsg_nosec net/socket.c:1046 [inline]
sock_recvmsg+0x22f/0x280 net/socket.c:1068
____sys_recvmsg+0x1db/0x470 net/socket.c:2816
___sys_recvmsg net/socket.c:2858 [inline]
__sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5360d6b4e9
Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9
RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003
RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001
</TASK>
Allocated by task 5235:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:312 [inline]
__kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3988 [inline]
slab_alloc_node mm/slub.c:4037 [inline]
kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080
__alloc_skb+0x1c3/0x440 net/core/skbuff.c:667
alloc_skb include/linux/skbuff.h:1320 [inline]
alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528
sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815
sock_alloc_send_skb include/net/sock.h:1778 [inline]
queue_oob+0x108/0x680 net/unix/af_unix.c:2198
unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x221/0x270 net/socket.c:745
____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
___sys_sendmsg net/socket.c:2651 [inline]
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 5235:
kasan_save_stack mm/kasan/common.c:47
---truncated---11dCVE-2022-50640—11.0%
——3——CVE-2025-43823—11.0%
——3——CVE-2022-48718—11.0%
——3——CVE-2026-439848.9 HIG11.0%
——3Tautulli is a Python based monitoring and tracking tool for Plex Media Server. Versions prior to 2.17.1 expose `log_js_errors` to any authenticated user, including guest users when guest access is enabled. The endpoint writes attacker-controlled strings directly into the main application log. The administrator-only `logFile` view then reads that log file and embeds it into an HTML response without escaping. This creates a stored cross-site scripting condition where a low-privilege guest can inject HTML or JavaScript into the log file and have it execute in an administrator's browser when the log viewer is opened. Version 2.17.1 patches the issue.23dCVE-2020-4369—11.0%
——3——CVE-2026-106475.3 MED11.0%
——3The USB CDC-NCM device class (subsys/usb/device_next/class/usbd_cdc_ncm.c) ignores the return value of usbd_ep_enqueue() in its ethernet transmit callback cdc_ncm_send(). When the enqueue fails, the function still calls k_sem_take(&data->sync_sem, K_FOREVER), blocking on a completion semaphore that is only ever signaled from the bulk-IN transfer-completion callback. Because nothing was enqueued, that callback never fires and the calling thread — a shared network traffic-class TX thread — deadlocks permanently while holding the interface TX lock, halting transmission until reboot (and leaking the transmit buffer).
The enqueue fails under conditions controlled by the attached USB host: usbd_ep_enqueue() returns -EPERM whenever the bus is suspended (a standard, persistent host operation), and the underlying udc_ep_enqueue() returns -EPERM/-ENODEV on disconnect, bus reset, or endpoint disable. The cdc_ncm_send() guard only checks the DATA_IFACE_ENABLED and IFACE_UP flags, not the suspended state, so a packet transmitted while the host holds the bus suspended reaches the failing enqueue and deadlocks the TX path.
The realistic trigger is a bus suspend that occurs while the exported network interface is active and has traffic to send — host sleep, USB selective/auto-suspend, or hub power management — after which any device-originated packet deadlocks the path, recoverable only by reboot. The impact is a persistent loss of the virtual network connection between the host's NCM interface and the Zephyr device; because the deadlocked thread is a shared traffic-class TX thread, egress on other network interfaces can stall as well. There is no memory corruption or information disclosure.
The defect was introduced with the CDC-NCM driver and shipped in releases through v4.4.0; it is fixed by checking the usbd_ep_enqueue() return value and freeing the buffer before the blocking wait.8d