CVE Watch360,756 in full archive

Vulnerabilities exploitable today

360,756in 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,665

New KEV · 24H0

Exploit Today ≥ 701,608

Distribution · last window

Critical
2,494
High
11,027
Medium
7,023
Low
632

Filters

Window

Severity

Flags

Vulnerabilities317,361–317,400 · 360,756

CVECVSSEPSSKEVRExploitTitleMod.

——4——CVE-2026-452077.8 HIG

11.9%

——4An origin validation vulnerability in the Apex One/SEP agent could allow a local attacker to escalate privileges on affected installations. This is similar to CVE-2026-45206 but exists in a different process protection communication mechanism. Please note: an attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.24d CVE-2024-530447.8 HIG

11.9%

——4In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e ("net/sched: Introduce tc block netdev tracking infra"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, "dev" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]13d CVE-2026-20402—

11.9%

——4——CVE-2026-470382.7 LOW

11.9%

——4Vulnerability in the RDBMS component of Oracle Database Server. Supported versions that are affected are 19.3-19.31, 21.3-21.22 and 23.4.0-23.26.2. Easily exploitable vulnerability allows high privileged attacker having None privilege with network access via Oracle Net to compromise RDBMS. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of RDBMS accessible data. CVSS 3.1 Base Score 2.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N).11d CVE-2025-60781—

——4——CVE-2025-603046.1 MED

11.9%

——4code-projects Simple Scheduling System 1.0 is vulnerable to Cross Site Scripting (XSS) via the Subject Description field.43d CVE-2024-21466—

11.9%

——4——CVE-2025-43218—

11.9%

——4——CVE-2026-92234.3 MED

11.9%

——4Missing authorization in the vault import feature in Devolutions Server 2026.1.16.0 and earlier allows a low-privileged authenticated user to create new vaults via a crafted import request.24d CVE-2016-8764—

11.9%

——4——CVE-2024-39485—

11.9%

——4——CVE-2026-140495.3 MED

11.9%

——4Inappropriate implementation in GPU in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Low)46d CVE-2025-63544—

11.9%

——4——CVE-2021-479316.4 MED

11.9%

——4Exponent CMS 2.6 contains a stored cross-site scripting vulnerability that allows authenticated attackers to inject malicious scripts through the Title and Text Block parameters in the text editing endpoint. Attackers can inject iframe payloads with embedded SVG onload events to execute arbitrary JavaScript. The application also exposes database credentials in responses and lacks brute-force protection on authentication endpoints.23d CVE-2026-20406—

——4——CVE-2026-601356.5 MED

11.9%

——4An attacker can modify data that should be restricted to read‑only access.17d CVE-2025-681827.5 HIG

11.9%

——4In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix potential use after free in iwl_mld_remove_link() This code frees "link" by calling kfree_rcu(link, rcu_head) and then it dereferences "link" to get the "link->fw_id". Save the "link->fw_id" first to avoid a potential use after free.18d CVE-2023-7206—

——4——CVE-2026-667515.4 MED

11.9%

——4Let's Chat 0.3.0 through 0.4.8 contains an improper authorization vulnerability that allows any authenticated user to archive any room on the server by sending a DELETE request to the rooms handler without ownership verification. Attackers can enumerate room IDs via the rooms listing endpoint and permanently archive private or password-protected rooms they cannot access, with no application-level recovery path requiring direct database intervention to restore.17d CVE-2026-56402—