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,289
- High9,343
- Medium5,276
- Low508
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-73557—16.3%
——5vLLM is an inference and serving engine for large language models. From 0.20.2rc0 until 0.26.0, safe_load_prompt_embeds in vllm/renderers/embed_utils.py uses torch.sparse.check_sparse_tensor_invariants, whose process-global save, enable, and restore state can be raced by concurrent prompt_embeds parts submitted to POST /v1/chat/completions through AsyncMultiModalItemTracker.resolve_items, asyncio.gather, and the default executor, allowing an invalid sparse tensor to reach tensor.to_dense despite the CVE-2025-62164 guard when enable_prompt_embeds is enabled. This issue is fixed in version 0.26.0.16dCVE-2025-13861—16.3%
——5——CVE-2025-21133—16.3%
——5——CVE-2025-7802—16.3%
——5——CVE-2026-28675—16.3%
——5——CVE-2026-801795.9 MED16.3%
——5A flaw was found in jwcrypto. A remote attacker can send a specially crafted JSON Web Encryption (JWE) token containing numerous period delimiters. This malformed token can force the JWE.deserialize() function to allocate excessive memory, leading to a MemoryError. This issue results in a denial of service (DoS) for services that process untrusted JWE values.1dCVE-2022-49136—16.3%
——5——CVE-2025-2420—16.3%
——5——CVE-2021-27755—16.3%
——5——CVE-2025-55097—16.3%
——5——CVE-2021-27753—16.3%
——5——CVE-2026-43526—16.3%
——5——CVE-2024-5801—16.3%
——5——CVE-2026-33393—16.3%
——5——CVE-2025-52987—16.3%
——5——CVE-2025-68946—16.3%
——5——CVE-2026-355396.1 MED16.3%
——5An issue was discovered in Roundcube Webmail before 1.5.14 and 1.6.14. XSS exists because of insufficient HTML attachment sanitization in preview mode. A victim must preview a text/html attachment.36dCVE-2026-680858.0 HIG16.3%
——5In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled
HCI_UART_SENDING bit in tx_state means write_work is pending and blocks
queueing it again. Currently this bit is not cleared when canceling the
work in hci_uart_close(), which blocks future writes when device is
reopened later if write_work was pending.
Fix by clearing HCI_UART_SENDING when canceling the work.
Also make clearing of tx_skb safe by using disable_work_sync +
enable_work instead of just cancel_work_sync. hci_uart_flush() purges
the proto tx queue so we can cancel the pending write_work there,
instead of doing it just in hci_uart_close(). Re-enable and possibly
requeue the work after queue flush.13dCVE-2025-7812—16.3%
——5——CVE-2025-14129—16.3%
——5——CVE-2024-48881—16.3%
——5——CVE-2023-44210—16.3%
——5——CVE-2024-42191—16.3%
——5——CVE-2026-33488—16.3%
——5——CVE-2025-14352—16.3%
——5——CVE-2025-11979—16.3%
——5——CVE-2025-68942—16.3%
——5——CVE-2024-13695—16.3%
——5——CVE-2022-49062—16.3%
——5——CVE-2025-21134—16.3%
——5——CVE-2026-25209—16.3%
——5——CVE-2024-36293—16.3%
——5——CVE-2024-0892—16.3%
——5——CVE-2021-35056—16.3%
——5——CVE-2021-33058—16.3%
——5——CVE-2021-35957—16.3%
——5——CVE-2025-10258—16.3%
——5——CVE-2021-28817—16.3%
——5——CVE-2025-4684—16.3%
——5——CVE-2025-32303—16.3%
——5——