CVE-2026-96643 in Pillowinfo

Summary

by MITRE • 10/21/2026

Pillow is a Python imaging library. From 11.0.0 until 13.0.0, Exif.load() in src/PIL/Image.py repeatedly slices the remaining EXIF data while it begins with the six-byte Exif header. src/PIL/PngImagePlugin.py accepts an uncapped PNG eXIf chunk, so a file filled with repeated headers causes a new shrinking copy on every iteration and quadratic CPU work. The condition is reachable through Image.getexif(), Image._getexif(), and ImageOps.exif_transpose(), including common photo-upload rotation workflows. This issue is fixed in version 13.0.0.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 10/21/2026

The vulnerability identified within the Pillow Python imaging library, specifically affecting versions from 11.0.0 through 13.0.0, represents a significant resource exhaustion risk rooted in inefficient data processing logic during EXIF metadata parsing. The core technical flaw resides in the Exif.load() method located in src/PIL/Image.py and its interaction with PNG image files containing eXIf chunks via PngImagePlugin.py. When processing an image file that contains repeated six-byte Exif headers, the library enters a loop where it repeatedly slices the remaining EXIF data as long as the beginning of the buffer matches this specific header signature. Because the slicing operation creates new copies of the shrinking data segment in each iteration rather than using efficient pointer arithmetic or offset tracking, the computational cost grows quadratically relative to the size of the malicious input. This means that for an attacker providing a file with sufficiently large and repetitive EXIF headers, the CPU usage will escalate dramatically, leading to severe performance degradation or complete system unavailability due to resource exhaustion.

This vulnerability is particularly dangerous because it can be triggered through several common API endpoints within the library, including Image.getexif(), Image._getexif(), and ImageOps.exif_transpose(). These functions are frequently utilized in web applications that handle user-uploaded images, such as social media platforms, content management systems, or any service performing automatic image rotation based on orientation metadata. The eXIf chunk in PNG files is not capped by default in the affected versions, allowing attackers to craft malformed PNG files with excessively large EXIF data sections filled with repeating header patterns. When a victim application processes such an uploaded file using standard photo-upload workflows that involve reading or manipulating EXIF data, it inadvertently triggers this quadratic CPU consumption pattern. The operational impact is primarily a Denial of Service condition, where the server hosting the vulnerable Pillow instance becomes unresponsive to legitimate requests as its processing threads are consumed by the malicious parsing task.

From a classification perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, and more specifically relates to inefficient regular expression or string matching patterns that lead to quadratic time complexity often associated with ReDoS-style attacks, although here it is driven by algorithmic inefficiency in data slicing rather than regex backtracking. In the context of the MITRE ATT&CK framework, this behavior maps to T1496 Resource Hijacking, where an adversary uses compromised resources for their own benefit or causes disruption through resource exhaustion. The attack vector typically involves Remote Code Execution prerequisites being absent; instead, it is a remote denial-of-service scenario that requires no authentication if the image upload functionality is publicly accessible.

Mitigation strategies focus primarily on upgrading to version 13.0.0 of Pillow, where this logic has been corrected to prevent the quadratic behavior during EXIF parsing. For environments unable to immediately upgrade, defensive coding practices should be implemented by validating and limiting the size of incoming eXIf chunks before passing them to the library's parsing functions. Additionally, implementing rate-limiting on image upload endpoints can help mitigate the impact of such attacks by preventing a single source from overwhelming system resources with multiple malicious requests. Security teams should also consider deploying Web Application Firewalls that inspect for anomalous metadata sizes in uploaded files, ensuring that only reasonably sized EXIF data is processed by downstream imaging libraries.

Responsible

GitHub M

Reservation

09/23/2026

Disclosure

10/21/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you know our Splunk app?

Download it now for free!