CVE Watch366,836 in full archive

Vulnerabilities exploitable today

366,836in 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,685

New KEV · 24H0

Exploit Today ≥ 701,629

Distribution · last window

Critical
2,360
High
9,604
Medium
5,458
Low
531

Filters

Window

Severity

Flags

Vulnerabilities309,041–309,080 · 366,836

CVECVSSEPSSKEVRExploitTitleMod.

——5——CVE-2026-139024.3 MED

15.5%

——5Inappropriate implementation in Chrome for iOS in Google Chrome on iOS prior to 150.0.7871.47 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)53d CVE-2026-140724.3 MED

15.5%

——5Inappropriate implementation in SplitView in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)58d CVE-2026-141264.3 MED

15.5%

——5Incorrect security UI in UI in Google Chrome on Android prior to 150.0.7871.47 allowed a remote attacker to perform domain spoofing via a crafted HTML page. (Chromium security severity: Low)54d CVE-2025-47507—

——5——CVE-2026-139874.3 MED

15.5%

——5Incorrect security UI in Mobile in Google Chrome on Android prior to 150.0.7871.47 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)54d CVE-2025-66514—

15.5%

——5——CVE-2021-47393—

15.4%

——5——CVE-2023-541497.5 HIG

15.4%

——5In the Linux kernel, the following vulnerability has been resolved: net: dsa: avoid suspicious RCU usage for synced VLAN-aware MAC addresses When using the felix driver (the only one which supports UC filtering and MC filtering) as a DSA master for a random other DSA switch, one can see the following stack trace when the downstream switch ports join a VLAN-aware bridge: ============================= WARNING: suspicious RCU usage ----------------------------- net/8021q/vlan_core.c:238 suspicious rcu_dereference_protected() usage! stack backtrace: Workqueue: dsa_ordered dsa_slave_switchdev_event_work Call trace: lockdep_rcu_suspicious+0x170/0x210 vlan_for_each+0x8c/0x188 dsa_slave_sync_uc+0x128/0x178 __hw_addr_sync_dev+0x138/0x158 dsa_slave_set_rx_mode+0x58/0x70 __dev_set_rx_mode+0x88/0xa8 dev_uc_add+0x74/0xa0 dsa_port_bridge_host_fdb_add+0xec/0x180 dsa_slave_switchdev_event_work+0x7c/0x1c8 process_one_work+0x290/0x568 What it's saying is that vlan_for_each() expects rtnl_lock() context and it's not getting it, when it's called from the DSA master's ndo_set_rx_mode(). The caller of that - dsa_slave_set_rx_mode() - is the slave DSA interface's dsa_port_bridge_host_fdb_add() which comes from the deferred dsa_slave_switchdev_event_work(). We went to great lengths to avoid the rtnl_lock() context in that call path in commit 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work"), and calling rtnl_lock() is simply not an option due to the possibility of deadlocking when calling dsa_flush_workqueue() from the call paths that do hold rtnl_lock() - basically all of them. So, when the DSA master calls vlan_for_each() from its ndo_set_rx_mode(), the state of the 8021q driver on this device is really not protected from concurrent access by anything. Looking at net/8021q/, I don't think that vlan_info->vid_list was particularly designed with RCU traversal in mind, so introducing an RCU read-side form of vlan_for_each() - vlan_for_each_rcu() - won't be so easy, and it also wouldn't be exactly what we need anyway. In general I believe that the solution isn't in net/8021q/ anyway; vlan_for_each() is not cut out for this task. DSA doesn't need rtnl_lock() to be held per se - since it's not a netdev state change that we're blocking, but rather, just concurrent additions/removals to a VLAN list. We don't even need sleepable context - the callback of vlan_for_each() just schedules deferred work. The proposed escape is to remove the dependency on vlan_for_each() and to open-code a non-sleepable, rtnl-free alternative to that, based on copies of the VLAN list modified from .ndo_vlan_rx_add_vid() and .ndo_vlan_rx_kill_vid().25d CVE-2025-8295—

——5——CVE-2024-386597.3 HIG

15.4%

——5In the Linux kernel, the following vulnerability has been resolved: enic: Validate length of nl attributes in enic_set_vf_port enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE is of length PORT_PROFILE_MAX and that the nl attributes IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX. These attributes are validated (in the function do_setlink in rtnetlink.c) using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation using the policy is for the max size of the attributes and not on exact size so the length of these attributes might be less than the sizes that enic_set_vf_port expects. This might cause an out of bands read access in the memcpys of the data of these attributes in enic_set_vf_port.25d CVE-2022-49686—

15.4%

——5——CVE-2025-10246—

15.4%

——5——CVE-2026-489536.1 MED

15.4%

——5Lack of escaping leads to an XSS vulnerability in the generic image output layout.51d CVE-2025-15451—

——5——CVE-2026-489506.1 MED

15.4%

——5Lack of escaping leads to an XSS vulnerability in the file management view of com_templates.51d CVE-2024-235733.7 LOW

15.4%

——5HCL Aftermarket EPC is vulnerable to attack since the Application is vulnerable to Lucky 13. that makes the SS LLUCKY13 possible affects the TLS1.1and 1.2 and DTLS1.0 or 1.2 implementations . It also affects previous versions such as SSL3.0 and TLS1.0. This can also be considered a type of man-in-the-middle attack.43d CVE-2019-19355—