The PyPI package 'resion' version 22.0.1 contains malicious code embedded in a dependency named 'pafex'. This dependency loads a disguised pickle file that executes malicious code upon unpickling. The malicious payload establishes persistence on the victim's machine via a PTH file and downloads a secondary payload. The campaign associated with this package involves file exfiltration, obfuscation, remote command execution, and remote access trojan (RAT) behavior. The final remote payload observed was a stub, indicating potential further stages. No patch or fix information is provided.
The PyPI package 'workcalender' version 17.1.0.dev0 is identified as malicious due to its overridden install command in setup.py that executes malicious code during installation. Although no installer-side harm such as network I/O, credential scraping, or persistence mechanisms were observed, the package appears to be a developmental release uploaded with intent to exploit dependency confusion. This package is part of a campaign with clear malicious intent, including backdoor installation.
The PyPI package test-workalendar-internal versions 0.0.1, 0.0.2, and 0.0.3 contains malicious code that executes during installation. It installs a web terminal bound to localhost and exposes it via a Cloudflare tunnel, sending access credentials to an attacker-controlled server. This creates a remote shell backdoor on the installer's machine.
Pillow, a Python imaging library, has a vulnerability in its XBM header parser prior to version 13.0.0. The issue involves a regular-expression denial of service (ReDoS) in the XbmImageFile._open function, where processing a crafted XBM file can cause excessive backtracking and stall the application. This vulnerability allows denial of service by making the image loading operation hang for minutes. The flaw is fixed in Pillow version 13.0.0.
Pillow versions from 12.0.0 up to but not including 13.0.0 contain a vulnerability in the Image.merge() function where a null image8 plane can be dereferenced. This occurs because validation skips the first input band, allowing certain image types to be merged incorrectly, leading to a native process crash. The issue can be triggered by opening a crafted IPTC file or by direct invocation of Image.merge() with a malicious first band. This vulnerability is fixed in version 13.0.0.
Pillow versions prior to 13.0.0 contain a vulnerability where a double free of image memory can occur during certain image transform operations. This happens when ImagingScaleAffine encounters a selective allocation failure in a specific fast path for affine transformations using nearest neighbor resampling. The flaw can cause process crashes and potential memory corruption. The issue is fixed in Pillow version 13.0.0.
Pillow versions prior to 13.0.0 contain a critical vulnerability in the FlashPix JPEG-tile decoder. The decoder can write decoded scanlines beyond the allocated tile buffer due to improper handling of JPEG modes, leading to heap memory corruption. This flaw may allow an attacker to execute arbitrary code by supplying a crafted OLE2 FlashPix file to an application that processes untrusted input with the optional olefile dependency. The issue is fixed in Pillow version 13.0.0.
Pillow versions from 11.3.0 up to but not including 13.0.0 contain a heap use-after-free vulnerability triggered when libtiff rejects a tag during TIFF encoding to an in-memory buffer. This flaw can cause a process crash and may allow code execution. The issue is resolved in Pillow version 13.0.0.
Pillow, a Python imaging library, has a vulnerability in versions prior to 13.0.0 where rank-based filters can dereference invalid image storage when processing a zero-size image. This flaw causes a native process crash due to a fault in the ImagingExpand() function before the rank filter is applied. The issue is resolved in version 13.0.0.
A use of uninitialized resource vulnerability exists in the python-pillow Pillow library versions 5.3.0 through 12.x. Pillow can return uninitialized memory as pixel data when decoding certain JPEG-compressed or Group 4 fax TIFF images. This occurs because the decoding buffers may be larger than the data written by libtiff, and the unwritten buffer tail is not cleared. An attacker can exploit this by supplying a crafted TIFF file to disclose stale heap memory contents. The issue is fixed in Pillow version 13.0.0.
## 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
CVE-2026-112895 is a high-severity vulnerability in the python-pillow Pillow library affecting versions from 5.1.0 up to but not including 13.0.0. It involves uncontrolled recursion in PDF parsing when appending to existing PDFs using Image.save with append=True. The PdfParser's linearize_page_tree function recurses through /Kids references without cycle or depth checks, allowing cyclic or duplicated page trees to cause unbounded recursion. Similarly, read_prev_trailer only guards against exact repeated offsets, permitting long unique chains to recurse deeply. This can lead to excessive CPU and memory consumption or a RecursionError, resulting in denial of service in applications processing user-supplied PDFs. The issue is fixed in Pillow 13.0.0 by adding a visited set and depth limit to the parsers.
Pillow, a Python imaging library, contains a buffer over-read vulnerability in its TIFF tile and RGBA decode paths in versions from 8.1.0 up to but not including 13.0.0. This flaw arises when Pillow and libtiff interpret certain TIFF tags differently, leading Pillow to read beyond the intended row data. Exploiting this can result in exposure of adjacent heap data or a crash. The issue is resolved in version 13.0.0.
A heap-based buffer overflow vulnerability exists in Pillow's JPEG decoder prior to version 13.0.0. The flaw occurs when decoding certain 8-bit lossless SOF3 JPEG images using libjpeg-turbo 3.x, which can ignore requested downscaling geometry, leading to buffer overflow. This can cause heap corruption, application crashes, or potentially allow code execution. The issue is fixed in Pillow version 13.0.0.
A vulnerability in the python-pillow Pillow library allows a crafted PPM or PGM image file to declare a width of 0, which is accepted and leads to an out-of-bounds write in the native morphology operation code. This causes a crash and potential memory corruption when running morphology operations on such images.
Pillow, a Python imaging library, has a vulnerability in versions prior to 13.0.0 where its P;2L and P;4L raw decoders can read beyond the end of an input buffer. This flaw allows disclosure of up to three adjacent heap bytes or can cause a crash. The issue arises because the unpackers read padded bit planes separately, potentially exceeding the buffer size calculated by ImagingRawDecode. This vulnerability is fixed in version 13.0.0.
CVE-2026-112400 is a high-severity vulnerability in the python-pillow Pillow library affecting versions from 9.2.0 up to but not including 13.0.0. It involves uncontrolled resource consumption due to a flaw in GIF frame size handling during decompression bomb checks. An attacker can craft a small GIF that causes Pillow to allocate gigabytes of memory, leading to denial of service by exhausting system memory. The issue arises because the image object retains a rejected oversized frame size after a DecompressionBombError, causing subsequent operations to allocate memory based on this stale size. This flaw does not cause memory corruption but can crash or kill the process due to out-of-memory conditions. The vulnerability was introduced in version 9.2.0 and fixed in version 13.0.0.