Pillow Decompression Bomb Verdict

Decide whether a Pillow decode path can be made to exhaust memory QUIETLY, before the decode rather than after it. Pure function: no I/O, no image decoding, no dependency on Pillow.

Built for Pillow 12.3.0. Not affiliated with or endorsed by the Pillow project.

THE SILENT FAILURE. Pillow's decompression-bomb guard is a WRITABLE MODULE GLOBAL, and what it does at the boundary is not what its name suggests. Measured:

  ratio to limit   what Pillow actually does
  <= 1.0x          decodes, silent, fine
  1.0x - 2.0x      DECODES, warning only          <- the dangerous band
  >= 2.0x          raises DecompressionBombError

A 10785x10785 PNG -- 116,316,225 pixels against the default limit of 89,478,485 -- emitted DecompressionBombWarning AND RETURNED A FULL IMAGE. The memory was allocated. A warning is a message, not a guard, and code that treats the existence of a limit as protection is wrong in exactly the band an attacker picks.

ONE LINE REMOVES IT AND LEAVES NOTHING BEHIND. Image.MAX_IMAGE_PIXELS = None is the most commonly published fix for that warning. Measured: the identical file then loaded with ZERO warnings -- not suppressed, never emitted. Any imported module can execute that line at import time, before your code runs, and nothing records that it did.

AND YOU CANNOT FIX IT LOCALLY. inspect.signature(Image.open) is (fp, mode='r', formats=None). No limit parameter, no context manager, no per-image option of any kind. The process global is the entire mechanism, so "we set a safe limit in our module" is a claim about the whole process that any dependency can falsify. That fact is reported on EVERY verdict including the safe ones, because a caller who believes they can bound a single decode will write a guard that does not exist and then trust it.

IT REFUSES RATHER THAN ASSUMING. An unread MAX_IMAGE_PIXELS returns REFUSED, never a verdict computed against the default -- "it is probably still 89478485" is precisely the assumption a dependency breaks. The refusal holds EVEN FOR A TINY IMAGE, because declaredPixels comes from the HEADER and a hostile file's header is written by the attacker. Answering SAFE there would be trusting the bomb's own description of itself.

WHAT WAS CHECKED AND FOUND NOT TO BE TRUE, stated because a listing that only lists wins is worth less: the warning is NOT swallowed by Python's default filters. With filters reset to defaults, one DecompressionBombWarning did reach the caller. The realistic failure is a process that suppresses warnings or nulls the global -- not one that is broken out of the box.

SCOPE, STATED PLAINLY: this does not decode images, does not resize anything, and does not replace a process or container resource limit, which is the real remedy for a decode already running. It tells you, before the decode, whether the guard you believe you have is the guard this process actually has.

VERIFIED: 21 tests, measured by running the suite. Both boundaries (1x, and the 2x hard-error multiplier) are pinned from each side. The reproduction script ships in evidence/ and regenerates every number against your own Pillow version.

DELIVERY: free, signed download of a hash-verified tarball, immediately. Full source, no card, no trial, no expiry.

Interface

What you call, and what comes back. Types and signatures only — the implementation ships with the source.

  export function evaluateBombRisk(input: BombCheckInput): BombVerdict;

  export type Severity = "critical" | "warning" | "note";