Vulnerabilities exploitable today
364,588in 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,675
New KEV · 24H0
Exploit Today ≥ 701,620
Distribution · last window
- Critical2,405
- High10,145
- Medium5,058
- Low466
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2018-25167—13.9%
——4——CVE-2021-47190—13.9%
——4——CVE-2025-10995—13.9%
——4——CVE-2023-42346—13.9%
——4——CVE-2024-274147.8 HIG13.9%
——4In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back
In the commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks
IFLA_BRIDGE_MODE length"), an adjustment was made to the old loop logic
in the function `rtnl_bridge_setlink` to enable the loop to also check
the length of the IFLA_BRIDGE_MODE attribute. However, this adjustment
removed the `break` statement and led to an error logic of the flags
writing back at the end of this function.
if (have_flags)
memcpy(nla_data(attr), &flags, sizeof(flags));
// attr should point to IFLA_BRIDGE_FLAGS NLA !!!
Before the mentioned commit, the `attr` is granted to be IFLA_BRIDGE_FLAGS.
However, this is not necessarily true fow now as the updated loop will let
the attr point to the last NLA, even an invalid NLA which could cause
overflow writes.
This patch introduces a new variable `br_flag` to save the NLA pointer
that points to IFLA_BRIDGE_FLAGS and uses it to resolve the mentioned
error logic.22dCVE-2019-25440—13.9%
——4——CVE-2016-5723—13.9%
——4——CVE-2022-48869—13.9%
——4——CVE-2022-49755—13.9%
——4——CVE-2026-165389.1 CRI13.9%
——4The Wallet for WooCommerce WordPress plugin before 1.6.10 does not verify the amount actually collected for a wallet top-up before crediting the wallet, allowing customers to top up their wallet balance for less than its value.13dCVE-2024-20890—13.9%
——4——CVE-2025-1301—13.9%
——4——CVE-2026-3682—13.9%
——4——CVE-2024-269687.3 HIG13.9%
——4In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gcc-ipq9574: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().
Only compile tested.22dCVE-2026-33265—13.9%
——4——CVE-2013-20005—13.9%
——4——CVE-2023-52682—13.9%
——4——CVE-2024-501827.1 HIG13.9%
——4In the Linux kernel, the following vulnerability has been resolved:
secretmem: disable memfd_secret() if arch cannot set direct map
Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This
is the case for example on some arm64 configurations, where marking 4k
PTEs in the direct map not present can only be done if the direct map is
set up at 4k granularity in the first place (as ARM's break-before-make
semantics do not easily allow breaking apart large/gigantic pages).
More precisely, on arm64 systems with !can_set_direct_map(),
set_direct_map_invalid_noflush() is a no-op, however it returns success
(0) instead of an error. This means that memfd_secret will seemingly
"work" (e.g. syscall succeeds, you can mmap the fd and fault in pages),
but it does not actually achieve its goal of removing its memory from the
direct map.
Note that with this patch, memfd_secret() will start erroring on systems
where can_set_direct_map() returns false (arm64 with
CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and
CONFIG_KFENCE=n), but that still seems better than the current silent
failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most
arm64 systems actually have a working memfd_secret() and aren't be
affected.
From going through the iterations of the original memfd_secret patch
series, it seems that disabling the syscall in these scenarios was the
intended behavior [1] (preferred over having
set_direct_map_invalid_noflush return an error as that would result in
SIGBUSes at page-fault time), however the check for it got dropped between
v16 [2] and v17 [3], when secretmem moved away from CMA allocations.
[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/
[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t
[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/22dCVE-2026-163288.6 HIG13.9%
——4In consul-mcp-server, versions 0.1.0 up to 0.1.3 did not restrict how the Consul backend address was supplied, allowing a connected client to override the server's configured Consul address via a request header. This may allow a malicious client to redirect the server's Consul API traffic to an attacker-controlled endpoint, potentially exfiltrating the Consul token configured on the server. This vulnerability, CVE-2026-16328, is fixed in consul-mcp-server 0.1.4.27dCVE-2026-4511—13.9%
——4——CVE-2026-608324.1 MED13.9%
——4Vulnerability in the Oracle Interaction Blending product of Oracle E-Business Suite (component: Internal Operations). Supported versions that are affected are 12.2.3-12.2.15. Difficult to exploit vulnerability allows high privileged attacker with network access via RMI to compromise Oracle Interaction Blending. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Interaction Blending accessible data as well as unauthorized read access to a subset of Oracle Interaction Blending accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Interaction Blending. CVSS 3.1 Base Score 4.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L).26dCVE-2021-47771—13.9%
——4——CVE-2024-27386—13.9%
——4——CVE-2022-39417—13.9%
——4——CVE-2021-22302—13.9%
——4——CVE-2024-32693—13.9%
——4——CVE-2024-357857.8 HIG13.9%
——4In the Linux kernel, the following vulnerability has been resolved:
tee: optee: Fix kernel panic caused by incorrect error handling
The error path while failing to register devices on the TEE bus has a
bug leading to kernel panic as follows:
[ 15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c
[ 15.406913] Mem abort info:
[ 15.409722] ESR = 0x0000000096000005
[ 15.413490] EC = 0x25: DABT (current EL), IL = 32 bits
[ 15.418814] SET = 0, FnV = 0
[ 15.421878] EA = 0, S1PTW = 0
[ 15.425031] FSC = 0x05: level 1 translation fault
[ 15.429922] Data abort info:
[ 15.432813] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 15.438310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 15.443372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000
[ 15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000
[ 15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration")
lead to the introduction of this bug. So fix it appropriately.22dCVE-2020-23438—13.9%
——4——CVE-2025-64142—13.9%
——4——CVE-2025-32063—13.9%
——4——CVE-2024-498617.8 HIG13.9%
——4In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix helper writes to read-only maps
Lonial found an issue that despite user- and BPF-side frozen BPF map
(like in case of .rodata), it was still possible to write into it from
a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}
as arguments.
In check_func_arg() when the argument is as mentioned, the meta->raw_mode
is never set. Later, check_helper_mem_access(), under the case of
PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the
subsequent call to check_map_access_type() and given the BPF map is
read-only it succeeds.
The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT
when results are written into them as opposed to read out of them. The
latter indicates that it's okay to pass a pointer to uninitialized memory
as the memory is written to anyway.
However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM
just with additional alignment requirement. So it is better to just get
rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the
fixed size memory types. For this, add MEM_ALIGNED to additionally ensure
alignment given these helpers write directly into the args via *<ptr> = val.
The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>).
MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated
argument types, since in !MEM_FIXED_SIZE cases the verifier does not know
the buffer size a priori and therefore cannot blindly write *<ptr> = val.22dCVE-2026-175688.8 HIG13.9%
——4Improper access control in the role membership management endpoint in Devolutions Server allows an authenticated non-administrative user holding the user-group membership management permission to escalate privileges to administrator via a crafted API request.
This issue affects :
* Devolutions Server 2026.2.4.0 through 2026.2.12.0
* Devolutions Server 2026.1.23.0 and earlier23dCVE-2022-30312—13.9%
——4——CVE-2021-1375—13.9%
——4——CVE-2019-25446—13.9%
——4——CVE-2025-64139—13.9%
——4——CVE-2022-48639—13.9%
——4——CVE-2026-42335—13.9%
——4MaxKB is an open-source AI assistant for enterprise. Prior to 2.8.1, MaxKB v2.8.0 and prior are vulnerable to a server-side request forgery (SSRF) bypass in the OSS file service URL fetch (chat/api/oss/get_url) endpoint. The vulnerability exists due to inconsistent URL parsing between the urlparse validation function and the requests HTTP client, allowing attackers to access internal network services. This vulnerability is fixed in 2.8.1.34dCVE-2024-40801—13.9%
——4——CVE-2024-24853—13.9%
——4——