Vulnerabilities exploitable today
407,603in 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,766
New KEV · 24H0
Exploit Today ≥ 701,698
Distribution · last window
- Critical5,725
- High22,214
- Medium20,699
- Low2,166
Filters
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-1212108.8 HIG—
———Type confusion in V8 in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High)10hCVE-2026-1214526.5 MED—
———bbs-go through 4.4.6 contains an improper certificate validation vulnerability that allows network-positioned attackers to intercept SMTP traffic because sendEmail() sets InsecureSkipVerify to true. Attackers can present any certificate to capture SMTP PLAIN auth credentials and read or modify outgoing password-reset and verification emails.13hCVE-2026-1166616.5 MED—
———Tanium addressed an improper access controls vulnerability in Enforce.9hCVE-2026-120930——
———Incorrect authorization in Blink in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: High)10hCVE-2026-99259——
———In the Linux kernel, the following vulnerability has been resolved:
soc/tegra: pmc: Fix uninitialised clock rate
For legacy 32-bit Tegra devices, the warning in the
tegra_pmc_enter_suspend_mode() function is being triggered because the
early_pmc->rate variable is never configured and hence, always 0. This
issue started occurring after updating the PMC driver to create the PMC
context dynamically which causes the 'rate' to be set in the new dynamic
context, but missed updating the rate in the early PMC context.
Fix this by initialising the early_pmc->rate variable for 32-bit Tegra
devices when the rate for the PMC context is initialised.
[treding@nvidia.com: move assignment to existing #ifdef block]20hCVE-2026-121211——
———Use after free in PowerBookmarks in Google Chrome prior to 157.0.8103.38 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to execute arbitrary code outside the sandbox via a crafted Chrome extension. (Chromium security severity: High)11hCVE-2026-1207585.5 MED—
———HDF5 through 2.2.0 contains a NULL pointer dereference vulnerability in H5HL_unprotect() in src/H5HL.c. H5HL_protect() pins a single metadata cache entry for a local heap, either the heap prefix or the separate data block, and H5HL_unprotect() unpins it on the final unprotect. When the metadata cache destroys a corrupted local heap entry, H5HL__prfx_dest() unlinks it from the heap by setting heap->prfx or heap->dblk to NULL. A crafted HDF5 file can therefore reach H5HL_unprotect() with no cached object to unpin, and the function passes the NULL pointer to H5AC_unpin_entry(). This causes an assertion failure in debug builds and a NULL pointer dereference and crash in release builds. An attacker who can get a user or application to open and traverse a malicious file can cause a denial of service.11hCVE-2026-99258——
———In the Linux kernel, the following vulnerability has been resolved:
x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index()
hv_apicid_to_vp_index() currently uses the per-cpu hypercall input
and output pages. This function is called when running in VTL2 and
when running in an SEV-SNP CoCo VM with no paravisor. In the former
case, the output page is allocated, but in the latter case it is
not, so the hypervisor stores the output VP index in memory that has
not been allocated by the guest.
Fix this by using the input page for both input and output. The
hypercall has very small input and output, so sharing the same
page for both is straightforward. An alternative fix is to
allocate the per-cpu output page when running in an SEV-SNP CoCo
guest, but this uses significantly more memory, particularly
with larger vCPUs counts.20hCVE-2026-99261——
———In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: correct reservation fence slots for userq per-vm BOs eviction
It fixes both the move overflow and the eviction fence add for
evicting these per-vm BOs.13hCVE-2026-1209319.6 CRI—
———Out of bounds write in WebGL in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Critical)10hCVE-2026-121212——
———Incorrect authorization in Core in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)11hCVE-2026-1213927.4 HIG—
———FreeRDP before 3.32.2 contains an improper certificate validation vulnerability in tls_verify_certificate() that accepts Common Name fallback despite non-matching SAN entries and matches IP literals against DNS strings. Man-in-the-middle attackers holding a certificate from a client-trusted CA can bypass server identity checks to intercept RDP sessions, including keystrokes, clipboard, and screen content.11hCVE-2026-1166636.5 MED—
———Tanium addressed an improper access controls vulnerability in Enforce.9hCVE-2026-121522——
———In BuildKit versions v0.26.0 through v0.34.1, a specific build definition that resolves metadata for the same Git source reference twice can cause the BuildKit daemon to panic and crash, interrupting builds handled by that daemon. The issue is fixed in v0.34.2.10hCVE-2026-1213914.3 MED—
———FreeRDP from 3.0.0 before 3.32.2 contains a file descriptor leak in parallel_process_irp_create that fails to close previous descriptors on repeated IRP_MJ_CREATE requests. A hostile RDP server with parallel-device redirection enabled can send repeated CREATE requests to exhaust the client descriptor table and crash the process.11hCVE-2026-1213904.3 MED—
———FreeRDP 3.0.0 before 3.32.2 built with WITH_AAD=ON contains a reachable assertion because its ARM gateway response parser accepts a missing or non-string redirectedServerCert field and passes a null buffer to the certificate parser. A malicious or malformed user-selected gateway can return such a response to abort the client process.11hCVE-2026-1207577.1 HIG—
———HDF5 through 2.2.0 contains a heap buffer over-read vulnerability in H5L__extern_traverse() in src/H5Lexternal.c, the default traversal callback for external links. The callback locates the target file name and object path within the link’s user data using strlen() without validating the buffer against its stored size (udata_size, which was marked unused). A crafted HDF5 file containing an external link whose data is not NULL-terminated, or is too short to hold both strings, causes strlen() to read past the end of the udata heap buffer, and the derived object path pointer may also point outside the buffer. The overrun is unbounded and continues until a zero byte is found. The flaw is triggered when the malicious link is traversed, for example when opening an object through it. An attacker who can get a user or application to access a crafted file can cause a denial of service, and adjacent heap contents may be incorporated into the external file name or object path the library attempts to open.11hCVE-2026-1207566.1 MED—
———HDF5 through 2.2.0 contains a heap buffer over-read vulnerability in H5O__chunk_deserialize() in src/H5Ocache.c. When decoding object header messages, the declared message size is checked against the end of the chunk image before the remainder of the message header (flags, and for version 2 object headers, the optional creation index) has been decoded. Because the message body begins after these fields, a message can start up to four bytes further into the chunk than the size check accounts for. A crafted HDF5 file can declare a message size that passes the check but extends past the end of the chunk image, causing the message’s decode callback, for example H5O__mtime_new_decode() in src/H5Omtime.c, to read beyond the heap allocation. The flaw is reachable during H5Fopen() on a crafted file. An attacker who can get a user or application to open a malicious file can cause a denial of service or limited disclosure of process memory.11hCVE-2026-121138——
———Observable discrepancy in CORS in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: Low)11hCVE-2026-1166643.1 LOW—
———Tanium addressed an improper access controls vulnerability in Discover.9hCVE-2026-1207555.5 MED—
———HDF5 through 2.2.0 contains an out-of-bounds read vulnerability in H5Z__filter_szip() in src/H5Zszip.c. When decoding a szip-compressed chunk, the function subtracts the 4-byte uncompressed-length header from the chunk length without first verifying that the chunk is at least 4 bytes long. A truncated or corrupted chunk shorter than the header causes the length calculation to wrap around to a very large value, and the decompressor reads far past the end of the chunk buffer. An attacker who can get a user or application to read a dataset from a crafted HDF5 file can cause a denial of service. Only builds with szip support (libaec or the szip library) are affected.11hCVE-2026-957635.9 MED—
———An improper certificate validation vulnerability in HPE Networking Fabric Composer could allow an unauthenticated remote attacker to access sensitive information if certain preconditions outside of the attacker's control are met. Successful exploitation could allow an attacker to intercept transferred files and the stored credentials for remote servers.12hCVE-2026-1207543.3 LOW—
———HDF5 through 2.2.0 contains an uninitialized memory read vulnerability in H5Z__filter_scaleoffset() in src/H5Zscaleoffset.c. The decode path validates reads against the allocated size of the chunk buffer rather than the number of bytes actually read from the file. Because H5D__chunk_lock() deliberately sizes filtered chunk buffers to the larger of the stored and unfiltered chunk sizes and fills only the stored bytes, a truncated chunk passes these bounds checks and is decompressed from the uninitialized remainder of the allocation. Unrelated heap contents are then returned to the caller as dataset data. Because the reads remain within the allocation, the issue is not detected by AddressSanitizer. An attacker who can get a user or application to read a dataset from a crafted HDF5 file can cause disclosure of process memory. This issue exists because of an incomplete fix for CVE-2026-19029.11hCVE-2026-957388.1 HIG—
———Authentication bypass vulnerabilities in the affected interface of HPE Networking Fabric Composer could allow an unauthenticated remote attacker to circumvent existing authentication controls if certain preconditions outside of the attacker's control are met. Successful exploitation could allow an attacker to gain administrative access to the affected system.12hCVE-2026-121213——
———Uninitialized resource in Images in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High)11hCVE-2026-99260——
———In the Linux kernel, the following vulnerability has been resolved:
ntfs: fix resident conversion in ntfs_new_attr_flags
When setting sparse/compressed flags on a resident attribute, the
function skipped the resident-to-non-resident conversion and
terminated.13hCVE-2026-99257——
———In the Linux kernel, the following vulnerability has been resolved:
gpio: shared: gracefully handle no-device lookup of shared GPIOs
We use platform lookup tables for shared GPIOs. This mechanism needs a
struct device to work so fwnode-based lookup with no device associated
currently causes a NULL-pointer deference.
Adding this functionality will require a larger rework and it has never
worked anyway so add a check that allows the kernel to gracefully handle
this situation with an error ahead of implementing that functionality as
a new feature.20hCVE-2026-99254——
———In the Linux kernel, the following vulnerability has been resolved:
io_uring: don't flood a cancelling task with task_work
io_ring_exit_work() asks each task which has used the ring to remove its
tctx node, by task_work, and repeats that until the list is empty.
io_tctx_exit_cb() doesn't touch the node while the task is in
io_uring_cancel_generic(), which removes all the nodes at its end. So the
work item queues the callback again as soon as it has completed, for
nothing.
That is more than a waste of time. task_work_run() only returns when it
finds the list empty. If the rings are released from inside the
cancellation, because requests of other rings held the last references to
their files, up to 64 work items keep sending callbacks to the one task
which is running them. It never finds the list empty, never gets back to
the cancellation, the nodes stay, and so it goes on: a task with 60 pairs
of rings which poll each other ran 280000 callbacks in 5 seconds, 20
seconds after exit_group(). It ends when all the senders happen to be late
at the same time. Until then the task keeps a CPU and the work items busy.
An exiting task can't be killed meanwhile. execve() cancels the requests in
the same way, so a live task can get stuck there as well, for minutes. If
it takes more than five, the work items run into the
WARN_ON_ONCE(time_after(jiffies, timeout)) of io_ring_exit_work(). No
privilege is needed for any of this.
If the callback has met a task in cancellation, wait a little before it is
sent again. Nobody has to wake the work item up for that: either the node
is gone by then, or it is the turn of the next round.12hCVE-2026-99253——
———In the Linux kernel, the following vulnerability has been resolved:
io_uring/cancel: rearm local work wake up before sleep
io_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next
io_req_local_work_add() wakes the cancelling task. The add that takes the
count to zero is the only one that wakes, later ones see a count <= 0 and
return. io_uring_cancel_generic() however only becomes
TASK_INTERRUPTIBLE much later, so the one wake up can be spent on a
running task. That is fine as long as the entry of that add is still
queued, as the io_local_work_pending() check then skips the sleep. It is
not if the add was delayed after queueing its entry:
CPU0 (submitter in exec or exit) CPU1 (io_req_local_work_add)
mpscq_push(req A)
io_uring_try_cancel_requests()
io_run_local_work() // runs req A
io_uring_try_cancel_requests()
atomic_set(&ctx->cq_wait_nr, 1)
atomic_read(&ctx->cq_wait_nr) == 1
count taken, wake_up_state()
// task is running, no-op
prepare_to_wait(TASK_INTERRUPTIBLE)
io_local_work_pending() == false
schedule()
mpscq_push(req B)
cq_wait_nr <= 0, return
Only the sleeping task can run req B, so it is stuck in execve() until a
signal happens to wake it. An exiting task doesn't even get that.
Arm the count again once the task state is set and before the work list
is checked, for the rings whose local work this task is the one to run.12hCVE-2026-121215——
———UI misrepresentation in Bluetooth in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium)11hCVE-2026-99252——
———In the Linux kernel, the following vulnerability has been resolved:
io_uring/mpscq: disable preemption while pushing
A push makes the node the new tail, and then links it to its predecessor.
In between the queue isn't empty, but mpscq_pop() can't get at the node.
The consumers deal with that by trying again, with a cond_resched() in
the loop to give a preempted producer the chance to finish.
cond_resched() doesn't do that if the consumer has a higher priority than
the producer and both have to use the same CPU:
producer (SCHED_OTHER) consumer (SCHED_FIFO), same CPU
io_req_local_work_add()
mpscq_push()
prev = xchg(&q->tail, node)
<preempted> io_cqring_wait()
__io_run_local_work()
again:
cond_resched() // nothing to do
mpscq_pop() // NULL
// work pending, no events yet
goto again
The producer can be any task that is able to queue task_work for the
ring: an io-wq worker, or somebody who sends a message with
IORING_OP_MSG_RING. The consumer spins, holding ->uring_lock, until the
scheduler takes pity on the fair class, which takes about a second with
the default settings of the fair server, and forever without it. The
loops in tctx_task_work_run() and io_cancel_local_task_work() have the
same problem.
Don't allow preemption between the two steps. That bounds the time the
window is open on the CPU of the producer by what interrupts take, and a
consumer that waits for that is on another CPU. The cost is a
preempt_disable()/preempt_enable() pair per push.12hCVE-2026-1213893.1 LOW—
———FreeRDP from 3.27.0 before 3.32.2 contains a denial of service vulnerability in rdpdr_dump_packet that allows malicious RDP servers to abort clients by sending malformed RDPDR device-list announcements. Attackers can declare a DeviceDataLength exceeding the received packet, triggering a fatal Stream_Seek assertion when device redirection, TRACE logging, and WinPR assertions are enabled.11hCVE-2026-1213886.5 MED—
———FreeRDP from 3.0.0 before 3.32.2 contains an uncontrolled resource allocation vulnerability that allows malicious RDP servers to force large client allocations through the DRDYNVC DATA_FIRST Length field. Attackers can declare lengths up to 4,294,967,295 bytes on running dynamic channels, causing StreamPool_Take to reserve memory before body validation and exhaust client memory.9hCVE-2026-1197417.5 HIG—
———rsync through 3.5.1 contains a denial of service vulnerability in the delta-transfer sender's hash_search() in match.c that allows malicious receivers to trigger unbounded strong-checksum work at consecutive offsets. Unauthenticated attackers pulling from a public daemon module can supply weak checksums colliding with consecutive rolling windows plus non-matching strong checksums, exhausting sender CPU across concurrent connections.11hCVE-2026-121216——
———UI misrepresentation in UI in Google Chrome prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium)11hCVE-2026-1213874.3 MED—
———FreeRDP 2.0.0 before 3.32.2 contains an out-of-bounds read vulnerability in freerdp_dsp_decode_gsm610 that allows malicious RDP servers to read past audio buffers by sending truncated GSM610 frames. Attackers can negotiate GSM610 on rdpsnd and send a WAVE2 message shorter than a 33- or 32-byte WAV49 frame to crash the client.11hCVE-2026-1211269.6 CRI—
———Use after free in Core in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Critical)3hCVE-2026-121217——
———Use after free in Streaming in Google Chrome prior to 157.0.8103.38 allowed an adjacent attacker to execute arbitrary code inside the sandbox via crafted network traffic. (Chromium security severity: Low)11hCVE-2026-1211049.6 CRI—
———Incorrect authorization in FileSystem in Google Chrome prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)10hCVE-2026-1205675.4 MED—
———The MongoDB Entity Framework Core provider does not neutralize special elements when it places a caller-supplied value into a bulk update that is expressed as a databasea result, a value supplied as plain data may be interpreted by the database as expression syntax. A part value through normal application input may causeunintended modification of fields in the records the application is updating, and may cause data already held in those records to be relocated into other fields of the same record.12h