Vulnerabilities exploitable today
354,689in 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,656
New KEV · 24H0
Exploit Today ≥ 701,601
Distribution · last window
- Critical2,617
- High9,375
- Medium7,592
- Low711
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2025-68277—5.3%
——2——CVE-2026-391786.3 MED5.3%
——2A SQL injection vulnerability in SOGo before 5.12.7 allows authenticated users to execute arbitrary SQL statements via the search parameter of the allContactSearch endpoint.23dCVE-2021-30289—5.3%
——2——CVE-2024-32909—5.3%
——2——CVE-2022-50064—5.3%
——2——CVE-2019-25288—5.3%
——2——CVE-2025-69783—5.3%
——2——CVE-2025-64734—5.3%
——2——CVE-2023-32221—5.3%
——2——CVE-2026-27091—5.3%
——2——CVE-2025-49842—5.3%
——2——CVE-2021-30256—5.3%
——2——CVE-2022-50023—5.3%
——2——CVE-2024-8992—5.3%
——2——CVE-2021-30311—5.3%
——2——CVE-2026-64509—5.3%
——2In the Linux kernel, the following vulnerability has been resolved:
rust: block: fix GenDisk cleanup paths
GenDiskBuilder::build() still has fallible work after
__blk_mq_alloc_disk(), but its error path only recovers the
foreign queue data. That leaks the temporary gendisk and
request_queue until later teardown. If the caller moved the last
Arc<TagSet<T>> into build(), the leaked queue can retain blk-mq
state after the tag set is dropped.
Fix the pre-registration failure path by dropping the temporary
gendisk reference with put_disk() before recovering queue_data,
so disk_release() can tear down the owned queue.
Also pair GenDisk::drop() with put_disk() after del_gendisk().
Once a Rust GenDisk has been added with device_add_disk(),
del_gendisk() only unregisters it; the final gendisk reference
still has to be dropped to complete the release path.7dCVE-2025-25523—5.3%
——2——CVE-2025-13685—5.3%
——2——CVE-2026-642597.8 HIG5.3%
——2In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: make a fuse_req on SQE commit only findable after memcpy
Bad userspace might try to trick us and send commit SQEs request
unique / commit-id of requests that are not even send to
fuse-server (io_uring_cmd_done() not called) yet.
fuse_uring_commit_fetch() ends the fuse request when the ring entry
has a wrong state, but that could have caused a use-after-free
with the memcpy operations in fuse_uring_send_in_task().
In order to avoid such races the call of fuse_uring_add_to_pq()
is moved after the copy operations and just before completing
the io-uring request - malicious userspace cannot find the request
anymore until all prepration work in fuse-client/kernel is completed.
This also moves fuse_uring_add_to_pq() a bit up in the code to
avoid a forward declaration. Also not with a preparation commit,
to make it easier to back port to older kernels.2dCVE-2026-64508—5.3%
——2In the Linux kernel, the following vulnerability has been resolved:
bpf: Support for hardening against JIT spraying
The BPF JIT allocator packs many small programs into larger executable
allocations and reuses space within those allocations as programs are
loaded and freed. When fresh code is written into space that a previous
program occupied, an indirect jump into the new program can reuse a branch
prediction left behind by the old one.
Flush the indirect branch predictors before reusing JIT memory so that
indirect jumps into a newly written program don't reuse predictions from an
old program that occupied the same space.
Introduce bpf_arch_pred_flush_enabled static key and bpf_arch_pred_flush
static call for flushing the branch predictors on JIT memory reuse.
Architectures that need a flush, can update it to a predictor flush
function. By default, its a NOP and does not emit any CALL.
Allocations larger than a pack are not covered by this flush. That is safe
because cBPF programs (the unprivileged attack surface) are bounded well
below a pack size. Issue a warning if this assumption is ever violated
while the flush is active.5dCVE-2026-64180—5.3%
——2In the Linux kernel, the following vulnerability has been resolved:
mm/memory_hotplug: fix memory block reference leak on remove
Patch series "mm: Fix memory block leaks and locking", v2.
This series fixes two memory block device reference leaks and one locking
issue around the per-memory_block hwpoison counter.
This patch (of 2):
remove_memory_blocks_and_altmaps() looks up each memory block with
find_memory_block(), which acquires a reference to the memory block
device.
That reference is never dropped on this path, resulting in a leaked device
reference when removing memory blocks and their altmaps. Drop the
reference after retrieving mem->altmap and clearing mem->altmap, before
removing the memory block device.2dCVE-2020-0233—5.3%
——2——CVE-2018-5857—5.3%
——2——CVE-2020-11286—5.3%
——2——CVE-2021-1983—5.3%
——2——CVE-2019-2040—5.3%
——2——CVE-2018-7534—5.3%
——2——CVE-2024-37027—5.3%
——2——CVE-2026-64499—5.3%
——2In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ti-ads1119: fix PM reference leak in buffer preenable
ads1119_triggered_buffer_preenable() resumes the device with
pm_runtime_resume_and_get() before starting a conversion.
If i2c_smbus_write_byte() fails, the function returns the error directly
and leaves the runtime PM usage counter elevated. The matching
postdisable callback is not called when preenable fails, so the reference
is leaked and the device may remain runtime-active indefinitely.
Store the I2C transfer result in ret and drop the runtime PM reference on
failure before returning the error.7dCVE-2021-1984—5.3%
——2——CVE-2024-6831—5.3%
——2——CVE-2025-38351—5.3%
——2——CVE-2026-150767.5 HIG5.3%
——2In versions up to and including 4.5.29 (4.x branch) and 5.1.4 (5.x branch), the WebClientSession component of Eclipse Vert.x Web Client does not validate that the Domain attribute of a Set-Cookie response header matches the originating server's domain, in violation of RFC 6265 section 5.3.
An attacker who controls any server that the victim application contacts can inject a cookie scoped to an arbitrary third-party domain; because the session store performs no cross-domain ownership check, it stores and later transmits that cookie to the targeted domain.
When the victim application subsequently sends a request to the targeted domain using the same WebClientSession, it presents the attacker-injected cookie, causing the receiving service to process the request under the attacker's account. Sensitive data included in the victim application's requests, such as payment amounts, card details, or other API payloads, may then be accessible to the attacker through their own account on that service.18dCVE-2025-21105—5.3%
——2——CVE-2022-50107—5.3%
——2——CVE-2025-2181—5.3%
——2——CVE-2022-32582—5.3%
——2——CVE-2026-45929—5.3%
——2——CVE-2022-37343—5.3%
——2——CVE-2023-28122—5.3%
——2——