Vulnerabilities exploitable today
358,897in 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,607
Distribution · last window
- Critical2,703
- High11,649
- Medium7,415
- Low682
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2025-41026—9.8%
——3——CVE-2024-12604—9.8%
——3——CVE-2026-23769—9.8%
——3——CVE-2021-47852—9.8%
——3——CVE-2022-507197.8 HIG9.8%
——3In the Linux kernel, the following vulnerability has been resolved:
ALSA: line6: fix stack overflow in line6_midi_transmit
Correctly calculate available space including the size of the chunk
buffer. This fixes a buffer overflow when multiple MIDI sysex
messages are sent to a PODxt device.9dCVE-2026-106543.1 LOW9.8%
——3A race condition in the Zephyr Bluetooth Classic RFCOMM host stack (subsys/bluetooth/host/classic/rfcomm.c) mishandles a simultaneous bidirectional session disconnect. When the local device has initiated a session teardown (state BT_RFCOMM_STATE_DISCONNECTING, DISC sent, RTX timer armed) and the connected peer concurrently sends its own DISC frame for dlci 0, rfcomm_handle_disc() invokes rfcomm_session_disconnected(), which unconditionally forced the session to BT_RFCOMM_STATE_DISCONNECTED without ever calling bt_l2cap_chan_disconnect().
Because the recovery timer was also cancelled and a later UA is ignored in the DISCONNECTED state, the session becomes permanently wedged: the underlying L2CAP channel is never released and the session slot in the fixed bt_rfcomm_pool[CONFIG_BT_MAX_CONN] array is never reclaimed (its conn pointer stays set).
Subsequent bt_rfcomm_dlc_connect() calls on that connection fail with -EINVAL due to the invalid session state, so RFCOMM service is denied for that peer, and repeated occurrences can exhaust the session pool. The DISC frame is peer-controlled over the air, but exploitation requires the peer's DISC to collide with a local-initiated disconnect (a high-complexity timing race). Impact is availability/resource-leak only; there is no memory-safety, confidentiality, or integrity consequence. The defect shipped in released versions (present in v4.4.0 and earlier).
The fix only transitions to DISCONNECTED when the session is not already in DISCONNECTING, preserving the proper L2CAP teardown path.29dCVE-2024-26948—9.8%
——3——CVE-2025-7205—9.8%
——3——CVE-2026-419296.1 MED9.8%
——3Vvveb before 1.0.8.2 contains an unauthenticated reflected cross-site scripting vulnerability in the visual editor preview renderer that allows attackers to execute arbitrary JavaScript by manipulating the r query parameter and _component_ajax POST parameter. Attackers can craft a malicious link or auto-submitted form that causes victims to execute attacker-controlled JavaScript in the context of the Vvveb origin, as the gating function isEditor() performs no session, role, or token verification and the view handler injects raw HTML POST body content without sanitization.29dCVE-2018-11934—9.8%
——3——CVE-2026-626833.1 LOW9.8%
——3File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.17, File Browser can leave a public directory share behind when the shared directory is deleted through a path with a trailing slash because the share cleanup path calls DeleteWithPathPrefix(file.Path, userID) and the Bolt backend performs the database prefix query with the unnormalized path before trimming the slash for boundary checks, so deleting /a/ does not delete the stored /a share and the stale public share exposes future content if the same path is recreated. This issue is fixed in version 2.63.17.28dCVE-2026-68330—9.8%
——3In the Linux kernel, the following vulnerability has been resolved:
net: airoha: Fix DMA direction for NPU mailbox buffer
airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE,
but some callers expect the NPU to write response data back into the
same buffer:
- airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into
the buffer, then the caller reads it via memcpy()
- airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back
npu_stats_addr field in the response
On non-cache-coherent architectures like EN7581 (Cortex-A53 without
hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op
— it does not invalidate the CPU cache. If the NPU-written cache line
is still present in the CPU cache when the caller reads the buffer,
the CPU observes stale data instead of the NPU response.
This is a timing-sensitive bug: small mailbox buffers (~24 bytes)
typically fit in a single cache line and may survive in the cache
until the caller reads them, producing silent data corruption rather
than a crash. The bug is more likely to trigger when the caller reads
the response immediately after dma_unmap_single() without intervening
cache-evicting operations.
Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures
dma_unmap_single() invalidates the CPU cache on non-coherent systems.
The mailbox buffers are small so there is no performance concern.3dCVE-2026-68173—9.8%
——3In the Linux kernel, the following vulnerability has been resolved:
ublk: wait on ublk_dev_ready() instead of ub->completion
ub->completion is only re-armed by a successful START_USER_RECOVERY. If
the ublk server sends END_USER_RECOVERY without one - e.g. its START
failed with -EBUSY and the error was ignored - the wait is satisfied by
the stale completion of the previous recovery cycle, and the device is
marked LIVE and the requeue list kicked while the FETCH stream is still
running and ubq->canceling is still set. The kick redispatches a
previously requeued request, __ublk_queue_rq_common() sees ->canceling
and parks it again via __ublk_abort_rq(), and after the last FETCH
clears ->canceling nothing ever kicks the requeue list again: the
request is stranded there while holding its tag. If it is the flush
machinery's flush_rq, every subsequent fsync piles up in uninterruptible
sleep and teardown hangs on tag draining. This matches a report of a
lost PREFLUSH with ext4 on top of ublk after daemon crash recovery.
ub->completion is an edge-triggered latch used as a proxy for the level
condition "every queue has fetched all I/O commands", which can regress
(F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop
it and wait on the real condition instead: the new helper
ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via
wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then
re-checks it under ub->mutex, waiting again on regression, and returns
with the mutex held and readiness guaranteed.
Readiness becomes true in the same ub->mutex critical section that
clears the last queue's ->canceling, so END_USER_RECOVERY marks the
device LIVE and kicks the requeue list strictly after ->canceling
clears. The wait stays interruptible, so a server whose daemon died can
still be signalled out. For ublk_ctrl_start_dev() this replaces the
fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting
until the device is ready again.3dCVE-2025-54283—9.8%
——3——CVE-2022-0005—9.8%
——3——CVE-2021-47108—9.8%
——3——CVE-2024-2904—9.8%
——3——CVE-2025-11492—9.8%
——3——CVE-2019-2292—9.8%
——3——CVE-2025-27273—9.8%
——3——CVE-2019-1586—9.8%
——3——CVE-2019-2247—9.8%
——3——CVE-2025-24807—9.8%
——3——CVE-2026-140204.3 MED9.8%
——3Insufficient validation of untrusted input in WebXR in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)42dCVE-2025-31835—9.8%
——3——CVE-2025-31032—9.8%
——3——CVE-2026-545005.3 MED9.8%
——3Oj (Optimized JSON) is a JSON parser and Object marshaller packaged as a Ruby gem. In versions prior to 3.17.3, Oj.load in :object mode reads uninitialized stack memory (and, for long keys, reads out of bounds) when parsing a JSON object whose key is 254 bytes or longer. The interned bytes can surface to the caller, disclosing process stack memory. In ext/oj/intern.c, form_attr() handles the long-key path by allocating a heap buffer, `b`, populating it with the attribute name, and then freeing it — but it passed the uninitialized stack buffer buf (not b) to rb_intern3(). rb_intern3 therefore reads len + 1 bytes of uninitialized stack memory. When the key length is >= 256, it also reads out of bounds past the 256-byte buf. The resulting bytes are interned and can reach the caller via the produced Symbol or via the EncodingError message raised on invalid UTF-8, leaking process stack contents. This issue has been fixed in version 3.17.3.43dCVE-2025-1439—9.8%
——3——CVE-2026-2933—9.8%
——3——CVE-2023-29165—9.8%
——3——CVE-2026-44457—9.8%
——3——CVE-2025-32479—9.8%
——3——CVE-2025-32478—9.8%
——3——CVE-2026-20610—9.8%
——3——CVE-2026-534675.3 MED9.8%
——3ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 6.9.13-51 and 7.1.2-26, the MNG decoder contains a possible heap information disclosure vulnerability because part of the pixels are left unchanged. This issue has been fixed in versions 6.9.13-51 and 7.1.2-26.41dCVE-2025-32112—9.8%
——3——CVE-2025-31393—9.8%
——3——CVE-2025-12143—9.8%
——3——CVE-2026-54198—9.8%
——3——CVE-2018-13912—9.8%
——3——