Vulnerabilities exploitable today
10,064in 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,644
New KEV · 24H0
Exploit Today ≥ 701,579
Distribution · last window
- Critical1,299
- High4,252
- Medium3,580
- Low277
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-285263.5 LOW4.0%
——1BlueKitchen BTstack versions prior to 1.8.1 contain an out-of-bounds read vulnerability in the AVRCP Controller LIST_PLAYER_APPLICATION_SETTING_ATTRIBUTES and LIST_PLAYER_APPLICATION_SETTING_VALUES handlers that allows attackers to read beyond buffer boundaries. A nearby attacker with a paired Bluetooth Classic connection can send a specially crafted VENDOR_DEPENDENT response with an attacker-controlled count value to trigger an out-of-bounds read from the L2CAP receive buffer, potentially causing a crash on resource-constrained devices.3dCVE-2026-16966.1 MED4.0%
——1Some HTTP security headers are not properly set by the web server when sending responses to the client application.8dCVE-2026-592086.8 MED4.0%
——1n8n is an open source workflow automation platform. Prior to 2.27.4 and from 2.28.0 prior to 2.28.1, n8n instances configured with more than one trusted token-exchange issuer resolved external identities to local accounts using only the JWT sub claim and ignored the iss claim, allowing an attacker with a valid token from one trusted issuer and a sub matching a victim under another issuer to authenticate as that victim. This issue is fixed in versions 2.27.4 and 2.28.1.4dCVE-2026-547837.4 HIG4.0%
——1CoreWCF is a port of the service side of Windows Communication Foundation (WCF) to .NET Core. Prior to 1.8.1 and 1.9.1, CoreWCF WS-Security endorsing and supporting signature verification does not ensure the selected ds:Signature covers the expected Security header target, allowing an attacker with one captured signed SOAP envelope to replay arbitrary service operations as the victim principal. This issue is fixed in versions 1.8.1 and 1.9.1.7dCVE-2026-448947.5 HIG4.0%
——1Netty is a network application framework for development of protocol servers and clients. NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version 4.2.15.Final, its writeToken() returns false (server will not send Retry — acceptable), but validateToken() unconditionally `return 0`. In QuicheQuicServerCodec.handlePacket(), a non-negative return from validateToken() is interpreted as 'token is valid, ODCID starts at offset 0', causing the server to call quiche_accept as if the client's address had been validated by a Retry round-trip. Per RFC 9000 §8.1, a validated address lifts the 3× anti-amplification send limit. Thus any attacker who includes ANY non-empty token bytes in an Initial packet — with a spoofed victim source IP — causes the Netty server to treat the victim as validated and reflect full-size handshake flights (certificates, etc.) toward it without the 3× cap. The correct 'no token handler' semantics would be to return -1 (invalid) so the normal un-validated path and amplification limit apply. Version 4.2.15.Final patches the issue.3dCVE-2025-607497.8 HIG4.0%
——1DLL Hijacking vulnerability in Trimble SketchUp desktop 2025 via crafted libcef.dll used by sketchup_webhelper.exe.13dCVE-2026-242727.8 HIG4.0%
——1NVIDIA TensorRT contains a vulnerability where an attacker might cause an overflow to a heap-based buffer. A successful exploit of this vulnerability might lead to code execution.12hCVE-2026-242387.8 HIG4.0%
——1NVIDIA TensorRT for contains a vulnerability where an attacker might cause an improper validation of array index. A successful exploit of this vulnerability might lead to code execution.12hCVE-2025-409456.7 MED4.0%
——1A vulnerability has been identified in COMOS V10.4.5 (All versions < V10.4.5.0.2), COMOS V10.6 (All versions < V10.6.1), Designcenter NX (All versions < V2512.7000), Simcenter 3D (All versions < V2512.7000), Simcenter Femap V2506 (All versions < V2506.0003), Simcenter Femap V2512 (All versions < V2512.0002), Simcenter Nastran (All versions < V2606), Simcenter STAR-CCM+ (All versions < V2606), Solid Edge SE2025 (All versions < V225.0 Update 13), Solid Edge SE2026 (All versions < V226.0 Update 04), Teamcenter Visualization V2412 (All versions < V2412.0012), Teamcenter Visualization V2506 (All versions < V2506.0009), Teamcenter Visualization V2512 (All versions < V2512.2605), Tecnomatix Plant Simulation V2404 (All versions < V2404.0022), Tecnomatix Plant Simulation V2504 (All versions < V2504.0010), Tecnomatix Process Simulate (All versions < V2606). Untrusted search path in IAM Client SDK may allow an authenticated user to potentially enable escalation of privilege via local access.2dCVE-2026-108344.6 MED4.0%
——1The WP Travel Engine WordPress plugin before 6.8.1 does not properly validate the source of a user-supplied profile image path before moving the file, allowing authenticated users with subscriber-level access and above to relocate arbitrary files within the WordPress uploads directory into their own profile-image path. This removes the targeted media from its original location and can break content across the site.8dCVE-2026-54893—4.0%
——1URL path injection in the Microsoft Graph adapter of Swoosh. Swoosh.Adapters.MsGraph builds its Microsoft Graph API request URL by interpolating the sender's email address into the URL path (/users/{from}/sendMail) without percent-encoding or validation.
In applications that derive the from address from untrusted or user-influenced input (for example a relay, a contact form, or a "send as" feature), an attacker can place URL-special characters such as /, ?, or # in the local part of the address to escape the intended path segment and rewrite the path and query string of the request. Because the same authenticated POST is sent with the application's Microsoft Graph bearer token, the attacker can redirect it to other Graph endpoints within the token's scopes and control the request's query string. Applications that always use a fixed, trusted from address are not affected.
This issue affects swoosh from 1.12.0 before 1.26.3.11dCVE-2026-69007.4 HIG4.0%
——1Improper certificate validation vulnerability in B&R Industrial Automation GmbH APROL.
This issue affects APROL: before R 4.4-01P5.11dCVE-2026-577668.8 HIG4.0%
——1Unauthenticated Cross Site Request Forgery (CSRF) in WPIDE – File Manager & Code Editor <= 3.5.6 versions.15dCVE-2026-577598.8 HIG4.0%
——1Unauthenticated Cross Site Request Forgery (CSRF) in ProfileGrid <= 5.9.9.7 versions.15dCVE-2026-437247.8 HIG4.0%
——1The issue was addressed with improved input sanitization. This issue is fixed in iOS 26.5.2 and iPadOS 26.5.2, macOS Tahoe 26.5.2. An app may be able to cause unexpected system termination or write kernel memory.17dCVE-2026-543697.1 HIG4.0%
——1acl before version 2.4.0 contains a symlink traversal vulnerability in the libacl pathname-based functions acl_get_file(), acl_set_file(), acl_extended_file(), and acl_delete_def_file() that allows local attackers to escalate privileges by replacing any pathname component with a symbolic link. Attackers who control any component of a pathname processed by a privileged caller can redirect ACL read or write operations to arbitrary files or directories, enabling unauthorized manipulation of access control lists and local privilege escalation.3dCVE-2026-531437.8 HIG4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11
The v11 MQD manager incorrectly assigned the CP-compute variants of
checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions
use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct
v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow.
During CRIU checkpoint of an SDMA queue on Navi3x:
- checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer,
leaking 1536 bytes of adjacent GTT memory to userspace
During CRIU restore:
- restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer,
corrupting 1536 bytes of adjacent GTT memory (often the ring buffer
or neighboring MQDs)
This is a copy-paste regression unique to v11. All other ASIC backends
(cik, vi, v9, v10, v12) correctly use the SDMA-specific variants.
Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly
handle the smaller v11_sdma_mqd structure, matching the pattern used in
other MQD managers.
(cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)3dCVE-2026-462947.8 HIG4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
dm: fix a buffer overflow in ioctl processing
Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the
function retrieve_status:
1. The code in retrieve_status checks that the output string fits into
the output buffer and writes the output string there
2. Then, the code aligns the "outptr" variable to the next 8-byte
boundary:
outptr = align_ptr(outptr);
3. The alignment doesn't check overflow, so outptr could point past the
buffer end
4. The "for" loop is iterated again, it executes:
remaining = len - (outptr - outbuf);
5. If "outptr" points past "outbuf + len", the arithmetics wraps around
and the variable "remaining" contains unusually high number
6. With "remaining" being high, the code writes more data past the end of
the buffer
Luckily, this bug has no security implications because:
1. Only root can issue device mapper ioctls
2. The commonly used libraries that communicate with device mapper
(libdevmapper and devicemapper-rs) use buffer size that is aligned to
8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input
buffer and the bug can't happen accidentally9dCVE-2026-316417.8 HIG4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix RxGK token loading to check bounds
rxrpc_preparse_xdr_yfs_rxgk() reads the raw key length and ticket length
from the XDR token as u32 values and passes each through round_up(x, 4)
before using the rounded value for validation and allocation. When the raw
length is >= 0xfffffffd, round_up() wraps to 0, so the bounds check and
kzalloc both use 0 while the subsequent memcpy still copies the original
~4 GiB value, producing a heap buffer overflow reachable from an
unprivileged add_key() call.
Fix this by:
(1) Rejecting raw key lengths above AFSTOKEN_GK_KEY_MAX and raw ticket
lengths above AFSTOKEN_GK_TOKEN_MAX before rounding, consistent with
the caps that the RxKAD path already enforces via AFSTOKEN_RK_TIX_MAX.
(2) Sizing the flexible-array allocation from the validated raw key
length via struct_size_t() instead of the rounded value.
(3) Caching the raw lengths so that the later field assignments and
memcpy calls do not re-read from the token, eliminating a class of
TOCTOU re-parse.
The control path (valid token with lengths within bounds) is unaffected.3dCVE-2026-314477.8 HIG4.0%
——1In the Linux kernel, the following vulnerability has been resolved:
ext4: reject mount if bigalloc with s_first_data_block != 0
bigalloc with s_first_data_block != 0 is not supported, reject mounting
it.3dCVE-2025-507538.4 HIG4.0%
——1Mitrastar GPT-2741GNAC-N2 devices are provided with access through ssh into a restricted default shell.The command "deviceinfo show file" is supposed to be used from restricted shell to show files and directories. By providing " /bin/sh" (quotes included) to the argument of this command will drop a root shell.12dCVE-2026-453377.6 HIG3.9%
——1Better Auth is an authentication and authorization library for TypeScript. From 1.6.0 until 1.6.11, the deviceAuthorization plugin treats any authenticated session as the owner of any pending device code because GET /device does not claim the row and POST /device/approve and POST /device/deny short-circuit when userId is unset, allowing an authenticated attacker who learns a valid user_code to bind the polling device to the attacker's account or deny the legitimate flow. This issue is fixed in version 1.6.11.2dCVE-2026-598385.9 MED3.9%
——1A improper neutralization of script-related html tags in a web page (basic xss) vulnerability in Fortinet FortiSIEM 7.4.0, FortiSIEM 7.3.0 through 7.3.4, FortiSIEM 7.2.0 through 7.2.6, FortiSIEM 7.1 all versions, FortiSIEM 7.0 all versions, FortiSIEM 6.7 all versions, FortiSIEM 6.6 all versions, FortiSIEM 6.5 all versions, FortiSIEM 6.4 all versions may allow attacker to execute unauthorized code or commands via <insert attack vector here>2dCVE-2026-585596.5 MED3.9%
——1DoS vulnerability in the vibration service. Impact: Successful exploitation of this vulnerability may affect availability.2dCVE-2026-447604.7 MED3.9%
——1Due to a Cross-Site Scripting (XSS) vulnerability, applications based on Business Server Pages framework in SAP NetWeaver Application Server ABAP reflects unsanitized input into the HTTP response which allows an attacker to inject and execute arbitrary JavaScript code under certain conditions. Successful exploitation could allow the attacker to steal session information, perform authenticated actions on behalf of the victim user etc. This vulnerability has low impact on confidentiality and integrity of the data and no impact on application 's availability.3dCVE-2026-319815.9 MED3.9%
——1A Stored HTML Injection vulnerability was discovered in the Diagram tab and Graph view due to a shared input validation function being insufficiently restrictive. An authenticated user with administrative privileges can inject malicious HTML tags into N2OS configuration data through multiple input vectors. When a victim views the affected data in the Diagram tab and Graph view, the injected HTML renders in their browser, enabling phishing and possibly open redirect attacks. Full XSS exploitation and direct information disclosure are prevented by the existing input validation and Content Security Policy configuration.7dCVE-2026-146124.2 MED3.9%
——1Two off-by-one errors in the FreeIPA ipa-otpd daemon's OAuth2 device authorization handler can cause out-of-bounds memory access when processing an oversized response from a configured external OAuth2/OIDC Identity Provider. An attacker who controls or can man-in-the-middle the IdP endpoint may be able to trigger ipa-otpd to write or read one byte past the end of a fixed-size buffer. Exploitation requires FreeIPA to be configured with an external IdP, attacker control or MITM of that IdP, and a user to initiate the OAuth2 device authorization flow. The most likely impact is limited denial of service affecting the ipa-otpd daemon.10dCVE-2026-580354.8 MED3.9%
——1Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Wikimedia Foundation MediaWiki.
This vulnerability is associated with program files resources/src/mediawiki.Special.Block/SpecialBlock.Vue.8dCVE-2026-580344.8 MED3.9%
——1Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Wikimedia Foundation CheckUser.
This vulnerability is associated with program files modules/ext.CheckUser.TempAccounts/components/blockConnectedTempAccountsField.Vue.
This issue affects CheckUser: from 1.46.0-rc.0 before 1.46.0.8dCVE-2026-140924.3 MED3.9%
——1Insufficient policy enforcement in Privacy in Google Chrome prior to 150.0.7871.47 allowed an attacker in a privileged network position to leak cross-origin data via malicious network traffic. (Chromium security severity: Low)16dCVE-2026-234745.5 MED3.9%
——1In the Linux kernel, the following vulnerability has been resolved:
mtd: Avoid boot crash in RedBoot partition table parser
Given CONFIG_FORTIFY_SOURCE=y and a recent compiler,
commit 439a1bcac648 ("fortify: Use __builtin_dynamic_object_size() when
available") produces the warning below and an oops.
Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000
------------[ cut here ]------------
WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1
memcmp: detected buffer overflow: 15 byte read of buffer size 14
Modules linked in:
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE
As Kees said, "'names' is pointing to the final 'namelen' many bytes
of the allocation ... 'namelen' could be basically any length at all.
This fortify warning looks legit to me -- this code used to be reading
beyond the end of the allocation."
Since the size of the dynamic allocation is calculated with strlen()
we can use strcmp() instead of memcmp() and remain within bounds.3dCVE-2026-230865.5 MED3.9%
——1In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: cap TX credit to local buffer size
The virtio transports derives its TX credit directly from peer_buf_alloc,
which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.
On the host side this means that the amount of data we are willing to
queue for a connection is scaled by a guest-chosen buffer size, rather
than the host's own vsock configuration. A malicious guest can advertise
a large buffer and read slowly, causing the host to allocate a
correspondingly large amount of sk_buff memory.
The same thing would happen in the guest with a malicious host, since
virtio transports share the same code base.
Introduce a small helper, virtio_transport_tx_buf_size(), that
returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume
peer_buf_alloc.
This ensures the effective TX window is bounded by both the peer's
advertised buffer and our own buf_alloc (already clamped to
buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer
cannot force the other to queue more data than allowed by its own
vsock settings.
On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with
32 guest vsock connections advertising 2 GiB each and reading slowly
drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only
recovered after killing the QEMU process. That said, if QEMU memory is
limited with cgroups, the maximum memory used will be limited.
With this patch applied:
Before:
MemFree: ~61.6 GiB
Slab: ~142 MiB
SUnreclaim: ~117 MiB
After 32 high-credit connections:
MemFree: ~61.5 GiB
Slab: ~178 MiB
SUnreclaim: ~152 MiB
Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest
remains responsive.
Compatibility with non-virtio transports:
- VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per
socket based on the local vsk->buffer_* values; the remote side
cannot enlarge those queues beyond what the local endpoint
configured.
- Hyper-V's vsock transport uses fixed-size VMBus ring buffers and
an MTU bound; there is no peer-controlled credit field comparable
to peer_buf_alloc, and the remote endpoint cannot drive in-flight
kernel memory above those ring sizes.
- The loopback path reuses virtio_transport_common.c, so it
naturally follows the same semantics as the virtio transport.
This change is limited to virtio_transport_common.c and thus affects
virtio-vsock, vhost-vsock, and loopback, bringing them in line with the
"remote window intersected with local policy" behaviour that VMCI and
Hyper-V already effectively have.
[Stefano: small adjustments after changing the previous patch]
[Stefano: tweak the commit message]3dCVE-2025-605357.3 HIG3.9%
——1A Cross-Site Request Forgery (CSRF) in the component /endpoints/currency/currency of Wallos v4.1.1 allows attackers to execute arbitrary operations via a crafted GET request.13dCVE-2026-429367.8 HIG3.9%
——1The installer of HYPER SBI 2 insecurely loads Dynamic Link Libraries. If there is a crafted DLL at the same directory when invoking the affected installer, arbitrary code may be executed with the privilege of the user invoking the installer.2dCVE-2026-156847.3 HIG3.9%
——1Glarysoft Glary Utilities Link Following Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Glarysoft Glary Utilities. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.
The specific flaw exists within the Disk Clean functionality. By creating a junction, an attacker can abuse the service to delete arbitrary files. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-27004.3dCVE-2026-147575.3 MED3.9%
——1A vulnerability was determined in radareorg radare2 up to 6.1.6. This affects the function core_anal_bytes of the file libr/core/cmd_anal.inc. This manipulation causes integer overflow. The attack needs to be launched locally. The exploit has been publicly disclosed and may be utilized. It is suggested to install a patch to address this issue.10dCVE-2026-529127.8 HIG3.9%
——1In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_queue: hold bridge skb->dev while queued
br_pass_frame_up() rewrites skb->dev from the ingress port to the bridge
master before queueing bridge LOCAL_IN packets. NFQUEUE only holds
references on state.in/out and bridge physdevs, so a queued bridge
packet can retain a freed bridge master in skb->dev until reinjection.
When the verdict is reinjected later, br_netif_receive_skb() re-enters
the receive path with skb->dev still pointing at the freed bridge master,
triggering a use-after-free.
Store skb->dev in the queue entry, hold a reference on it for the queue
lifetime, and use the saved device when dropping queued packets during
NETDEV_DOWN handling.9dCVE-2026-568157.4 HIG3.9%
——1pwnlift before d7a9544, in a privileged deployment, contains a symlink following vulnerability in the upload handler in Components/Pages/Home.razor.15dCVE-2026-502577.8 HIG3.9%
——1A use-after-free flaw was found in the X.Org X server and Xwayland in miSyncDestroyFence(). A client that sets up multiple fence triggers can trigger a use-after-free function pointer call. An attacker would connect to the X server to set up a fence and await that fence, then a second X connection destroys the fence, causing the use-after-free. This may be used to crash the server, or for privilege escalation if the X server runs as root.3dCVE-2026-461767.8 HIG3.9%
——1In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix error path fall-through in mlx5_ib_dev_res_srq_init()
mlx5_ib_dev_res_srq_init() allocates two SRQs, s0 and s1. When
ib_create_srq() fails for s1, the error branch destroys s0 but falls
through and unconditionally assigns the freed s0 and the ERR_PTR s1 to
devr->s0 and devr->s1.
This leads to several problems: the lock-free fast path checks
"if (devr->s1) return 0;" and treats the ERR_PTR as already initialised;
users in mlx5_ib_create_qp() dereference the freed SRQ or ERR_PTR via
to_msrq(devr->s0)->msrq.srqn; and mlx5_ib_dev_res_cleanup() dereferences
the ERR_PTR and double-frees s0 on teardown.
Fix by adding the same `goto unlock` in the s1 failure path.3d