Vulnerabilities exploitable today
366,836in 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,685
New KEV · 24H0
Exploit Today ≥ 701,629
Distribution · last window
- Critical2,377
- High9,662
- Medium5,457
- Low531
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2021-1572—15.8%
——5——CVE-2024-53172—15.8%
——5——CVE-2026-330217.3 HIG15.8%
——5libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. Versions 1.8.7 and prior contain a use-after-free vulnerability in sixel_encoder_encode_bytes() because sixel_frame_init() stores the caller-owned pixel buffer pointer directly in frame->pixels without making a defensive copy. When a resize operation is triggered, sixel_frame_convert_to_rgb888() unconditionally frees this caller-owned buffer and replaces it with a new internal allocation, leaving the caller with a dangling pointer. Any subsequent access to the original buffer by the caller constitutes a use-after-free, confirmed by AddressSanitizer. An attacker who controls incoming frames can trigger this bug repeatedly and predictably, resulting in a reliable crash with potential for code execution. This issue has been fixed in version 1.8.7-r1.35dCVE-2024-34817—15.8%
——5——CVE-2021-33083—15.8%
——5——CVE-2025-43191—15.8%
——5——CVE-2025-0666—15.8%
——5——CVE-2026-7725—15.8%
——5——CVE-2025-1495—15.8%
——5——CVE-2025-31951—15.8%
——5——CVE-2025-13226—15.8%
——5——CVE-2024-410177.8 HIG15.8%
——5In the Linux kernel, the following vulnerability has been resolved:
jfs: don't walk off the end of ealist
Add a check before visiting the members of ea to
make sure each ea stays within the ealist.25dCVE-2026-46958—15.8%
——5——CVE-2024-53183—15.8%
——5——CVE-2025-32357—15.8%
——5——CVE-2025-57728—15.8%
——5——CVE-2026-46959—15.8%
——5——CVE-2022-44636—15.8%
——5——CVE-2024-49344—15.8%
——5——CVE-2022-3378—15.8%
——5——CVE-2022-49034—15.8%
——5——CVE-2024-36076—15.8%
——5——CVE-2021-47858—15.8%
——5——CVE-2024-468307.8 HIG15.8%
——5In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS
Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly
leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX
reads guest memory.
Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN
via sync_regs(), which already holds SRCU. I.e. trying to precisely use
kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause
problems. Acquiring SRCU isn't all that expensive, so for simplicity,
grab it unconditionally for KVM_SET_VCPU_EVENTS.
=============================
WARNING: suspicious RCU usage
6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
-----------------------------
include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by repro/1071:
#0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]
stack backtrace:
CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Call Trace:
<TASK>
dump_stack_lvl+0x7f/0x90
lockdep_rcu_suspicious+0x13f/0x1a0
kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]
kvm_vcpu_read_guest+0x3e/0x90 [kvm]
nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]
load_vmcs12_host_state+0x432/0xb40 [kvm_intel]
vmx_leave_nested+0x30/0x40 [kvm_intel]
kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]
kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]
? mark_held_locks+0x49/0x70
? kvm_vcpu_ioctl+0x7d/0x970 [kvm]
? kvm_vcpu_ioctl+0x497/0x970 [kvm]
kvm_vcpu_ioctl+0x497/0x970 [kvm]
? lock_acquire+0xba/0x2d0
? find_held_lock+0x2b/0x80
? do_user_addr_fault+0x40c/0x6f0
? lock_release+0xb7/0x270
__x64_sys_ioctl+0x82/0xb0
do_syscall_64+0x6c/0x170
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7ff11eb1b539
</TASK>25dCVE-2026-666227.5 HIG15.8%
——5Unauthenticated SQL Injection in Depicter Slider <= 4.8.0 versions.9dCVE-2025-57762—15.8%
——5——CVE-2024-37068—15.8%
——5——CVE-2024-37356—15.8%
——5——CVE-2023-47113—15.8%
——5——CVE-2026-55531—15.8%
——5——CVE-2026-0730—15.8%
——5——CVE-2019-14783—15.8%
——5——CVE-2024-28047—15.8%
——5——CVE-2026-46971—15.8%
——5——CVE-2021-472917.8 HIG15.8%
——5In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix another slab-out-of-bounds in fib6_nh_flush_exceptions
While running the self-tests on a KASAN enabled kernel, I observed a
slab-out-of-bounds splat very similar to the one reported in
commit 821bbf79fe46 ("ipv6: Fix KASAN: slab-out-of-bounds Read in
fib6_nh_flush_exceptions").
We additionally need to take care of fib6_metrics initialization
failure when the caller provides an nh.
The fix is similar, explicitly free the route instead of calling
fib6_info_release on a half-initialized object.25dCVE-2025-34189—15.8%
——5——CVE-2026-708757.5 HIG15.8%
——5Vulnerability in the Oracle Hyperion Data Relationship Management product of Oracle Hyperion (component: Access and security). The supported version that is affected is 11.2.25.0.000. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Hyperion Data Relationship Management. Successful attacks of this vulnerability can result in takeover of Oracle Hyperion Data Relationship Management. CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H).4dCVE-2021-0121—15.8%
——5——CVE-2025-24108—15.8%
——5——CVE-2026-40300—15.8%
——5——