GHSA-gg2r-wvfm-q9rx: Pip/pillow vulnerability
Summary The MSP RLE decoder expands run-length data into an in-memory buffer with no cap tied to the declared image size. A small file that passes the pixel-count check can force hundreds of megabytes or more of allocation when the application loads pixels.
Details The MSP decoder writes each run into an unbounded io.BytesIO and can expand roughly 85x per run:
- src/PIL/MspImagePlugin.py:144-146
Impact Memory-exhaustion denial of service from a tiny crafted image in any application that loads pixels. The expansion is decoupled from the declared pixel count, so MAXIMAGEPIXELS does not bound it.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/pillowto a version that resolves this vulnerability.Fixed in 13.0.0
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Any application using Pillow that loads pixel data from attacker-controlled or otherwise untrusted MSP image files is exposed to memory-exhaustion denial of service. The issue is triggered when pixels are loaded, not merely by the file's declared pixel count.
Does Pillow's MAX_IMAGE_PIXELS setting mitigate the problem?
No. The RLE expansion is decoupled from the declared pixel count, so MAX_IMAGE_PIXELS does not cap the memory consumed by the decoder.
What does an attacker need to do to exploit this?
An attacker needs to provide a crafted MSP image that passes the pixel-count check but contains run-length data that expands into a very large in-memory buffer. Loading its pixels can then force allocation of hundreds of megabytes or more.