Total
15399 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-20644 | 1 Apple | 5 Ipados, Iphone Os, Macos and 2 more | 2026-07-15 | N/A | 6.5 MEDIUM |
| The issue was addressed with improved memory handling. This issue is fixed in Safari 26.3, iOS 18.7.5 and iPadOS 18.7.5, iOS 26.3 and iPadOS 26.3, macOS Tahoe 26.3, visionOS 26.3. Processing maliciously crafted web content may lead to an unexpected process crash. | |||||
| CVE-2026-1837 | 1 Libjxl Project | 1 Libjxl | 2026-07-15 | N/A | 7.5 HIGH |
| A specially-crafted file can cause libjxl's decoder to write pixel data to uninitialized unallocated memory. Soon after that data from another uninitialized unallocated region is copied to pixel data. This can be done by requesting color transformation of grayscale images to another grayscale color space. Buffers allocated for 1-float-per-pixel are used as if they are allocated for 3-float-per-pixel. That happens only if LCMS2 is used as CMS engine. There is another CMS engine available (selected by build flags). | |||||
| CVE-2026-0797 | 1 Gimp | 1 Gimp | 2026-07-15 | N/A | 8.8 HIGH |
| GIMP ICO File Parsing Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GIMP. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of ICO files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-28599. | |||||
| CVE-2025-15059 | 1 Gimp | 1 Gimp | 2026-07-15 | N/A | 7.8 HIGH |
| GIMP PSP File Parsing Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GIMP. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of PSP files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-28232. | |||||
| CVE-2023-43010 | 1 Apple | 4 Ipados, Iphone Os, Macos and 1 more | 2026-07-15 | N/A | 8.8 HIGH |
| The issue was addressed with improved memory handling. This issue is fixed in iOS 17.2 and iPadOS 17.2, macOS Sonoma 14.2, Safari 17.2, iOS 16.7.15 and iPadOS 16.7.15, iOS 15.8.7 and iPadOS 15.8.7. Processing maliciously crafted web content may lead to memory corruption. | |||||
| CVE-2019-25695 | 2026-07-15 | N/A | 8.4 HIGH | ||
| R 3.4.4 contains a local buffer overflow vulnerability that allows attackers to execute arbitrary code by injecting malicious input into the GUI Preferences language field. Attackers can craft a payload with a 292-byte offset and JMP ESP instruction to execute commands like calc.exe when the payload is pasted into the Language for menus and messages field. | |||||
| CVE-2026-5403 | 1 Wireshark | 1 Wireshark | 2026-07-15 | N/A | 7.8 HIGH |
| SBC codec crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service and possible code execution | |||||
| CVE-2026-53004 | 1 Linux | 1 Linux Kernel | 2026-07-14 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks sctp_getsockopt_peer_auth_chunks() checks that the caller's optval buffer is large enough for the peer AUTH chunk list with if (len < num_chunks) return -EINVAL; but then writes num_chunks bytes to p->gauth_chunks, which lives at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8 inside optval. The check is missing the sizeof(struct sctp_authchunks) = 8-byte header. When the caller supplies len == num_chunks (for any num_chunks > 0) the test passes but copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes past the declared buffer. The sibling function sctp_getsockopt_local_auth_chunks() at the next line already has the correct check: if (len < sizeof(struct sctp_authchunks) + num_chunks) return -EINVAL; Align the peer variant with its sibling. Reproducer confirms on v7.0-13-generic: an unprivileged userspace caller that opens a loopback SCTP association with AUTH enabled, queries num_chunks with a short optval, then issues the real getsockopt with len == num_chunks and sentinel bytes painted past the buffer observes those sentinel bytes overwritten with the peer's AUTH chunk type. The bytes written are under the peer's control but land in the caller's own userspace; this is not a kernel memory corruption, but it is a kernel-side contract violation that can silently corrupt adjacent userspace data. | |||||
| CVE-2026-52992 | 1 Linux | 1 Linux Kernel | 2026-07-14 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: fs/adfs: validate nzones in adfs_validate_bblk() Reject ADFS disc records with a zero zone count during boot block validation, before the disc record is used. When nzones is 0, adfs_read_map() passes it to kmalloc_array(0, ...) which returns ZERO_SIZE_PTR, and adfs_map_layout() then writes to dm[-1], causing an out-of-bounds write before the allocated buffer. adfs_validate_dr0() already rejects nzones != 1 for old-format images. Add the equivalent check to adfs_validate_bblk() for new-format images so that a crafted image with nzones == 0 is rejected at probe time. Found by syzkaller. | |||||
| CVE-2026-53041 | 1 Linux | 1 Linux Kernel | 2026-07-14 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix listxattr handling when the buffer is full [BUG] If an OCFS2 inode has both inline and block-based xattrs, listxattr() can return a size larger than the caller's buffer when the inline names consume that buffer exactly. kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102 Call Trace: __check_heap_object+0xe3/0x120 mm/slub.c:8243 check_heap_object mm/usercopy.c:196 [inline] __check_object_size mm/usercopy.c:250 [inline] __check_object_size+0x5c5/0x780 mm/usercopy.c:215 check_object_size include/linux/ucopysize.h:22 [inline] check_copy_size include/linux/ucopysize.h:59 [inline] copy_to_user include/linux/uaccess.h:219 [inline] listxattr+0xb0/0x170 fs/xattr.c:926 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x137/0x320 fs/xattr.c:988 __do_sys_listxattr fs/xattr.c:1001 [inline] __se_sys_listxattr fs/xattr.c:998 [inline] __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998 ... [CAUSE] Commit 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2_xattr_handler().") replaced the old per-handler list accounting with ocfs2_xattr_list_entry(), but it kept using size == 0 to detect probe mode. That assumption stops being true once ocfs2_listxattr() finishes the inline-xattr pass. If the inline names fill the caller buffer exactly, the block-xattr pass runs with a non-NULL buffer and a remaining size of zero. ocfs2_xattr_list_entry() then skips the bounds check, keeps counting block names, and returns a positive size larger than the supplied buffer. [FIX] Detect probe mode by testing whether the destination buffer pointer is NULL instead of whether the remaining size is zero. That restores the pre-refactor behavior and matches the OCFS2 getxattr helpers. Once the remaining buffer reaches zero while more names are left, the block-xattr pass now returns -ERANGE instead of reporting a size larger than the allocated list buffer. | |||||
| CVE-2026-53043 | 1 Linux | 1 Linux Kernel | 2026-07-14 | N/A | 9.1 CRITICAL |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: validate qr_numregions in dlm_match_regions() Patch series "ocfs2/dlm: fix two bugs in dlm_match_regions()". In dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION network message is used to drive loops over the qr_regions buffer without sufficient validation. This series fixes two issues: - Patch 1 adds a bounds check to reject messages where qr_numregions exceeds O2NM_MAX_REGIONS. The o2net layer only validates message byte length; it does not constrain field values, so a crafted message can set qr_numregions up to 255 and trigger out-of-bounds reads past the 1024-byte qr_regions buffer. - Patch 2 fixes an off-by-one in the local-vs-remote comparison loop, which uses '<=' instead of '<', reading one entry past the valid range even when qr_numregions is within bounds. This patch (of 2): The qr_numregions field from a DLM_QUERY_REGION network message is used directly as loop bounds in dlm_match_regions() without checking against O2NM_MAX_REGIONS. Since qr_regions is sized for at most O2NM_MAX_REGIONS (32) entries, a crafted message with qr_numregions > 32 causes out-of-bounds reads past the qr_regions buffer. Add a bounds check for qr_numregions before entering the loops. | |||||
| CVE-2026-55233 | 1 Openresty | 1 Openresty | 2026-07-14 | N/A | 7.5 HIGH |
| OpenResty is a high performance web platform. From 1.29.2.1 to before 1.29.2.5, an out-of-bounds write vulnerability exists in the upstream PROXY protocol v2 implementation. When OpenResty is configured to send PROXY protocol version 2 headers to upstream servers, constructing the header in the stream proxy protocol v2 patch can write beyond the bounds of the allocated buffer, causing the worker process to crash and resulting in a denial of service. Only configurations that explicitly enable PROXY protocol v2 for upstream connections are impacted. This issue is fixed in version 1.29.2.5. | |||||
| CVE-2026-29022 | 1 Mackron | 1 Dr Libs | 2026-07-14 | N/A | 7.3 HIGH |
| dr_libs dr_wav.h version 0.14.4 and earlier (fixed in commit 8a7258c) contain a heap buffer overflow vulnerability in the drwav__read_smpl_to_metadata_obj() function of dr_wav.h that allows memory corruption via crafted WAV files. Attackers can exploit a mismatch between sampleLoopCount validation in pass 1 and unconditional processing in pass 2 to overflow heap allocations with 36 bytes of attacker-controlled data through any drwav_init_*_with_metadata() call on untrusted input. | |||||
| CVE-2026-52962 | 1 Linux | 1 Linux Kernel | 2026-07-14 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ceph: fix a buffer leak in __ceph_setxattr() The old_blob in __ceph_setxattr() can store ci->i_xattrs.prealloc_blob value during the retry. However, it is never called the ceph_buffer_put() for the old_blob object. This patch fixes the issue of the buffer leak. | |||||
| CVE-2026-22211 | 2026-07-14 | N/A | N/A | ||
| TinyOS versions up to and including 2.1.2 contain a global buffer overflow vulnerability in the printfUART formatted output implementation used within the ZigBee / IEEE 802.15.4 networking stack. The implementation formats output into a fixed-size global buffer and concatenates strings for %s format specifiers using strcat() without verifying remaining buffer capacity. When printfUART is invoked with a caller-controlled string longer than the available space, the unbounded sprintf/strcat sequence writes past the end of debugbuf, resulting in global memory corruption. This can cause denial of service, unintended behavior, or information disclosure via corrupted adjacent global state or UART output. | |||||
| CVE-2026-22189 | 1 Cmu | 1 Panda3d | 2026-07-14 | N/A | 9.8 CRITICAL |
| The egg-mkfont utility in Panda3D versions up to and including 1.10.16 contains a stack-based buffer overflow vulnerability due to use of an unbounded sprintf() call with attacker-controlled input. When constructing glyph filenames, egg-mkfont formats a user-supplied glyph pattern (-gp) into a fixed-size stack buffer without length validation. Supplying an excessively long glyph pattern string can overflow the stack buffer, resulting in memory corruption and a deterministic crash. Depending on build configuration and execution environment, the overflow may also be exploitable for arbitrary code execution. | |||||
| CVE-2026-5450 | 1 Gnu | 1 Glibc | 2026-07-14 | N/A | 9.8 CRITICAL |
| Calling the scanf family of functions with a %mc (malloc'd character match) in the GNU C Library version 2.7 to version 2.43 with a format width specifier with an explicit width greater than 1024 could result in a one byte heap buffer overflow. | |||||
| CVE-2026-5435 | 1 Gnu | 1 Glibc | 2026-07-14 | N/A | 7.3 HIGH |
| The deprecated functions ns_printrrf, ns_printrr and fp_nquery in the GNU C Library version 2.2 and newer fail to enforce the caller-supplied buffer length, and can result in an out-of-bounds write when printing TSIG records. | |||||
| CVE-2022-48174 | 2 Busybox, Debian | 2 Busybox, Debian Linux | 2026-07-14 | N/A | 9.8 CRITICAL |
| There is a stack overflow vulnerability in ash.c:6030 in busybox before 1.35. In the environment of Internet of Vehicles, this vulnerability can be executed from command to arbitrary code execution. | |||||
| CVE-2026-33799 | 1 Juniper | 2 Junos, Junos Os Evolved | 2026-07-13 | N/A | 4.3 MEDIUM |
| An Out-of-bounds Write vulnerability in the SNMP daemon (snmpd) of Juniper Networks Junos OS and Junos OS Evolved allows an authenticated network-based attacker sending specific valid SNMPv3 queries to trigger a memory leak. Over time, continuous receipt of these queries will result in snmpd process memory exhaustion, resulting in a process crash and restart, impacting the ability to monitor the system via SNMP. Memory usage can be monitored using the following command: user@device> show system processes extensive | match snmpd This issue affects: Junos OS: * all versions before 21.2R3-S8; * from 21.4 before 21.4R3-S7; * from 22.1 before 22.1R3-S6; * from 22.2 before 22.2R3-S4; * from 22.3 before 22.3R3-S3; * from 22.4 before 22.4R3-S2; * from 23.2 before 23.2R2; * from 23.4 before 23.4R2. Junos OS Evolved: * all versions before 21.2R3-S8-EVO; * from 21.4 before 21.4R3-S7-EVO; * all versions of 22.1-EVO, * from 22.2 before 22.2R3-S4-EVO; * from 22.3 before 22.3R3-S3-EVO; * all versions of 22.4-EVO, * from 23.2 before 23.2R2-EVO; * from 23.4 before 23.4R2-EVO. | |||||