Search Results (22523 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-86510 1 D-link 1 Dir-822a 2026-09-08 9.9 Critical
A vulnerability has been found in D-Link DIR-822A A_101. Affected is the function tunnel_set_params of the component L2TP Control Message Parser. Such manipulation leads to out-of-bounds write. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.
CVE-2026-53932 1 Stefanzweifel 1 Laravel-backup-restore 2026-09-08 8 High
laravel-backup-restore restores database backups made with spatie/laravel-backup. Prior to version 1.9.4, a crafted backup archive can trigger OS command injection during database restore. This issue has been patched in version 1.9.4.
CVE-2026-79423 1 Seacms 1 Seacms 2026-09-08 8.8 High
An authenticated remote code execution (RCE) vulnerability in the admin_config.php component of seacms v13.6 allows attackers to execute arbitrary code via a crafted POST request.
CVE-2026-86313 1 Samsung Open Source 1 Walrus 2026-09-08 7.8 High
Out-of-bounds write vulnerability in Samsung Opensource Walrus allows Overflow Buffers. This issue affects Walrus: af80e665ea49d9003695a66502f841ed1d8397e7.
CVE-2026-85050 1 Google 2 Android, Chrome 2026-09-08 9.6 Critical
Out of bounds write in WebGL in Google Chrome on on Android prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)
CVE-2026-19204 1 Eclipse 1 Jetty 2026-09-08 N/A
A client may send a WebSocket frame with an unknown opcode and a very large declared payload length, causing Jetty to attempt a large memory allocation and potentially exhaust the JVM heap. This occurs when auto-fragmentation is enabled, as unknown opcodes bypass the normal maximum frame size handling and payload allocation occurs before the opcode is validated.
CVE-2026-79379 1 Bestechnic 1 Bes2300 2026-09-08 N/A
A buffer overflow in the SBC_DecodeFrames() function of Bestechnic Co., Ltd BES2300 Bluetooth Audio SoC firmware v3.x and earlier and fixed in v.5.0 allows attackers to cause a Denial of Service (DoS) via sending a crafted frame.
CVE-2026-86315 1 Samsung Open Source 1 Escargot 2026-09-08 6.2 Medium
An out-of-bounds write caused by numeric truncation Samsung Open Source Escargot on Linux x86-64 allows an attacker who can supply JavaScript for execution to corrupt native memory and crash the host process via a crafted class definition whose instance initialization entry count exceeds UINT16_MAX. This issue affects Escargot: 5dc93606abd42b859045add05d704a038e197359.
CVE-2026-84256 1 Openvpn 1 Openvpn 2026-09-08 8.8 High
An argument parsing issue in OpenVPN 2.1_rc10 through 2.6.22 and 2.7_alpha1 through 2.7.6 on Windows allows remote authenticated users to execute arbitrary commands via a crafted certificate subject
CVE-2026-81738 1 Openvpn 1 Openvpn 2026-09-08 4.2 Medium
OpenVPN 2.5.0 through 2.7.6 on Windows using the tap-windows6 driver allows attackers to trigger an out-of-bounds write via crafted DOMAIN-SEARCH entries
CVE-2026-16004 1 Asus 1 Armoury Crate 2026-09-08 N/A
Exposed IOCTL with Insufficient Access Control in Armoury Crate driver allows a local user to read and write arbitrary PCI/PCIe configuration space via crafted IOCTL requests by bypassing the driver's verification. Refer to the ' Security Update for Armoury Crate App' section on the ASUS Security Advisory for more information.
CVE-2022-50999 1 Nokogiri 1 Nokogiri 2026-09-08 8.6 High
This CVE ID has been rejected as a duplicate.
CVE-2026-16233 1 Ni 1 Labview 2026-09-08 7.8 High
There is a memory corruption vulnerability recently discovered in NI LabVIEW that may result in information disclosure or arbitrary code execution.  Successful exploitation requires an attacker to get a user to open a specially crafted VI.  This vulnerability affects NI LabVIEW 2026 Q3 (26.3.0) and prior versions.
CVE-2026-86540 1 Knowns-dev 1 Knowns 2026-09-08 7.8 High
knowns versions before 0.30.0 fail to validate the settings.lsp.languages binary field in project configuration files, allowing attackers to execute arbitrary binaries by crafting a malicious .knowns/config.json file. When a repository with a crafted configuration is opened, the unvalidated binary path is executed twice under the user's account without any verification.
CVE-2026-64381 1 Linux 1 Linux Kernel 2026-09-08 7.8 High
In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix next buffer leak in receive_encrypted_standard() receive_encrypted_standard() allocates next_buffer before checking whether the number of compound PDUs already reached MAX_COMPOUND. If the limit check fails, the function returns immediately and the newly allocated next_buffer is not assigned to server->smallbuf/server->bigbuf, making it leaked. Move the MAX_COMPOUND check before allocating next_buffer.
CVE-2026-75809 1 Asus 1 Armoury Crate 2026-09-08 N/A
Exposed IOCTL with insufficient access control in ASUS Armoury Crate allows a local user to disclosure information and disabling device functionality by bypassing driver authentication and using IOCTLs to read from and write to PCIe configuration space.Refer to the ' Security Update for Armoury Crate App ' section on the ASUS Security Advisory for more information.
CVE-2026-71376 1 Hitachi 1 Cosminexus Component Container 2026-09-08 9.8 Critical
OS command injection vulnerability in Cosminexus Component Container. This issue affects Cosminexus Component Container: from 11-70-01 before 11-70-03, from 11-60 before 11-60-03, from 11-50 through 11-50-03, from 11-40 through 11-40-03, from 11-30 through 11-30-08, from 11-20 before 11-20-10, from 11-10 through 11-10-11, from 11-00 before 11-00-13, from 09-87 before 09-87-10, from 09-80 before 09-80-05, from 09-70 before 09-70-28, from 09-50 through 09-50-22, and from 09-00 through 09-00-18.
CVE-2026-64552 1 Linux 1 Linux Kernel 2026-09-08 8.4 High
In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix len check in receive_big() receive_big() bounds the device-announced length by (big_packets_num_skbfrags + 1) * PAGE_SIZE. That is still too loose: add_recvbuf_big() sets sg[1] to start at offset sizeof(struct padded_vnet_hdr) into the first page, so the chain actually carries hdr_len + (PAGE_SIZE - sizeof(padded_vnet_hdr)) + big_packets_num_skbfrags * PAGE_SIZE bytes -- 20 bytes less than the check allows for the common hdr_len == 12 case. A malicious virtio backend can announce a len in that gap. page_to_skb() then walks one frag past the page chain, storing a NULL page->private into skb_shinfo()->frags[MAX_SKB_FRAGS], which is both an out-of-bounds write past the static frag array and a NULL frag handed up the rx path. Bound len by the size add_recvbuf_big() actually advertised.
CVE-2026-46173 1 Linux 1 Linux Kernel 2026-09-08 7.8 High
In the Linux kernel, the following vulnerability has been resolved: exit: prevent preemption of oopsing TASK_DEAD task When an already-exiting task oopses, make_task_dead() currently calls do_task_dead() with preemption enabled. That is forbidden: do_task_dead() calls __schedule(), which has a comment saying "WARNING: must be called with preemption disabled!". If an oopsing task is preempted in do_task_dead(), between becoming TASK_DEAD and entering the scheduler explicitly, bad things happen: finish_task_switch() assumes that once the scheduler has switched away from a TASK_DEAD task, the task can never run again and its stack is no longer needed; but that assumption apparently doesn't hold if the dead task was preempted (the SM_PREEMPT case). This means that the scheduler ends up repeatedly dropping references on the dead task's stack, which can lead to use-after-free or double-free of the entire task stack; in other words, two tasks can end up running on the same stack, resulting in various kinds of memory corruption. (This does not just affect "recursively oopsing" tasks; it is enough to oops once during task exit, for example in a file_operations::release handler)
CVE-2026-43501 1 Linux 1 Linux Kernel 2026-09-08 9.8 Critical
In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: skb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.