CVE Watch356,780 in full archive

Vulnerabilities exploitable today

356,780in 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,662

New KEV · 24H0

Exploit Today ≥ 701,605

Distribution · last window

Critical
2,532
High
10,545
Medium
6,712
Low
670

Filters

Window

Severity

Flags

Vulnerabilities323,881–323,920 · 356,780

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-118695.3 MED

9.2%

——3The WP DSGVO Tools (GDPR) WordPress plugin before 3.1.40 does not perform an authorization check on the immediate-processing path of its data subject access request feature, allowing unauthenticated attackers to generate and download the full personal-data export (including name, postal address, phone number, email, and comment content) of any user, customer, or commenter by supplying their email address.32d CVE-2022-50631—

9.2%

——3——CVE-2025-657964.3 MED

9.2%

——3Incorrect access control in usememos memos v0.25.2 allows attackers with low-level privileges to arbitrarily delete reactions made to other users' Memos.36d CVE-2023-6138—

——3——CVE-2026-114536.3 MED

9.1%

——3A vulnerability was found in Tiobon Employee Self-Service System up to 7.2. Affected by this vulnerability is an unknown functionality of the file /Blog/BlogSearch.aspx of the component Login Endpoint. The manipulation of the argument Keyword results in sql injection. The attack can be launched remotely. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.18d CVE-2022-502197.8 HIG

9.1%

——3In the Linux kernel, the following vulnerability has been resolved: bpf: Fix KASAN use-after-free Read in compute_effective_progs Syzbot found a Use After Free bug in compute_effective_progs(). The reproducer creates a number of BPF links, and causes a fault injected alloc to fail, while calling bpf_link_detach on them. Link detach triggers the link to be freed by bpf_link_free(), which calls __cgroup_bpf_detach() and update_effective_progs(). If the memory allocation in this function fails, the function restores the pointer to the bpf_cgroup_link on the cgroup list, but the memory gets freed just after it returns. After this, every subsequent call to update_effective_progs() causes this already deallocated pointer to be dereferenced in prog_list_length(), and triggers KASAN UAF error. To fix this issue don't preserve the pointer to the prog or link in the list, but remove it and replace it with a dummy prog without shrinking the table. The subsequent call to __cgroup_bpf_detach() or __cgroup_bpf_detach() will correct it.6d CVE-2025-13906—

——3——CVE-2025-378147.8 HIG

9.1%

——3In the Linux kernel, the following vulnerability has been resolved: tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT This requirement was overeagerly loosened in commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), but as it turns out, (1) the logic I implemented there was inconsistent (apologies!), (2) TIOCL_SELMOUSEREPORT might actually be a small security risk after all, and (3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse daemon (GPM or Consolation), which runs as CAP_SYS_ADMIN already. In more detail: 1. The previous patch has inconsistent logic: In commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), we checked for sel_mode == TIOCL_SELMOUSEREPORT, but overlooked that the lower four bits of this "mode" parameter were actually used as an additional way to pass an argument. So the patch did actually still require CAP_SYS_ADMIN, if any of the mouse button bits are set, but did not require it if none of the mouse buttons bits are set. This logic is inconsistent and was not intentional. We should have the same policies for using TIOCL_SELMOUSEREPORT independent of the value of the "hidden" mouse button argument. I sent a separate documentation patch to the man page list with more details on TIOCL_SELMOUSEREPORT: https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/ 2. TIOCL_SELMOUSEREPORT is indeed a potential security risk which can let an attacker simulate "keyboard" input to command line applications on the same terminal, like TIOCSTI and some other TIOCLINUX "selection mode" IOCTLs. By enabling mouse reporting on a terminal and then injecting mouse reports through TIOCL_SELMOUSEREPORT, an attacker can simulate mouse movements on the same terminal, similar to the TIOCSTI keystroke injection attacks that were previously possible with TIOCSTI and other TIOCL_SETSEL selection modes. Many programs (including libreadline/bash) are then prone to misinterpret these mouse reports as normal keyboard input because they do not expect input in the X11 mouse protocol form. The attacker does not have complete control over the escape sequence, but they can at least control the values of two consecutive bytes in the binary mouse reporting escape sequence. I went into more detail on that in the discussion at https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/ It is not equally trivial to simulate arbitrary keystrokes as it was with TIOCSTI (commit 83efeeeb3d04 ("tty: Allow TIOCSTI to be disabled")), but the general mechanism is there, and together with the small number of existing legit use cases (see below), it would be better to revert back to requiring CAP_SYS_ADMIN for TIOCL_SELMOUSEREPORT, as it was already the case before commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"). 3. TIOCL_SELMOUSEREPORT is only used by the mouse daemons (GPM or Consolation), and they are the only legit use case: To quote console_codes(4): The mouse tracking facility is intended to return xterm(1)-compatible mouse status reports. Because the console driver has no way to know the device or type of the mouse, these reports are returned in the console input stream only when the virtual terminal driver receives a mouse update ioctl. These ioctls must be generated by a mouse-aware user-mode application such as the gpm(8) daemon. Jared Finder has also confirmed in https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/ that Emacs does not call TIOCL_SELMOUSEREPORT directly, and it would be difficult to find good reasons for doing that, given that it would interfere with the reports that GPM is sending. More information on the interaction between GPM, terminals and th ---truncated---11d CVE-2025-40312—

9.1%

——3——CVE-2023-7196—

9.1%

——3——CVE-2026-415396.1 MED

9.1%

——3A cross-site scripting (XSS) vulnerability has been reported to affect several QNAP operating system versions. The remote attackers can then exploit the vulnerability to bypass security mechanisms or read application data. We have already fixed the vulnerability in the following versions: QTS 5.2.9.3492 build 20260507 and later QuTS hero h5.2.9.3499 build 20260514 and later QuTS hero h5.3.4.3500 build 20260520 and later QuTS hero h6.0.0.3500 build 20260520 and later18d CVE-2025-9365—