Vulnerabilities (CVE)

Total 395814 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2026-69616 1 Microsoft 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more 2026-09-15 N/A 5.5 MEDIUM
Out-of-bounds read in Windows Remote Desktop Services allows an authorized attacker to disclose information locally.
CVE-2026-69627 1 Microsoft 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more 2026-09-15 N/A 5.5 MEDIUM
Out-of-bounds read in Windows Remote Desktop Licensing Service allows an authorized attacker to disclose information locally.
CVE-2026-69638 1 Microsoft 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more 2026-09-15 N/A 8.4 HIGH
Heap-based buffer overflow in Windows NTFS allows an unauthorized attacker to execute code locally.
CVE-2026-69669 1 Microsoft 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more 2026-09-15 N/A 8.8 HIGH
Heap-based buffer overflow in Windows Kernel allows an unauthorized attacker to execute code over a network.
CVE-2026-69709 1 Microsoft 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more 2026-09-15 N/A 7.8 HIGH
Heap-based buffer overflow in Windows NTFS allows an authorized attacker to execute code locally.
CVE-2026-69723 1 Microsoft 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more 2026-09-15 N/A 5.7 MEDIUM
Exposure of sensitive system information to an unauthorized control sphere in Windows Kernel allows an authorized attacker to disclose information over a network.
CVE-2026-69846 1 Microsoft 12 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 9 more 2026-09-15 N/A 8.2 HIGH
Integer overflow or wraparound in Windows Secure Kernel Mode allows an authorized attacker to elevate privileges locally.
CVE-2026-69875 1 Microsoft 10 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 7 more 2026-09-15 N/A 8.0 HIGH
Heap-based buffer overflow in Windows NTFS allows an authorized attacker to elevate privileges over a network.
CVE-2026-69906 1 Microsoft 12 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 9 more 2026-09-15 N/A 8.2 HIGH
Heap-based buffer overflow in Windows Secure Kernel Mode allows an authorized attacker to elevate privileges locally.
CVE-2026-73476 1 External Authentication Project 1 External Authentication 2026-09-15 N/A 5.4 MEDIUM
Improper Handling of Case Sensitivity vulnerability in Drupal External Authentication allows Privilege Escalation. This issue affects External Authentication versions: from 0.0.0 to 2.0.13.
CVE-2026-9796 1 Redhat 1 Build Of Keycloak 2026-09-15 N/A 6.5 MEDIUM
A flaw was found in Keycloak. An authenticated administrator with the `manage-clients` role can exploit a Time-of-check to time-of-use (TOCTOU) vulnerability in the name-based admin role checks. This allows the attacker to escalate their privileges to `realm-admin` for all users within the realm, granting them extensive control over the system. The composite role relationship persists even after the attacker's own permissions are revoked and across system reboots.
CVE-2026-91997 2026-09-15 N/A 5.3 MEDIUM
evolution-api through 2.3.7 contains an incorrect array comparison in the metricsIPWhitelist middleware that always evaluates to false, allowing unauthenticated access to the /metrics endpoint. Attackers can bypass IP whitelist restrictions to access sensitive metrics disclosing server version, database client name, configured server URL, and WhatsApp instance details.
CVE-2026-82918 2026-09-15 N/A 5.5 MEDIUM
XG VisionTerminal and XG-X VisionTerminal provided by Keyence Corporation improperly restrict XML external entity references. If a user opens a specially crafted setting file, the sensitive information stored in the system where XG VisionTerminal or XG-X VisionTerminal is installed may be disclosed.
CVE-2026-72693 2026-09-15 N/A 7.8 HIGH
`openvt -u` is intended to identify the owner of the current VT and then execute `login` as that user from a privileged context. In the documented `kbrequest`/init usage, the ownership test in `authenticate_user()` relies on `stat("/proc/<pid>/fd/0")`. `stat()` on `/proc/<pid>/fd/0` follows the symlink to the underlying TTY device node. As a result, `buf.st_uid` reflects the owner of the TTY node rather than the owner of the process holding the file descriptor. If the TTY owner returns to `root` or the getty owner after logout while an unprivileged process still has `fd 0` attached to that TTY, the check can incorrectly treat that process as belonging to the privileged console owner. Once that check succeeds, the `-u` path executes a passwordless login as the selected user. In the documented `kbrequest`/init deployment using `openvt -us`, this can result in passwordless `login -f root` on the spawned VT. This report establishes that privilege escalation path for that documented deployment; it does not claim equivalent reachability for deployments that do not use `openvt -u` from a privileged `kbrequest`/init path.
CVE-2026-58015 2 Gnome, Redhat 2 Glib, Enterprise Linux 2026-09-15 N/A 5.9 MEDIUM
A flaw was found in GLib. The D-Bus client-side implementation of the DBUS_COOKIE_SHA1 SASL authentication mechanism does not validate the cookie_context parameter received from the server. A malicious D-Bus server can supply a cookie_context containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.
CVE-2026-58014 2 Gnome, Redhat 2 Glib, Enterprise Linux 2026-09-15 N/A 7.3 HIGH
A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.
CVE-2026-52924 1 Linux 1 Linux Kernel 2026-09-15 N/A 9.8 CRITICAL
In the Linux kernel, the following vulnerability has been resolved: sctp: purge outqueue on stale COOKIE-ECHO handling sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart. Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths.
CVE-2026-46116 1 Linux 1 Linux Kernel 2026-09-15 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: if (x->km.seq) hlist_del_rcu(&x->byseq); if (x->id.spi) hlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle
CVE-2026-43329 1 Linux 1 Linux Kernel 2026-09-15 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: strictly check for maximum number of actions The maximum number of flowtable hardware offload actions in IPv6 is: * ethernet mangling (4 payload actions, 2 for each ethernet address) * SNAT (4 payload actions) * DNAT (4 payload actions) * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. * Redirect (1 action) Which makes 17, while the maximum is 16. But act_ct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions. Update flow_action_entry_next() calls to check for the maximum number of supported actions. While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.
CVE-2026-43133 1 Linux 1 Linux Kernel 2026-09-15 N/A 7.9 HIGH
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.