Vulnerabilities exploitable today
403,426in 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,756
New KEV · 24H0
Exploit Today ≥ 701,689
Distribution · last window
- Critical5,556
- High21,532
- Medium19,936
- Low2,099
Filters
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-65222——
———Rejected reason: The reported issue could not be reproduced, and the affected products are end-of-life. This CVE ID is unused by the CNA.10hCVE-2026-77060——
———boneIO black_debian_images stores the Mosquitto MQTT broker password file at /etc/mosquitto/passwd with world-readable permissions. Any local user can read the password hashes for all MQTT accounts and perform offline dictionary attacks.
This issue was fixed in version 1.6.0.9hCVE-2026-77061——
———boneIO Black directly excludes several API endpoints from the authentication. An unauthenticated remote attacker on the local network can retrieve system logs, firmware version, serial number, MQTT username, configuration file listings, and API documentation. This data aids reconnaissance and enables targeted attacks against the device.
This issue was fixed in version 1.6.0: every API route requires an authenticated role, the interactive API documentation is disabled, and the serial number is withheld from anonymous callers.9hCVE-2026-112525——
———An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An app may be able to cause unexpected system termination or read kernel memory.5hCVE-2026-77062——
———The boneIO Black web interface lacks proper clickjacking protections. A remote attacker can embed the control panel in an iframe on a malicious web page and trick an authenticated user on the internal network into clicking buttons that activate relays, open gates, or control blinds. This can lead to unauthorized state changes with potential physical safety consequences. Critically, due to CVE-2026-77053 (authentication disabled by default), any user on the same internal network can trigger attacker-controlled actions by visiting the malicious website.
This issue was fixed in version 1.6.0.9hCVE-2026-112524——
———A use-after-free issue was addressed with improved memory management. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An app may be able to cause unexpected system termination or corrupt kernel memory.5hCVE-2026-112495——
———An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An app may be able to cause unexpected system termination or read kernel memory.5hCVE-2026-921716.5 MED—
———A flaw was found in the Infinispan Operator for Red Hat Data Grid. When cross-site (xsite) TLS is enabled, the operator launches the Gossip Router container with keystore and truststore passwords passed as plain-text command-line arguments (`-tls_keystore_password`, `-tls_truststore_password`). Container args are stored in the Pod spec and visible to any principal with `get pods` permission in the namespace (no `get secrets` required), to node-level processes via `/proc/<pid>/cmdline`, and frequently captured in audit/event logs.9hCVE-2026-112523——
———This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An app may be able to access user-sensitive data.5hCVE-2026-112497——
———This issue was addressed with improved permissions checking. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An app may be able to break out of its sandbox.5hCVE-2026-65221——
———Rejected reason: The reported issue was assessed as intended functionality. This CVE ID is unused by the CNA.10hCVE-2026-93328——
———Path Traversal and Missing Authorization in cloud-storage source in Google Cloud MCP Toolbox for Databases (googleapis/mcp-toolbox) versions 1.2.0 through 1.4.0 allows an unauthenticated remote attacker to exfiltrate host files to external Google Cloud Storage buckets and overwrite arbitrary local files via crafted tool invocation parameters.9hCVE-2026-938473.5 LOW—
———Mattermost versions 11.7.x <= 11.7.10 fail to validate reserved system post types on the scheduled post creation and publication paths which allows an authenticated channel member to publish messages rendering as trusted system events via the scheduled post endpoint.. Mattermost Advisory ID: MMSA-2026-007329hCVE-2026-938482.7 LOW—
———Mattermost versions 11.7.x <= 11.7.10 fail to apply outbound internal-connection filtering to the OpenID discovery endpoint request which allows a System Administrator to determine whether internal addresses and ports are reachable from the server via an unauthenticated login request that triggers the discovery fetch.. Mattermost Advisory ID: MMSA-2026-007749hCVE-2026-112522——
———An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. Processing a maliciously crafted file may lead to unexpected app termination.5hCVE-2026-938496.5 MED—
———Mattermost versions 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10, 11.10.x <= 11.10.1 Mattermost fail to apply allocation limits to the byte-string decode paths in its WebSocket msgpack decoder, which allows an authenticated remote attacker to cause excessive server memory allocation via a crafted binary WebSocket frame declaring a Bin32 payload length of up to 4,294,967,295 bytes.. Mattermost Advisory ID: MMSA-2026-007689hCVE-2026-65218——
———Rejected reason: The reported issue is tracked under CVE-2026-18451. This CVE ID is rejected as a duplicate.10hCVE-2026-112521——
———A buffer overflow was addressed with improved bounds checking. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. A sandboxed process may be able to circumvent sandbox restrictions.5hCVE-2026-938506.5 MED—
———Mattermost versions 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10, 11.10.x <= 11.10.1 fail to bind the volume of text extracted from an uploaded PDF which allows an authenticated user to exhaust server memory and cause a denial of service via a crafted PDF whose compressed content stream expands into a very large amount of text.. Mattermost Advisory ID: MMSA-2026-007699hCVE-2026-65217——
———Rejected reason: The reported issue could not be reproduced. This CVE ID is unused by the CNA.10hCVE-2026-943864.8 MED—
———Use of Cache Containing Sensitive Information vulnerability in Apache Camel Oauth component.
This issue affects Apache Camel: from 4.19.0 before 4.22.2.
OAuthClientCredentialsTokenResolver obtains OAuth 2.0 bearer tokens through the client credentials grant on behalf of the components that authenticate their outbound calls with a named OAuth profile, such as camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat and the IBM watsonx components, and of applications that call the OAuthClientAuthenticationFactory SPI directly. It kept the tokens it obtained in a static cache shared by every resolver instance and every CamelContext in the JVM, and keyed that cache on the token endpoint and the client ID only, although the token request also carries the client secret and the requested scope. Two profiles that share a token endpoint and a client ID but request different scopes, or authenticate with different client secrets, therefore mapped to the same cache entry: the profile that resolved a token first populated the entry, and the other profile was then handed that token, with no token request made under its own configuration, for as long as the token remained valid. Token caching is enabled by default, and pointing several profiles at one identity provider client is an ordinary use of the profile support rather than an opt-in to an insecure setting. The outcome is an outbound request that carries a token issued for another profile's scope, which can grant broader authority than the calling profile was configured for, or reach a service the token was not issued for; with identity providers that derive a token's audience from the requested scope, a different scope can mean a token for a different service altogether. A profile configured with a different client secret was likewise served the token obtained with the other secret, without authenticating with its own. The profiles are configured by the deployment, which is trusted, so no untrusted input reaches the cache: the party that gains is the service that receives a token it was not meant to receive, which, if hostile or compromised, can replay that token within its scope. Reaching the issue requires a deployment that defines more than one profile sharing a token endpoint and client ID while differing in scope or client secret.
Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. The 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile’s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID.9hCVE-2026-112519——
———An integer overflow was addressed with improved input validation. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. Connecting to a malicious VNC server may cause a denial-of-service.5hCVE-2026-65216——
———Rejected reason: The reported issue is tracked under CVE-2026-18450. This CVE ID is rejected as a duplicate.10hCVE-2026-99089——
———In the Linux kernel, the following vulnerability has been resolved:
ASoC: samsung: i2s: enable op_clk in probe to balance runtime PM
The probe function puts the device into the runtime PM active state with
only the "iis" bus clock enabled, but it also sets priv->op_clk to the
parent of the RCLK_SRC mux without enabling it. The runtime PM suspend
callback disables both clocks, so the first runtime suspend after probe
disables op_clk once more than it was enabled.
On Exynos5250 Arndale both clocks resolve to the same EXYNOS_I2S_BUS gate,
so this triggers the following warning during boot:
WARNING: drivers/clk/clk.c:1270 at clk_core_disable+0xe4/0x23c, CPU#0: kworker/u8:3/45
i2s_bus already disabled
...
Workqueue: pm pm_runtime_work
Call trace:
...
clk_core_disable from clk_disable+0x28/0x34
clk_disable from i2s_runtime_suspend+0x58/0x68 [snd_soc_i2s]
i2s_runtime_suspend [snd_soc_i2s] from genpd_runtime_suspend+0xc4/0x298
genpd_runtime_suspend from __rpm_callback+0x48/0x18c
__rpm_callback from rpm_callback+0x4c/0x50
rpm_callback from rpm_suspend+0xf4/0x718
rpm_suspend from pm_runtime_work+0x9c/0xa0
...
Fix this by enabling op_clk in probe right after getting it, so the clock
state matches the runtime PM active state, and by disabling it in remove.11hCVE-2026-99090——
———In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: serialize vblank counter reads against GPU reset
The vblank counter callback reads display registers and scanout
position without holding reset_domain->sem. During GPU recovery,
display commit work can call the callback while reset owns the
semaphore for writing. The hardware access then triggers the
lockdep_assert_held() in amdgpu_device_skip_hw_access() and sets
TAINT_WARN when lockdep is enabled.
Try to acquire the reset semaphore for reading before accessing the
hardware, and hold it across the counter and scanout-position reads.
If reset is already in progress, return DRM's cached software vblank
count instead. This avoids blocking behind reset and avoids accessing
display hardware while it is being reset.
The cached count is less accurate than the hardware count, but is
used only when reset prevents a safe hardware read. This addresses
the reset-time warning from this vblank path; it does not suppress or
fix unrelated lockdep warnings.
(cherry picked from commit 51a4359f7431a4be5e42803c8bdaf7e0e5be2934)11hCVE-2026-99092——
———In the Linux kernel, the following vulnerability has been resolved:
riscv: patch: fix handling of bpf-jit execmem addresses
Commit 8718e5a3090b ("riscv: patch: skip fixmap mapping when kernel text
is already writable") gated the core_kernel_text() branch of patch_map()
on CONFIG_STRICT_KERNEL_RWX, and explicitly left the vmalloc branch
unchanged. That branch has a separate problem.
That branch only creates a temporary writable fixmap alias when
CONFIG_STRICT_MODULE_RWX is enabled, and otherwise assumes the target is
directly writable and returns the address unchanged. That assumption no
longer holds: bpf_prog_pack_alloc calls set_memory_rox() on every pack
unconditionally in alloc_new_pack(), independently of any
CONFIG_STRICT_*_RWX option, so BPF text in the vmalloc area is read-only
regardless of what CONFIG_STRICT_MODULE_RWX says.
With CONFIG_STRICT_MODULE_RWX=n, patch_map() returns the read-only
address directly, the subsequent copy_to_kernel_nofault() takes a
page fault and returns -EFAULT. bpf_arch_text_copy() turns that into
-EINVAL, which propagates through bpf_jit_binary_pack_finalize() to the
WARN_ON() in bpf_int_jit_compile() and leaves the program un-JITed.
Note that BPF cannot be fixed the way kprobes was in
commit bdc46e507b59 ("riscv: mm: make EXECMEM_KPROBES writable without
CONFIG_STRICT_MODULE_RWX"). EXECMEM_BPF is already PAGE_KERNEL, i.e.
writable at allocation time; the read-only mapping is established
afterwards by generic code in alloc_new_pack(), which arch code cannot
influence. The only place this can be handled is patch_map().
This is the same problem that was fixed on arm64 by commit b1480ed230ac
("arm64: patching: fix handling of execmem addresses"), and the fix is
the same: CONFIG_EXECMEM is what actually tracks whether the vmalloc
area can hold executable memory that needs a temporary alias to be
written. CONFIG_BPF_JIT, CONFIG_KPROBES and CONFIG_MODULES all select
it.
Note that this is not limited to CONFIG_MODULES=n. Unlike arm64, riscv
selects CONFIG_ARCH_OPTIONAL_KERNEL_RWX, so CONFIG_STRICT_MODULE_RWX can
be disabled with CONFIG_MODULES=y as well, and the bug is reachable in
that configuration too.
The !CONFIG_MMU build is unaffected: it has its own __patch_insn_set()
and __patch_insn_write() implementations and never calls patch_map().11hCVE-2026-112498——
———An access issue was addressed with additional sandbox restrictions. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An app may be able to break out of its sandbox.5hCVE-2026-99093——
———In the Linux kernel, the following vulnerability has been resolved:
mm: don't schedule deferred kernel page table freeing while booting
Booting with a boot-time function tracer and a filter, for example
ftrace=function ftrace_filter=pud_free_pmd_page
panics on 7.3-rc4 as soon as the tracer starts:
[ 23.531178] Starting tracer 'function'
[ 23.675800] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN NOPTI
[ 23.819917] KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7]
[ 23.964025] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.3.0-rc4-fe2ec83746e5-with-fixes-v2+ #195 PREEMPT(undef)
[ 24.252248] RIP: 0010:__queue_work+0xab/0xf00
[ 25.981629] Call Trace:
[ 26.125727] <TASK>
[ 26.413912] ? pagetable_free_kernel+0x20/0x120
[ 26.990283] queue_work_on+0x97/0xf0
[ 27.134382] __cpa_collapse_large_pages+0x501/0x6f0
[ 27.566662] cpa_flush+0x394/0x620
[ 27.998953] change_page_attr_set_clr+0x321/0x4a0
[ 29.151729] set_memory_rox+0xa2/0xf0
[ 29.584018] create_trampoline+0x431/0x6f0
...
[ 44.343347] Kernel panic - not syncing: Attempted to kill the idle task!
The boot-time tracer is started from early_trace_init(), which runs
before workqueue_init_early(). Making its trampoline read-only splits a
large page, and CPA collapses it again right away. The split table has
been a kernel page table since commit 9e4a3ec3411b
("x86/mm/pat: Allocate split page tables as kernel page tables"), so the
collapse frees it through pagetable_free_kernel(), which queues work on
system_percpu_wq - still NULL at that point. That commit is correct in
itself; it only lets CPA reach pagetable_free_kernel() before the
workqueue that function relies on exists.
Keep putting the table on the list, but don't schedule the work while
the system is still booting. A core_initcall schedules it once to free
whatever was queued by then.11hCVE-2026-112518——
———An issue with signature validation was addressed with improved checks. This issue is fixed in iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. An attacker in a privileged network position may be able to impersonate a Kerberos KDC.5hCVE-2026-65215——
———Rejected reason: The reported issue could not be reproduced. This CVE ID is unused by the CNA.10hCVE-2026-65214——
———Rejected reason: The reported issue is tracked under CVE-2026-18449. This CVE ID is rejected as a duplicate.10hCVE-2026-99095——
———In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: drain the hangcheck timer and works on V3D unbind
Nothing stops the hangcheck timer that submitted jobs arm, or the
job_done_work that the render-done interrupt queues, at teardown:
vc4_irq_disable() cancels only overflow_mem_work, and vc4_gem_destroy()
runs from the drm-managed release, after vc4_v3d_unbind() has already
uninstalled the V3D interrupt and cleared vc4->v3d. A timer still armed
by then reads V3D registers through the NULL vc4->v3d pointer, and the
late callbacks run on the vc4_dev embedding them after it has been
freed.
Drain them in vc4_v3d_unbind(): shut the timer down and cancel
reset_work before the interrupt is taken down, because its
vc4_irq_reset() re-enables it, then flush job_done_work so that
completions queued at teardown still release their jobs.
This issue was found by an in-house static analysis tool.11hCVE-2026-112500——
———A logic issue was addressed with improved restrictions. This issue is fixed in iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, visionOS 27.2. The user's original email address may be leaked when using the Hide My Email feature.5hCVE-2026-112517——
———A use after free issue was addressed with improved memory management. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. An app may be able to cause unexpected system termination or corrupt kernel memory.5hCVE-2026-99096——
———In the Linux kernel, the following vulnerability has been resolved:
io_uring/register: don't exempt disabled rings from task restrictions
A ring created with IORING_SETUP_R_DISABLED is exempt from its register
restrictions until it is enabled. This lets the creator register the
restrictions and then enable the ring with IORING_REGISTER_ENABLE_RINGS,
whether or not that opcode is in the allowed set.
Since commit ed82f35b926b ("io_uring: allow registration of per-task
restrictions"), a ring also inherits restrictions from the task that
creates it, and the same exemption applies to those. A task whose
register opcodes are restricted can therefore create a disabled ring,
issue any register opcode on it, and then enable it.
Mark rings whose restrictions were inherited from the task, and keep
checking register opcodes for them while the ring is disabled. Enabling
such a ring now requires IORING_REGISTER_ENABLE_RINGS to be in the
task's allowed set. Per-ring restrictions registered on a disabled ring
work as before.
[axboe: amend with inheritance flag fixup]11hCVE-2026-99097——
———In the Linux kernel, the following vulnerability has been resolved:
tee: shm: reject zero-sized allocations in tee_dyn_shm_alloc_helper()
tee_dyn_shm_alloc_helper() derives nr_pages from a caller-supplied size
and passes it to alloc_pages_exact() without checking it. For size == 0
nr_pages is 0, and alloc_pages_exact(0) calls get_order(0), which is
documented as undefined and returns BITS_PER_LONG - PAGE_SHIFT. The page
allocator then trips its order > MAX_PAGE_ORDER warning and fails the
allocation; on a panic_on_warn kernel that ends the boot.
This can be triggered by TEE_IOC_SHM_ALLOC with struct
tee_ioctl_shm_alloc_data where size is 0.
Reject a zero page count, as register_shm_helper() already does for the
register path.11hCVE-2026-112516——
———A use-after-free issue was addressed with improved memory management. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. An app may be able to cause unexpected system termination.5hCVE-2026-112515——
———An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. An attacker may be able to cause unexpected system termination or read kernel memory.5hCVE-2026-65212——
———Rejected reason: The reported issue was assessed as intended functionality. This CVE ID is unused by the CNA.10hCVE-2026-65203——
———Rejected reason: The reported issue could not be reproduced. This CVE ID is unused by the CNA.10h