Total
15356 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-52356 | 4 Apple, Debian, Libtiff and 1 more | 14 Ipados, Iphone Os, Macos and 11 more | 2026-10-28 | N/A | 7.5 HIGH |
| A segment fault (SEGV) flaw was found in libtiff that could be triggered by passing a crafted tiff file to the TIFFReadRGBATileExt() API. This flaw allows a remote attacker to cause a heap-buffer overflow, leading to a denial of service. | |||||
| CVE-2026-113943 | 1 Apple | 1 Macos | 2026-10-28 | N/A | 6.5 MEDIUM |
| An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in macOS Golden Gate 27.2. Mounting a maliciously crafted disk image may cause unexpected system termination or corrupt kernel memory. | |||||
| CVE-2026-98096 | 1 Linux | 1 Linux Kernel | 2026-10-28 | N/A | 7.4 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back. | |||||
| CVE-2026-82962 | 2026-10-28 | N/A | 6.5 MEDIUM | ||
| ethernet_fill_header() in subsys/net/l2/ethernet/ethernet.c can prepend the Ethernet header in place, by pushing it into the headroom of the packet's first fragment, instead of allocating a separate header fragment. Before this fix the in-place path was selected purely from the build-time value of CONFIG_NET_L2_ETHERNET_RESERVE_HEADER, with no check that the packet actually has that headroom, and then called net_buf_push(pkt->buffer, hdr_len). Only Ethernet TX allocations reserve that space: net_pkt_alloc_buffer() invokes the L2 alloc hook (ethernet_l2_alloc()) only when is_pkt_tx() is true and the packet's interface is the Ethernet interface. A packet that was allocated by a different L2 and then handed to Ethernet for transmission therefore has too little (usually zero) headroom. Such packets are produced by ordinary routing and tunnelling paths: net_route_packet_if() re-targets a received packet to another interface when CONFIG_NET_IPV4_FORWARDING / CONFIG_NET_IPV6_FORWARDING are enabled (for example an 802.15.4/OpenThread or PPP interface forwarding to Wi-Fi/Ethernet), net_route_ipv6_mcast_forward_packet() forwards an RX-slab clone that carries no reserve, and the IPIP tunnel interface_send() prepends an outer IP header allocated on the virtual interface. In these configurations a remote or adjacent attacker triggers the condition simply by sending traffic that the device forwards. Because net_buf_simple_push() only asserts on the headroom bound, a build without CONFIG_ASSERT (and without the newer CONFIG_NET_BUF_HARDENING) moves the fragment data pointer below the start of its data block and writes 14 bytes — 18 with VLAN — of Ethernet header out of bounds. With the default fixed-size buffer pools this overwrites the tail of the neighbouring buffer's payload or memory preceding the pool array; with variable-size pools it overwrites the buffer reference count and the heap chunk header. The attacker controls neither the written bytes nor the offset, so the practical impact is memory corruption leading to a crash, packet corruption, or heap inconsistency rather than controlled code execution. The fix takes the in-place path only when net_buf_headroom(pkt->buffer) is large enough and otherwise falls back to a separate header fragment. | |||||
| CVE-2026-82961 | 2026-10-28 | N/A | 7.8 HIGH | ||
| The GPIO syscall handlers in drivers/gpio/gpio_handlers.c did not validate the pin argument supplied by a user-mode caller. z_vrfy_gpio_pin_configure(), z_vrfy_gpio_pin_get_config() and z_vrfy_gpio_pin_interrupt_configure() verified only the device object (K_SYSCALL_DRIVER_GPIO() / K_SYSCALL_OBJ()) and then passed the caller-supplied gpio_pin_t straight through to z_impl_gpio_pin_*() and on to the driver. The only pin check in include/zephyr/drivers/gpio.h was __ASSERT(gpio_port_pin_is_supported(cfg->port_pin_mask, pin), ...), which compiles to nothing unless CONFIG_ASSERT is enabled, so in a production build no check existed at all. GPIO drivers use pin as a shift count and as an array index on the documented assumption that it is a pin the controller supports. On STM32, for example, gpio_stm32_pin_interrupt_configure() turns pin into an EXTI line and stm32_gpio_intc_set_irq_callback() writes data->cb[line_num].cb and data->cb[line_num].data into a NUM_EXTI_LINES-entry array (default 16) in drivers/interrupt_controller/intc_gpio_stm32.c, guarded only by a compiled-out __ASSERT_NO_MSG(); the same function then reads exti_irq_table[line_num] and calls irq_enable() on the result. Other controllers index fixed-size per-pin configuration tables the same way — drivers/gpio/gpio_ite_it8xxx2_v2.c reads an MMIO base pointer out of wuc_base[8] with the caller's pin and performs a read-modify-write through it. The issue is reachable only in builds with CONFIG_USERSPACE=y (the file is compiled under that symbol), by a user-mode thread that has been granted access to a GPIO device object. Such a grant is intended to authorize control of that port's pins; the missing validation instead lets the thread drive a supervisor-mode out-of-bounds write of a function pointer and an associated void * past a kernel .bss array, and out-of-bounds reads that feed irq_enable() and MMIO accesses — an escape from the user-mode sandbox that can lead to kernel memory corruption, arbitrary code execution, or a crash. The fix validates pin against the controller's gpio_driver_config.port_pin_mask with gpio_port_pin_is_supported() in every pin-taking z_vrfy_ handler and returns -EINVAL otherwise, complemented by an unconditional pin >= GPIO_MAX_PINS_PER_PORT range check added to the shared z_impl_gpio_pin_*() inlines. | |||||
| CVE-2026-57189 | 2026-10-28 | N/A | N/A | ||
| Asterisk is an open source private branch exchange and telephony toolkit. In affected deployments, an authenticated attacker may cause a `T.140 RED` out-of-bounds write during `generation accumulation` using carefully crafted packets, potentially allowing remote code execution or causing Asterisk to crash. The `chan_sip` channel driver must be installed and configured, and its `textsupport` option must be enabled; `textsupport` defaults to no. `The chan_sip driver was deprecated in Asterisk 20 and completely removed in all later versions.` Repository comparisons verify patch containment in Asterisk 20.20.1, 21.12.3, 22.10.1 and 23.4.1, and Certified Asterisk 20.7-cert11 and 22.8-cert3. The affected release-track scope remains unresolved: structured metadata includes later release tracks even though the advisory says the required `chan_sip` driver was removed there. | |||||
| CVE-2026-103392 | 2026-10-28 | N/A | 4.8 MEDIUM | ||
| An Out-of-Bounds Write vulnerability in the TCP header processing in Juniper Networks Session Smart Router allows an attacker to corrupt TCP payload data and potentially cause session desynchronization via a transit TCP packet with an oversized SACK option length. | |||||
| CVE-2026-103391 | 2026-10-28 | N/A | 5.3 MEDIUM | ||
| An Out-of-bounds Write vulnerability in the SSR TCP proxy/optimization path in Juniper Networks Session Smart Router allows an attacker to corrupt forwarded packet data and potentially cause a data-plane crash via a transit TCP packet with a crafted TCP option length. | |||||
| CVE-2026-70058 | 1 Microsoft | 7 Windows 10 1607, Windows 10 1809, Windows Server 2012 and 4 more | 2026-10-28 | N/A | 7.5 HIGH |
| Out-of-bounds write in Windows DHCP Server allows an unauthorized attacker to execute code over a network. | |||||
| CVE-2021-48020 | 2026-10-28 | N/A | 6.5 MEDIUM | ||
| Vyper from 0.1.0b4 before 0.3.0 contains a memory corruption vulnerability caused by an incorrect stack tip pointer when internal function calls are performed inside arrays. Contracts placing internal calls in nested array elements, external call arguments, struct literals, or raw_log topics can have memory corrupted, producing incorrect contract behavior. | |||||
| CVE-2026-84496 | 1 Apple | 1 Macos | 2026-10-28 | N/A | 6.5 MEDIUM |
| An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in macOS Golden Gate 27.2, macOS Tahoe 26.7.2. Mounting a maliciously crafted disk image may cause unexpected system termination or corrupt kernel memory. | |||||
| CVE-2026-96521 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2026-10-28 | N/A | 7.8 HIGH |
| Photoshop Desktop is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | |||||
| CVE-2026-118435 | 2026-10-28 | N/A | 5.4 MEDIUM | ||
| Out-of-bounds write vulnerability in Samsung Open Source escargot allows Buffer Manipulation. | |||||
| CVE-2026-118375 | 2026-10-28 | N/A | 8.1 HIGH | ||
| llama.cpp b8841 before b11865 contains an out-of-bounds write vulnerability in the ggml-rpc RDMA transport rdma_recv() function that allows unauthenticated peers to overflow the rpc-server stack. Attackers advertising RDMA capabilities in the HELLO message can send up to 256 KiB into a 1-byte stack variable in rpc_serve_client(), crashing the server or potentially executing code. | |||||
| CVE-2026-90442 | 2026-10-28 | N/A | N/A | ||
| A stack-based buffer overflow vulnerability in the Fireware OS certd process allows an authenticated attacker with access to the Firebox management interface to crash the certificate management service and potentially execute arbitrary code by sending a specially crafted request. | |||||
| CVE-2026-103594 | 2026-10-28 | N/A | N/A | ||
| A stack-based buffer overflow vulnerability in Fireware OS's WireGuard configuration processing allows a remote attacker that has man-in-the-middle TLS-decrypted access between the Firebox and WatchGuard Cloud to create a Denial of Service condition and potentially execute arbitrary code by tampering with a FireCloud Gateway configuration payload. | |||||
| CVE-2026-93866 | 2026-10-28 | N/A | N/A | ||
| An integer overflow vulnerability in the WebSocket connection handling used by WatchGuard Fireware OS's Access Portal allows a remote, unauthenticated attacker to write beyond the bounds of a heap buffer by sending a specially crafted request while the Access Portal feature is enabled. | |||||
| CVE-2026-112709 | 2026-10-28 | N/A | N/A | ||
| A heap-based buffer overflow vulnerability in the Fireware OS authentication service allows an attacker who controls or intercepts traffic to the configured Active Directory server to create a denial of service condition and potentially execute arbitrary code by returning a specially crafted response. | |||||
| CVE-2026-57192 | 2026-10-28 | N/A | N/A | ||
| Asterisk is an open source private branch exchange and telephony toolkit. Prior to Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3, an authenticated attacker may cause a heap buffer overflow through an out-of-bounds write in the `Codec2` decoder caused by a `floor/ceil sample-count mismatch`. The `codec_codec2` module must be loaded and `Codec2` must be configured on the attacked endpoint. The attacker must pass SIP authentication by username/password or `source IP address matching`, establish a call using `Codec2`, and send carefully crafted `Codec2` audio packets. This issue is fixed in Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3. | |||||
| CVE-2026-57197 | 2026-10-28 | N/A | N/A | ||
| Asterisk is an open source private branch exchange and telephony toolkit. Prior to Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3, an unbounded `memcpy` of `OGG/Speex` packet data in `format_ogg_speex` can cause a heap buffer overflow and crash Asterisk when reading a file containing corrupted Speex audio. The attacker must create the file and make it available to Asterisk either through sufficiently elevated privileges or by convincing an Asterisk administrator to make it available. Asterisk must also be configured to play that file. This issue is fixed in Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3. | |||||