What Is a JPEG Decompression Bomb?

A JPEG decompression bomb—often referred to as a "pixel bomb"—is a malicious or malformed image file designed to crash systems by consuming excessive resources during the decoding process. Although the file itself may be only a few kilobytes in size on disk, it contains instructions that force an image parser to allocate massive amounts of uncompressed data in RAM. When opened or processed by an application, a JPEG bomb can easily exhaust system memory, leading to out-of-memory (OOM) errors, severe performance degradation, or complete denial-of-service (DoS) crashes.

How a JPEG Bomb Works

JPEG compression operates by eliminating redundant visual information and encoding pixel data using discrete cosine transforms (DCT), run-length encoding, and Huffman coding. A standard image viewer reads this compressed stream and reconstructs the full-resolution pixel array in memory to display or manipulate it.

An attacker creates a JPEG bomb by manipulating the file’s header fields—specifically the "Start of Frame" (SOF) marker—to declare absurdly large image dimensions, such as 100,000 by 100,000 pixels. Because the file contains repetitive or blank data, the compressed file size remains minuscule (often under 50 KB). However, the header dictates the allocation requirements for the uncompressed output.

Can It Exhaust System Memory?

Yes, a JPEG bomb directly targets and can rapidly exhaust system memory.

When an image-rendering library decodes an image, it typically allocates a raw bitmap buffer in RAM calculated by the following formula:

\[\text{Memory Required} = \text{Width} \times \text{Height} \times \text{Bytes Per Pixel}\]

For a standard 24-bit RGB image (3 bytes per pixel) defined with dimensions of 100,000 by 100,000 pixels:

\[100{,}000 \times 100{,}000 \times 3 \text{ bytes} \approx 30{,}000{,}000{,}000 \text{ bytes (roughly 30 GB)}\]

If an application does not validate the image dimensions prior to memory allocation, the operating system attempts to allocate this requested memory block all at once. This leads to two primary outcomes:

Immediate Allocation Failure: If the requested allocation exceeds total physical RAM and swap space, the process throws an unhandled out-of-memory exception and crashes immediately.
System-Wide Resource Starvation: If the operating system attempts to satisfy the request using virtual memory and aggressive swapping, disk I/O spikes, causing the entire host system to freeze. On Linux servers, this often triggers the Out-of-Memory (OOM) Killer, which may terminate critical background processes to free resources.

Mitigation Strategies

Preventing JPEG decompression bombs requires defensive programming at the application and infrastructure levels:

Header Inspection: Read only the image metadata to inspect declared width and height dimensions before authorizing memory allocation for full decoding.
Strict Dimension Limits: Enforce maximum allowable resolution thresholds (for example, capping uploads at 4,096 by 4,096 pixels) and reject any file exceeding those boundaries.
Decoder Memory Caps: Use modern decoding libraries that support explicit memory limits, ensuring the parser terminates automatically if an allocation threshold is reached.
Resource Sandboxing: Isolate image processing tasks inside sandboxed containers or worker processes with hard limits on CPU and memory usage to prevent host-level downtime.