Vulnerabilities exploitable today
355,887in 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,660
New KEV · 24H0
Exploit Today ≥ 701,604
Distribution · last window
- Critical2,768
- High11,114
- Medium7,337
- Low704
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2025-66150—7.3%
——2——CVE-2025-379497.8 HIG7.3%
——2In the Linux kernel, the following vulnerability has been resolved:
xenbus: Use kref to track req lifetime
Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
<TASK>
__wake_up_common_lock+0x82/0xd0
process_msg+0x18e/0x2f0
xenbus_thread+0x165/0x1c0
process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), a
thin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems
like it was xs_wake_up() in this case.
It seems like req may have woken up the xs_wait_for_reply(), which
kfree()ed the req. When xenbus_thread resumes, it faults on the zero-ed
data.
Linux Device Drivers 2nd edition states:
"Normally, a wake_up call can cause an immediate reschedule to happen,
meaning that other processes might run before wake_up returns."
... which would match the behaviour observed.
Change to keeping two krefs on each request. One for the caller, and
one for xenbus_thread. Each will kref_put() when finished, and the last
will free it.
This use of kref matches the description in
Documentation/core-api/kref.rst7dCVE-2025-137635.7 MED7.3%
——2Multiple uses of uninitialized variables were found in libopensc that may lead to information disclosure or application crash. An attack requires a crafted USB device or smart card that would present the system with specially crafted responses to the APDUs37dCVE-2024-45671—7.3%
——2——CVE-2025-62749—7.3%
——2——CVE-2025-62748—7.3%
——2——CVE-2026-55741—7.3%
——2——CVE-2026-110846.5 MED7.3%
——2Inappropriate implementation in Password Manager in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium)14dCVE-2024-34952—7.3%
——2——CVE-2025-66153—7.3%
——2——CVE-2026-24317—7.3%
——2——CVE-2026-639218.8 HIG7.3%
——2In the Linux kernel, the following vulnerability has been resolved:
ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().
After patch 1/2 in this series, vti6_update() unlinks and relinks
the tunnel through t->net. vti6_siocdevprivate() still uses
dev_net(dev) for the collision lookup. For a tunnel moved through
IFLA_NET_NS_FD, dev_net(dev) is the new netns, not t->net.
SIOCCHGTUNNEL on a migrated tunnel then runs:
net = dev_net(dev) /* migrated netns */
t = vti6_locate(net, &p1, false) /* misses target in t->net */
...
t = netdev_priv(dev)
vti6_update(t, &p1, false) /* mutates t->net's hash */
A caller in the migrated netns picks params that match a tunnel
in the creation netns. The lookup in dev_net(dev) finds nothing.
vti6_update() prepends the migrated tunnel at the head of the
creation netns hash bucket for those params. Later lookups in
the creation netns resolve to the migrated device. xfrm receive
delivers the matched packets through a device the caller controls.
Reachable from an unprivileged user namespace (unshare --user
--map-root-user --net). Cross tenant scope on container hosts.
Switch the SIOCCHGTUNNEL path on a non fallback device to use
t->net for the lookup. The lookup now matches the netns
vti6_update() operates on.
Also add ns_capable(self->net->user_ns, CAP_NET_ADMIN) before
the lookup. The check at the top of the case is against
dev_net(dev)->user_ns, which after migration is the attacker's
netns. A caller there can pick params absent from self->net,
the lookup returns NULL, t becomes self, and vti6_update()
inserts the device into the creation netns hash. The new check
requires CAP_NET_ADMIN in the creation netns user_ns too.
SIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep
dev_net(dev), which equals init_net there.9dCVE-2025-68401—7.3%
——2——CVE-2025-48939—7.3%
——2——CVE-2026-111396.5 MED7.3%
——2Inappropriate implementation in Paint in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium)14dCVE-2023-53359—7.3%
——2——CVE-2025-12652—7.3%
——2——CVE-2026-4453—7.3%
——2——CVE-2026-111346.5 MED7.3%
——2Inappropriate implementation in Media in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium)14dCVE-2026-30980—7.3%
——2——CVE-2026-177203.1 LOW7.3%
——2Insufficient policy enforcement in Passwords in Google Chrome prior to 151.0.7922.72 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)2dCVE-2024-22448—7.3%
——2——CVE-2025-69648—7.3%
——2——CVE-2025-11882—7.3%
——2——CVE-2025-52598—7.3%
——2——CVE-2026-1146—7.3%
——2——CVE-2025-66148—7.3%
——2——CVE-2024-39432—7.3%
——2——CVE-2025-30912—7.3%
——2——CVE-2024-0147—7.3%
——2——CVE-2025-12151—7.3%
——2——CVE-2025-27087—7.3%
——2——CVE-2026-111766.5 MED7.3%
——2Inappropriate implementation in Media in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium)14dCVE-2025-62888—7.3%
——2——CVE-2026-3215—7.3%
——2——CVE-2026-387635.5 MED7.3%
——2An issue in Unistal Systems Pvt. Ltd.Protegent 360 v2.0.0.4 allows a local attacker to cause a denial of service via the function sub_1382812dCVE-2025-62108—7.3%
——2——CVE-2026-7964—7.3%
——2——CVE-2025-62960—7.3%
——2——CVE-2024-13795—7.3%
——2——