PULSE
LIVE0signals / 24h
FEED
vulnKEV agrega CVE-2026-86060 — MikroTik / RouterOSvulnKEV agrega CVE-2026-67277 — MikroTik / RouterOSvulnKEV agrega CVE-2026-19490 — Citrix / NetScalervulnKEV agrega CVE-2025-25249 — Fortinet / Multiple ProductsvulnKEV agrega CVE-2026-87491 — Google / Chromium V8vulnKEV agrega CVE-2026-20079 — Cisco / Secure Firewall Management Center (FMC) and Security Cloud Control (SCC) Firewall ManagementvulnKEV agrega CVE-2026-75650 — Adobe / Commerce and MagentovulnKEV agrega CVE-2026-81963 — Microsoft / WindowsvulnKEV agrega CVE-2026-86218 — N-able / N-centralvulnKEV agrega CVE-2026-85880 — Microsoft / WindowsvulnKEV agrega CVE-2026-85046 — Google / Chromium V8vulnKEV agrega CVE-2026-59822 — BerriAI / LiteLLMvulnKEV agrega CVE-2026-48710 — Kludex / StarlettevulnKEV agrega CVE-2026-49869 — Kestra / Kestra OSSvulnKEV agrega CVE-2026-86060 — MikroTik / RouterOSvulnKEV agrega CVE-2026-67277 — MikroTik / RouterOSvulnKEV agrega CVE-2026-19490 — Citrix / NetScalervulnKEV agrega CVE-2025-25249 — Fortinet / Multiple ProductsvulnKEV agrega CVE-2026-87491 — Google / Chromium V8vulnKEV agrega CVE-2026-20079 — Cisco / Secure Firewall Management Center (FMC) and Security Cloud Control (SCC) Firewall ManagementvulnKEV agrega CVE-2026-75650 — Adobe / Commerce and MagentovulnKEV agrega CVE-2026-81963 — Microsoft / WindowsvulnKEV agrega CVE-2026-86218 — N-able / N-centralvulnKEV agrega CVE-2026-85880 — Microsoft / WindowsvulnKEV agrega CVE-2026-85046 — Google / Chromium V8vulnKEV agrega CVE-2026-59822 — BerriAI / LiteLLMvulnKEV agrega CVE-2026-48710 — Kludex / StarlettevulnKEV agrega CVE-2026-49869 — Kestra / Kestra OSS
CVE Watch372,926 in full archive

Vulnerabilities exploitable today

372,926in 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,705
New KEV · 24H0
Exploit Today ≥ 701,644

Distribution · last window

  • Critical
    2,236
  • High
    8,261
  • Medium
    6,234
  • Low
    615
Filters

Window

Severity

Flags

Vulnerabilities372,921–372,926 · 372,926
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-80927
In the Linux kernel, the following vulnerability has been resolved: timekeeping: Check the return value of tk_get_aux_ts64 in __do_adjtimex() If the auxiliary clock is disabled during tk_get_aux_ts64() but is enabled before tks->clock_valid is checked, then uninitialized stackdata will be used in the calculations and indirectly leaked to userspace. The same race window also exists after this change and also for the core timekeeper. But in these cases the only effect would be incorrect adjustments and this is userspace's responsibility to avoid this.6h
CVE-2026-80928
In the Linux kernel, the following vulnerability has been resolved: smack: fix cred UAF in smack_file_send_sigiotask() When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race.6h
CVE-2026-80929
In the Linux kernel, the following vulnerability has been resolved: sysctl: move the "cad_pid" entry from pid_table[] to kern_reboot_table[] cad_pid is global, and kill_cad_pid() is only used in the root namespace. However, due to pid_table_root_permissions(), a non-root user can unshare pid/user namespaces and modify it from the child namespace. This makes no sense and is simply wrong. Move it to kern_reboot_table[] where it logically belongs; this ensures that only GLOBAL_ROOT_UID can read/modify this sysctl. Note that this patch doesn't preserve "#ifdef CONFIG_PROC_SYSCTL" around the "cad_pid"; CONFIG_PROC_SYSCTL selects CONFIG_SYSCTL, so it is always set when kern_reboot_table[] is compiled.6h
CVE-2026-80930
In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper.6h
CVE-2026-89679
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix null dereference in nfsd4_setattr for deleg timestamp attrs When a SETATTR request includes FATTR4_WORD2_TIME_DELEG_ACCESS or FATTR4_WORD2_TIME_DELEG_MODIFY in the attribute bitmap, nfsd4_setattr() sets deleg_attrs=true and calls nfs4_preprocess_stateid_op() to validate the stateid. If the client supplies the NFSv4 "one stateid" (all-0xFF bytes), check_special_stateids() returns nfs_ok without populating the output nfs4_stid pointer, because the special-stateid path in nfs4_preprocess_stateid_op() jumps to done: with s==NULL, and the "if (s)" block that would set *cstid is skipped. The local variable `st` remains NULL. Back in nfsd4_setattr(), the if (deleg_attrs) block then unconditionally dereferences st->sc_type (at offset 4 from NULL), causing a kernel oops. This is remotely triggerable by any NFSv4 client: send COMPOUND [PUTROOTFH, SETATTR(ONE_STATEID, {bmval2=FATTR4_WORD2_TIME_DELEG_ACCESS, ...})]. No authentication, delegation, or prior state is required. Fix by adding a NULL check before the dereference. A special stateid is not a delegation stateid, so the existing nfserr_bad_stateid return value is already correct; we only need to guard the pointer dereference itself.6h
CVE-2026-89646
In the Linux kernel, the following vulnerability has been resolved: ceph: fix leaked inode reference on writeback abort at umount ceph_dirty_folio() takes a wrbuffer claim on each newly dirtied folio: it bumps i_wrbuffer_ref (taking an ihold() on the 0->1 transition) and attaches the snap_context to folio->private. That claim is released only by ceph_put_wrbuffer_cap_refs(), which for a submitted write runs from writepages_finish(). In ceph_submit_write(), if ceph_inc_osd_stopping_blocker() fails -- which happens during umount -- the request is aborted before submission: the already-collected folios are only redirtied and unlocked, so writepages_finish() never runs and the claim is leaked. redirty_page_for_writepage() -> folio_redirty_for_writepage() -> filemap_dirty_folio() sets PG_dirty directly and does not go through ->dirty_folio, so ceph_dirty_folio() is not re-entered to rebalance it. Because every subsequent writeback also fails the osd_stopping_blocker, i_wrbuffer_ref never returns to 0, the ihold() is never dropped, and the inode cannot be evicted: VFS: Busy inodes after unmount of ceph kernel BUG at fs/super.c:650! Release the orphaned claim in the abort path before redirtying, via ceph_undo_wrbuffer_claim(): detach the snap_context, drop the wrbuffer reference (letting i_wrbuffer_ref reach 0 and iput() the inode), and drop the snap_context reference -- i.e. do what writepages_finish() would have done for these never-submitted folios. Only the locked_pages entries are undone; folios still in the fbatch were never dirty-cleared by this call (folio_clear_dirty_for_io() is the ownership-transfer point, and a successful move NULLs the fbatch slot), so they hold no claim this call owns.6h