Export limit exceeded: 15478 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (15478 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-84444 | 2026-09-18 | 7.4 High | ||
| libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.23.2, when WITH_UNCOMPRESSED_CODEC is enabled, heif_context_add_image_tile() accepts an independently constructed tile whose component-plane dimensions do not match the tile geometry established by the prototype image. ImageItem_uncompressed::add_image_tile() passes that tile directly to unc_encoder::encode_tile(), which lacked the check_component_sizes() gate and sizes its output from the configured tile geometry while copying the tile's actual component-plane dimensions. An oversized component plane can therefore make unc_encoder_component_interleave::encode_tile() copy attacker-controlled data beyond the heap output buffer. This issue is fixed in version 1.23.2. | ||||
| CVE-2026-84383 | 2026-09-18 | 9.8 Critical | ||
| libheif is a HEIF and AVIF file format decoder and encoder. From 1.22.0 until 1.23.2, a crafted HEIF, HEIC, or AVIF item graph using nested iden and auxl references can make HeifPixelImage::transfer_channel_from_image_as() append duplicate Alpha planes with different bit depths to m_storage. HeifPixelImage::scale_nearest_neighbor() in libheif/image/pixelimage.cc allocates the destination Alpha plane using the first plane's 8-bit depth, then iterates a later 10-bit or 12-bit Alpha component and writes uint16_t samples into the same 8-bit allocation. The output geometry controls the overflow extent and the encoded sample values control the data written, allowing a remote file processed by heif_decode_image() to cause a heap out-of-bounds write. This issue is fixed in version 1.23.2. | ||||
| CVE-2026-67549 | 2026-09-18 | 7.6 High | ||
| OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.1.16.0, A crafted 1-bit contiguous cmyk tiff is exposed through a native uint1 imagespec, so callers allocate a bit-packed buffer. tiffinput::read_native_scanline_locked() nevertheless invokes tiffinput::bit_convert() with 8-bit output and writes one expanded byte per value into that smaller buffer, resulting in a heap out-of-bounds write and memory corruption. The affected implementation is identified by src/tiff.imageio/tiffinput.cpp, TIFFInput::bit_convert(), TIFFInput::read_native_scanline_locked(), PHOTOMETRIC_SEPARATED, 1-bit CMYK, and native uint1 ImageSpec, which define the relevant source path, functions, state, and trigger. This issue is fixed in 3.1.16.0. | ||||
| CVE-2026-63638 | 2026-09-18 | 8.3 High | ||
| OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1, A crafted cineon image can declare unsupported component bit depth 26. cineoninput::open() maps it to a 32-bit imagespec, but libcineon maps the unsupported depth to an 8-byte value, so cineoninput::read_native_scanline() causes attacker-controlled data to be written beyond the 4-byte-per-pixel caller buffer, resulting in a heap out-of-bounds write and memory corruption. The affected implementation is identified by src/cineon.imageio/cineoninput.cpp, CineonInput::open(), CineonInput::read_native_scanline(), ComponentDataSize(), bit depth 26, and ImageSpec, which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1. | ||||
| CVE-2026-63419 | 2026-09-18 | 7.8 High | ||
| OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1, A zbuffer-only tiled iff is exposed with a 16-bit public imagespec while the decoder retains a 32-bit internal pixel size. iffinput::read_native_tile() copies according to m_header.pixel_bytes() rather than imagespec::tile_bytes(true), and a failed read can leave m_buf nonempty so a later call copies partially initialized data into the undersized caller buffer, resulting in a heap out-of-bounds write and memory corruption. The affected implementation is identified by src/iff.imageio/iffinput.cpp, IffInput::read_native_tile(), ImageSpec::tile_bytes(true), m_header.pixel_bytes(), ZBUFFER, and m_buf, which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1. | ||||
| CVE-2026-10027 | 1 Ibm | 1 Mq | 2026-09-18 | 8.1 High |
| IBM MQ could allow a remote attacker to cause a denial of service or execute arbitrary code due to a buffer overflow when processing malformed compressed data on channels configured with compression enabled. | ||||
| CVE-2023-4738 | 4 Apple, Debian, Neovim and 1 more | 4 Macos, Debian Linux, Neovim and 1 more | 2026-09-18 | 7.8 High |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1848. | ||||
| CVE-2026-63422 | 2026-09-18 | 7.8 High | ||
| OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1, A valid tiled openexr image whose width is not a multiple of its tile width can trigger an overflow when a caller reads a partial edge-tile rectangle. openexrinput::read_native_tiles() copies each row into the caller buffer using the padded whole-tile scanline_stride rather than user_scanline_bytes for the requested rectangle, resulting in a heap out-of-bounds write and memory corruption. The affected implementation is identified by src/openexr.imageio/exrinput.cpp, OpenEXRInput::read_native_tiles(), partial edge tile, user_scanline_bytes, and scanline_stride, which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1. | ||||
| CVE-2026-59181 | 2026-09-18 | 6.1 Medium | ||
| OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1, A crafted cineon file can supply a numberofelements value greater than the format maximum of eight. cineoninput::open() uses that unchecked value as the loop bound while filling the fixed strings[8] array, writing pointers beyond the stack buffer and into adjacent state, resulting in memory corruption and denial of service. The affected implementation is identified by src/cineon.imageio/cineoninput.cpp, CineonInput::open(), numberOfElements, and strings[8], which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1. | ||||
| CVE-2026-53266 | 1 Linux | 1 Linux Kernel | 2026-09-18 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits(). | ||||
| CVE-2026-44254 | 1 Wazuh | 1 Wazuh | 2026-09-18 | 5.3 Medium |
| Wazuh is a free and open source platform used for threat prevention, detection, and response. From 1.0.0 until 4.14.6 and 5.0.0-beta2, HandleSecureMessage() in src/remoted/secure.c passes a pointer inside its stack buffer to ReadSecMSG(), and src/os_crypto/shared/msgs.c decompresses up to OS_MAXSTR bytes at that offset. For an encrypted agent message on TCP port 1514 that expands to 65,536 bytes, os_zlib_uncompress() writes a terminating null byte beyond the end of the destination buffer. The resulting stack out-of-bounds write in the root-level remoted daemon can crash message processing and disrupt agent communications. This issue is fixed in versions 4.14.6 and 5.0.0-beta2. | ||||
| CVE-2026-75992 | 1 Adobe | 3 Illustrator, Illustrator Desktop 2025, Illustrator Desktop 2026 | 2026-09-18 | 7.8 High |
| Illustrator 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-53196 | 1 Linux | 1 Linux Kernel | 2026-09-18 | 6.8 Medium |
| In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ] | ||||
| CVE-2026-93393 | 1 Mongodb | 1 C Driver | 2026-09-18 | 8.1 High |
| A heap-based buffer overflow exists in the TLS transport layer of the MongoDB C Driver when built with the Windows platform TLS backend. A remote endpoint that the client connects to, or an attacker able to impersonate or redirect the client's connection, can cause the driver to write attacker-supplied data outside the bounds of a heap allocation while processing incoming encrypted traffic. No authentication or user interaction is required, because the affected processing occurs before any application-level authentication completes. Successful exploitation may lead to memory corruption in the client process, disclosure of adjacent heap memory, or termination of the process. | ||||
| CVE-2026-58701 | 1 Google | 1 Android | 2026-09-18 | 7 High |
| In trusty_dputc of generic-arm64-smcall.c, there is a possible out-of-bounds write due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-58773 | 1 Google | 1 Android | 2026-09-18 | 6.7 Medium |
| In link_load_gnss_image of link_device.c, there is a possible out-of-bounds write due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-58734 | 1 Google | 1 Android | 2026-09-18 | 7 High |
| In google_mba_recv_msg of google_mba_poll.c, there is a possible out-of-bounds write due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-54626 | 1 Happyseafox | 1 Sail | 2026-09-18 | 9.8 Critical |
| SAIL is a cross-platform library for loading and saving images with support for animation, metadata, and ICC profiles. In 0.9.10 and earlier, the TGA_INDEXED_RLE path selected by image_type == 9 allocates an image buffer using the one-byte-per-pixel SAIL_PIXEL_FORMAT_BPP8_INDEXED format returned by tga_private_sail_pixel_format() in src/sail-codecs/tga/helpers.c, while sail_codec_load_frame_v8_tga() in src/sail-codecs/tga/tga.c derives a two-to-four-byte pixel_size from an attacker-controlled header bpp value from 9 through 32. Loading a crafted color-mapped run-length-encoded TGA through sail_load_from_file() or sail_load_from_memory() therefore writes attacker-controlled bytes beyond the heap pixel buffer. The pixel-count clamp added for CVE-2026-40494 does not constrain the per-pixel write width, so this issue is an incomplete fix of that vulnerability and can cause heap corruption, a reliable crash, or potential code execution. This issue is fixed in version 1.0.0. | ||||
| CVE-2026-54627 | 1 Happyseafox | 1 Sail | 2026-09-18 | 9.8 Critical |
| SAIL is a cross-platform library for loading and saving images with support for animation, metadata, and ICC profiles. In 0.9.10 and earlier, psd_private_sail_pixel_format() in src/sail-codecs/psd/helpers.c resolves a one-channel PSD in Bitmap color mode to SAIL_PIXEL_FORMAT_BPP1_INDEXED without requiring the file depth to be one, so the pixel buffer uses one-bit rows while sail_codec_load_frame_v8_psd() in src/sail-codecs/psd/psd.c accepts depth == 8 and writes one attacker-controlled byte per pixel. Loading a crafted PSD through sail_load_from_file() or sail_load_from_memory() therefore writes beyond each heap row, causing memory corruption, a reliable crash, or potential code execution. This mode/depth mismatch is distinct from GHSA-rcqx-gc76-r9mv and GHSA-wcj8-hxxf-pq2c. This issue is fixed in version 1.0.0. | ||||
| CVE-2026-54692 | 1 Happyseafox | 1 Sail | 2026-09-18 | 7.8 High |
| SAIL is a cross-platform library for loading and saving images with support for animation, metadata, and ICC profiles. Prior to 1.0.0, sail_codec_load_frame_v8_xbm() in src/sail-codecs/xbm/xbm.c allocates the decoded pixel buffer using the X11 one-byte-per-literal layout, but an X10 static short file causes the flat decode loop to write two file-controlled bytes per literal. When ceil(width/8) produces an odd row stride, the X10 literal count includes a padding byte for every row, but the destination has no space for those bytes, so loading the XBM through sail_load_from_file, sail_load_from_memory, or sail_start_loading_* produces a forward heap overwrite that scales with image height. The X11 static char path is not affected. The overwrite can corrupt process state, cause reliable crashes, and potentially enable code execution in a susceptible consuming application. This issue is fixed in version 1.0.0. | ||||