Vulnerabilities exploitable today
374,209in 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,710
New KEV · 24H0
Exploit Today ≥ 701,646
Distribution · last window
- Critical2,210
- High7,852
- Medium6,391
- Low708
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2024-47618—28.0%
——8——CVE-2010-2053—28.0%
——8——CVE-2021-1076—28.0%
——8——CVE-2019-14357—28.0%
——8——CVE-2025-12484—28.0%
——8——CVE-2026-137918.1 HIG28.0%
——8Insufficient validation of untrusted input in Downloads in Google Chrome prior to 150.0.7871.47 allowed an attacker who convinced a user to install a malicious extension to execute arbitrary code via a crafted Chrome Extension. (Chromium security severity: High)76dCVE-2019-11111—28.0%
——8——CVE-2025-7576—28.0%
——8——CVE-2005-0106—28.0%
——8——CVE-2025-6782—28.0%
——8——CVE-2026-155076.3 MED28.0%
——8A vulnerability was detected in coollabsio Coolify up to 4.1.1. The impacted element is an unknown function of the file /app/Policies/ of the component Policy Handler. Performing a manipulation results in missing authorization. Remote exploitation of the attack is possible. The exploit is now public and may be used.65dCVE-2026-155016.3 MED28.0%
——8A security vulnerability has been detected in AstrBotDevs AstrBot up to 4.25.2. Affected by this issue is the function ToolsRoute.test_mcp_connection of the file astrbot/dashboard/routes/tools.py of the component MCP Test Endpoint. The manipulation of the argument mcp_server_config.url leads to server-side request forgery. The attack is possible to be carried out remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.63dCVE-2026-31864—28.0%
——8——CVE-2008-3857—28.0%
——8——CVE-2009-0504—28.0%
——8——CVE-2024-55895—28.0%
——8——CVE-2001-0990—28.0%
——8——CVE-2024-43437—28.0%
——8——CVE-2015-7062—28.0%
——8——CVE-2026-744339.8 CRI28.0%
——8In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix UAF in rxgk_issue_challenge()
Fix rxgk_issue_challenge() to free the page containing the challenge
content after invoking the tracepoint as the whdr passed to the tracepoint
points into the page just freed.30dCVE-2014-6600—28.0%
——8——CVE-2024-28803—28.0%
——8——CVE-2014-6570—28.0%
——8——CVE-2022-509448.8 HIG28.0%
——8Aero CMS 0.0.1 contains a PHP code injection vulnerability that allows authenticated attackers to execute arbitrary PHP code by uploading malicious files through the image parameter. Attackers can upload PHP files with embedded code to the admin posts.php endpoint with source=add_post parameter, and the uploaded files are executed by the server.53dCVE-2008-5699—28.0%
——8——CVE-2001-1535—28.0%
——8——CVE-2006-4307—28.0%
——8——CVE-2024-32877—28.0%
——8——CVE-2011-0197—28.0%
——8——CVE-2025-24206—28.0%
——8——CVE-2003-0656—28.0%
——8——CVE-2025-10759—28.0%
——8——CVE-2007-5093—28.0%
——8——CVE-2025-147719.9 CRI28.0%
——8Files or directories accessible to external parties vulnerability in ABB T-MAC Plus.
This issue affects T-MAC Plus: 4.0-24.56dCVE-2004-1001—28.0%
——8——CVE-2023-25394—28.0%
——8——CVE-2026-463259.8 CRI28.0%
——8In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE
The current implementation incorrectly handles memory regions (MRs) with
page sizes different from the system PAGE_SIZE. The core issue is that
rxe_set_page() is called with mr->page_size step increments, but the
page_list stores individual struct page pointers, each representing
PAGE_SIZE of memory.
ib_sg_to_page() has ensured that when i>=1 either
a) SG[i-1].dma_end and SG[i].dma_addr are contiguous
or
b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned.
This leads to incorrect iova-to-va conversion in scenarios:
1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K):
ibmr->iova = 0x181800
sg[0]: dma_addr=0x181800, len=0x800
sg[1]: dma_addr=0x173000, len=0x1000
Access iova = 0x181800 + 0x810 = 0x182010
Expected VA: 0x173010 (second SG, offset 0x10)
Before fix:
- index = (0x182010 >> 12) - (0x181800 >> 12) = 1
- page_offset = 0x182010 & 0xFFF = 0x10
- xarray[1] stores system page base 0x170000
- Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong)
2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K):
ibmr->iova = 0x18f800
sg[0]: dma_addr=0x18f800, len=0x800
sg[1]: dma_addr=0x170000, len=0x1000
Access iova = 0x18f800 + 0x810 = 0x190010
Expected VA: 0x170010 (second SG, offset 0x10)
Before fix:
- index = (0x190010 >> 16) - (0x18f800 >> 16) = 1
- page_offset = 0x190010 & 0xFFFF = 0x10
- xarray[1] stores system page for dma_addr 0x170000
- Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong)
Yi Zhang reported a kernel panic[1] years ago related to this defect.
Solution:
1. Replace xarray with pre-allocated rxe_mr_page array for sequential
indexing (all MR page indices are contiguous)
2. Each rxe_mr_page stores both struct page* and offset within the
system page
3. Handle MR page_size != PAGE_SIZE relationships:
- page_size > PAGE_SIZE: Split MR pages into multiple system pages
- page_size <= PAGE_SIZE: Store offset within system page
4. Add boundary checks and compatibility validation
This ensures correct iova-to-va conversion regardless of MR page size
and system PAGE_SIZE relationship, while improving performance through
array-based sequential access.
Tests on 4K and 64K PAGE_SIZE hosts:
- rdma-core/pytests
$ ./build/bin/run_tests.py --dev eth0_rxe
- blktest:
$ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd
[1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/55dCVE-2014-6509—28.0%
——8——CVE-2023-1656—28.0%
——8——CVE-2025-61132—28.0%
——8——