CVE-2026-112202 is an out-of-bounds read vulnerability in the Imager::File::GIF module for Perl versions before 1.006. When the gif_consolidate option is enabled, palette indices are used without bounds checking, leading to reading beyond allocated heap memory. This can cause disclosure of adjacent heap memory and potential process crashes. The default GIF reader is not affected. The vulnerability is fixed in versions 1.006 and 1.040.
IBM QRadar SIEM 7.6.0.0 through 7.6.0.4, and 7.5.0 through 7.5.0 Update Package 16 Interim Fix 001 could allow a remote attacker to cause a denial of service or obtain sensitive information due to an out-of-bounds read.
CVE-2026-100132 is an out-of-bounds read vulnerability in Adobe Acrobat for Edge that could allow an attacker to disclose sensitive memory information. Exploitation requires user interaction, such as visiting a malicious URL or interacting with a compromised webpage. The vulnerability has a medium severity rating with a CVSS score of 4.3.
CVE-2026-94202 is an out-of-bounds read vulnerability in the Eclipse ThreadX real-time operating system's Module Manager. The flaw occurs in the block-pool create dispatcher function, which improperly reads two words from an extra-parameter array without verifying ownership. This leads to reading memory outside the intended bounds during validation and argument list construction. The vulnerability affects versions from 6.0.1 up to and including 6.5.1.202602a. The CVSS 4.0 base score is 4.8, indicating a medium severity issue.
CVE-2026-94024 is an out-of-bounds read vulnerability in the Eclipse Foundation's Eclipse ThreadX module manager. The vulnerability arises because the object lookup functions do not properly bound the memory search length, allowing a module to cause an unbounded memory walk in privileged mode. This can lead to a fault that disables kernel preemption indefinitely, impacting system stability.
CVE-2026-94023 is an out-of-bounds read vulnerability in Eclipse Foundation's Eclipse ThreadX affecting versions 6.0.1 through 6.5.1.202602a. The flaw arises because a ThreadX module can request deletion of kernel objects it does not own by exploiting the Module Manager's dispatch layer, which only checks if the object lies outside the module's code and data. This improper validation allows a module to delete objects created by other modules, violating intended sharing policies.
CVE-2026-95109 is a high-severity out-of-bounds read vulnerability in Eclipse Foundation's Eclipse ThreadX affecting versions 6.1 through 6.5.1.202602a. The flaw arises from improper validation of buffer ranges in the Cortex-A7 MMU Modules port, which only checks the first byte of a caller-supplied buffer for user-readability, ignoring the full buffer size. This allows privileged dispatch code to read or write beyond the intended buffer boundaries, potentially leading to memory corruption or data leakage. The vulnerability is systemic, affecting all protected-module dispatchers relying on this common macro for buffer validation.
CVE-2026-92843 is a high-severity vulnerability in Eclipse Foundation's Eclipse ThreadX - NetX Duo affecting versions up to 6.5.1.202602. It involves a missing bounds check in the TLS 1.3 Certificate-message parser, allowing a malicious TLS 1.3 server to cause an unsigned-integer underflow and a heap out-of-bounds read during the handshake process before certificate verification completes. This flaw is exploitable pre-authentication and can impact any peer processing a remote Certificate message.
CVE-2026-92853 is a high-severity vulnerability in the TLS 1.3 Certificate-message parser of Eclipse Foundation's Eclipse ThreadX - NetX Duo. The parser incorrectly decrements the message length to skip a context byte without verifying that the message contains that byte. This leads to an unsigned integer wraparound when processing a zero-length Certificate message, causing the parser to read beyond the session packet buffer. The flaw can be triggered pre-authentication with a minimal four-byte handshake header and does not require cryptographic validity.
CVE-2026-91057 is an out-of-bounds read vulnerability in Eclipse Foundation's Eclipse ThreadX - GUIX component. The function _gx_multi_line_text_view_display_info_get() reads one byte beyond the end of the application's text buffer when the input string ends with a carriage return character. This causes a secondary out-of-bounds read in _gx_multi_line_text_view_string_total_rows_compute(), potentially resulting in a row of text that does not exist in the source.
The GUIX software JPEG decoder reads four kinds of marker segment without checking that each is long enough to hold what it reads. A truncated segment is therefore read past the end of the caller's image buffer. Separately, a zero chroma sampling factor makes the block decode loop non-terminating. Both reproduce in the default configuration, in which `GX_SOFTWARE_DECODER_SUPPORT` is enabled.
The GUIX JPEG software decoder enforces no ordering on JPEG markers. A file that places a second `SOF0` frame header after `SOS` re-runs the frame header parser after the output buffer has already been allocated and its geometry latched. The decoder returns `GX_SUCCESS` and publishes a `GX_PIXELMAP` whose reported dimensions and `data_size` exceed the allocation behind it.
Any consumer that trusts the returned structure reads out of bounds, including GUIX's own display drivers, reached through the ordinary draw path.
Reproduces in the shipped default configuration; `GX_SOFTWARE_DECODER_SUPPORT` is enabled by default.
`gx_binres_theme_load()` and `gx_binres_font_load()` take the resource as a bare `GX_UBYTE *` with no length, and `GX_BINRES_DATA_INFO` has no field to carry one. Every read is therefore performed at an offset the file itself chose, against a buffer whose extent the loader does not know. A resource that declares more data than it contains is read past its end, and an offset stored in the file is turned into a pointer without being bounded.
This is a distinct defect from GHSA-hgcj-22cg-4hfv, which was an underflowed glyph count. It needs no underflow and no wrapped multiply: a perfectly well-formed, narrow glyph range reaches it.
The PNG chunk reader has no notion of chunk ordering. It records whether an IDAT has been seen and whether a tRNS has already supplied transparency, but nothing prevents an IHDR being read a second time.
A PNG carries exactly one IHDR and it is the first chunk. A file that places a second one after IDAT rewrites the image width, height, bit depth and pixel depth *after* the decoded-data buffer has already been allocated and filled from the original values. The pass that reverses the PNG row filters then derives its own extent from the new dimensions and walks the old allocation, moving image bytes past the end of it.
The buffer is allocated by GUIX rather than supplied by the caller, so the application has no way to size it defensively. The decoder is compiled in by default.
A memory-protected ThreadX module's queue request reaches the Module Manager's dispatch layer, which decides how much of the module's buffer the privileged queue copy may touch and hands that extent to the module port's range check. A queue's `tx_queue_message_size` is a count of `ULONG`s and the copy moves that many words, so the extent is `message_size * sizeof(ULONG)` bytes.
The front-send dispatcher passed the word count itself. `tx_queue_send` and `tx_queue_receive`, either side of it in the same header, have always multiplied.
A source buffer ending `message_size` bytes into memory the module may read was therefore accepted, and `_txe_queue_front_send` then read `message_size * sizeof(ULONG)` bytes from it in privileged mode — `3 * message_size` bytes past the end of what the module is allowed to read. The words are written into the queue's message area, so a module that can receive from that queue reads them back.
A malicious USB MTP/PTP device can cause the USBX host to read past a heap buffer during ordinary object enumeration, leaking adjacent heap contents to the application or faulting on an unmapped page.
A VideoStreaming interface reports the size of its whole class-specific descriptor block in the `wTotalLength` field of its input header. The USBX host recorded that figure and used it as the budget for walking the format, frame and frame-interval descriptors, without holding it against the configuration descriptor actually received.
A device that reports a `wTotalLength` larger than the descriptors it supplies therefore had its own claim believed. Once the real bytes ran out the walk kept going, dereferencing the cursor past the end of the configuration buffer, in the host's context, whenever the application queried format or frame data.
A HID report descriptor is a sequence of items, each declaring in its header how many data bytes follow. The USBX host walks that sequence by advancing over each header and parsing the data behind it.
The walk checked that an item fitted in the descriptor only **after** it had advanced past the header and parsed the payload, and the item analysis it relied on never measured the declared sizes against the bytes actually received. A HID peripheral returning a short report descriptor therefore drove a heap out-of-bounds read during ordinary enumeration.
.
Security Fix(es):
A malformed header in the binary file fed to QBinaryJson::fromBinaryData() can cause undefined behaviour because of out-of-bounds read.(CVE-2026-101201)
## Summary
A small attacker-supplied TIFF can be opened and loaded normally, then reach an out-of-bounds read when an application saves it back to TIFF with retained metadata. The fixed reproducer is a 1×1, 16-bit grayscale, PackBits-compressed TIFF containing tag 320 (ColorMap) with **768 SHORT values**: three zero-filled planes of 256 entries each. No Python object is forged and no metadata is injected after loading.
Pillow's TIFF encoder allocates **768 × 2 = 1536 bytes**, then passes three plane pointers separated by 256 SHORT entries to libtiff. With `BitsPerSample = 16`, libtiff instead expects **65536 SHORT values per plane** and attempts a **131072-byte read** from a plane pointer. Existing ASAN observations identify a heap-buffer-overflow READ crossing the 1536-byte allocation made in `PyImaging_LibTiffEncoderNew`.
The malformed ColorMap need not be a valid palette for this grayscale image. The issue is that accepted metadata is forwarded on save without reconciling the fixed plane extent with the effective sample depth. Opening/loading alone is not the demonstrated fault; the encoder path is required.
## Impact and prerequisites
An application must accept the input, retain the relevant TIFF metadata, and invoke the libtiff-backed TIFF save path. The observed consequence is an out-of-bounds read and ASAN termination. Process-memory exposure during encoding is a potential consequence, **not demonstrated by extracting arbitrary heap contents in this report**. No arbitrary read primitive, full memory-disclosure chain, code execution, address-space bypass, or cross-process effect is claimed.
The 131072-byte attempted copy is not the number of bytes proven disclosed. This report does not run a synthetic-canary serializer or collect an unsanitized encoded output.
## Tested environment and limits of the evidence
The existing observations were recorded on August 30, 2026, with **CPython 3.11.8 on macOS ARM64**, using the unmodified official **Pillow 12.3.0** wheel and its bundled **libtiff 4.7.1**:
- Wheel: `pillow-12.3.0-cp311-cp311-macosx_11_0_arm64.whl`
- Wheel size: `4785266` bytes
- Wheel SHA-256: `37d6d0a00072fd2948eb22bce7e1475f34569d90c87c59f7a2ec59541b77f7a6`
- Pillow source revision: `bb1d8e8ab8d29048624d96e3ee53cecf7c13d13d`
- Bundled libtiff SHA-256: `e8988717b7470394a47d5ccd343130796b24ee70b6d885d3818e0e0b53238be1`
Apple's ASAN runtime was injected at process startup. This is **not an ASAN-rebuilt Pillow wheel**; allocation/memcpy interception detects the reported boundary violation, but the wheel's native instructions are not comprehensively instrumented.
Only this concrete full-package environment is established here. No affected-version range, current development-branch result, or patched release is asserted. Severity is **Unknown**; no CVSS score is proposed.
Separate earlier evidence reached the original Pillow 8.0.1 encoder constructor compiled as a component against a modern Python/libtiff environment. **That was not a complete Pillow 8.0.1 installation** and does not establish the historical package's full runtime behavior. It is not part of this reproducer or an affected-version range.
## Observed evidence and controls
The earlier integration harness performed the natural sequence `Image.open(BytesIO(input))`, `image.load()`, then `image.save(BytesIO(), format="TIFF")`, without replacing the image's metadata. Each case was recorded three times:
| Original fixture | Bytes | Recorded result |
| --- | ---: | --- |
| `colormap16` | 1685 | Loaded as `I;16`; save terminated with ASAN exit 86, READ of size 131072 crossing a 1536-byte heap region (3/3). |
| `colormap8` | 1684 | Same fixed ColorMap, but 8-bit samples; save succeeded and retained SHORT/count 768 (3/3). |
| `colormap_absent` | 137 | Same 16-bit geometry without ColorMap; save succeeded (3/3). |
Address-free summary of the recorded native diagnostic:
```text
AddressSanitizer: heap-buffer-overflow
READ of size 131072
0 bytes after 1536-byte region
Copy path: memcpy -> _TIFFmemcpy -> setByteArray -> _TIFFsetShortArrayExt
-> _TIFFVSetField -> TIFFVSetField -> ImagingLibTiffSetField
-> PyImaging_LibTiffEncoderNew
Allocation: calloc -> PyImaging_LibTiffEncoderNew
```
Input SHA-256 values (also enforced inside the script):
- `colormap16`: `5f38e0ead90b97949fb0c98c63f9c68d00ba9181db6631ecb8927376dcc75f4d`
- `colormap8`: `fdb26d9135549ed44824901985086c5ee4f06515699ca3291e498c523935405c`
- `colormap_absent`: `bd54979624f3ffb713342e0458caff9e17c477f940cda2f0960feebfabbc9556`
## Root cause and source references
- [Pillow `src/encode.c`, lines 870–899, pinned revision](https://github.com/python-pillow/Pillow/blob/bb1d8e8ab8d29048624d96e3ee53cecf7c13d13d/src/encode.c#L870): the ColorMap tuple must contain exactly 768 entries; a 1536-byte allocation is passed with a fixed stride of 256. The check does not reconcile that extent with `BitsPerSample`.
- [Pillow `src/PIL/TiffImagePlugin.py`, lines 1944–19