How JPEG ZIP Polyglot Files Work

A polyglot file is a computer file that is valid according to the specifications of two or more distinct file formats simultaneously. In cybersecurity, attackers frequently craft polyglot files combining the JPEG image format with the ZIP archive format to bypass content inspection systems, smuggle malicious payloads, and evade detection. This article explains the technical mechanics behind JPEG-ZIP polyglots, examining how structural parsing differences between sequential image decoders and reverse-seeking archive extractors allow a single sequence of bytes to function both as an image and an archive.

The Asymmetry of Format Parsers

The creation of a JPEG-ZIP polyglot relies on a fundamental divergence in how each format is read by operating systems and applications.

The JPEG format is read sequentially from the beginning of the file to the end. A JPEG parser begins execution by searching for the Start of Image (SOI) marker (FF D8) at offset zero. It proceeds to parse metadata markers (such as APP0 or COM) and compressed scan data until it reaches the End of Image (EOI) marker (FF D9). Standard image viewers stop parsing once the EOI marker is encountered, ignoring any arbitrary bytes appended after it.

Conversely, the ZIP file format is designed around random access and is parsed backwards from the end of the file. A ZIP utility does not require the file to begin with a specific header at byte zero. Instead, it scans backward from the end of the file to locate the End of Central Directory (EOCD) record, identifiable by the 4-byte signature 50 4B 05 06. The EOCD record contains the byte offset pointing to the Central Directory, which in turn points to individual Local File Headers within the archive. Because the ZIP specification locates its primary index at the end, any data prepended before the archive entries is often ignored or handled as an offset adjustment.

Method 1: Appending (Concatenation)

The most straightforward way attackers craft this polyglot is by appending a valid ZIP archive directly to the end of a valid JPEG file.

  1. Construct the Payloads: The attacker creates a legitimate image (image.jpg) and a separate ZIP archive (payload.zip) containing the malicious payload or secondary files.
  2. Concatenate the Data: The attacker merges the binary data using tools like the command-line utility cat on Unix (cat image.jpg payload.zip > polyglot.jpg) or copy /b on Windows (copy /b image.jpg + payload.zip polyglot.jpg).

When an image rendering engine processes the file, it reads the SOI marker, displays the pixel data, reaches FF D9, and cleanly terminates. When a decompression utility like unzip or 7-Zip processes the same file, it ignores the initial JPEG segment, reads the EOCD signature at the tail, and extracts the archive. Some strict unzipping utilities may require the central directory offsets to be corrected to account for the size of the prepended JPEG, which attackers accomplish using tools like zip -A to adjust internal file pointers.

Method 2: Encapsulation via JPEG Comment Markers

To bypass file upload filters that actively check for trailing bytes after an EOI marker, attackers can hide the ZIP structure within the valid boundaries of the JPEG itself using metadata segments.

  1. Allocating a Marker: JPEGs allow variable-length metadata segments, such as the Comment marker (FF FE) or Application-specific markers (FF E0 through FF EF). These markers declare a 2-byte length field indicating how many subsequent bytes belong to the metadata payload.
  2. Injecting the ZIP: An attacker inserts the FF FE marker immediately after the JPEG header, sets the length field to encapsulate the size of the ZIP archive, and embeds the raw ZIP data within this segment.
  3. Handling Constraints: Because a single JPEG marker segment is limited to a maximum size of 65,535 bytes, larger archives are split across multiple consecutive APPn or COM segments, or the ZIP central directory is carefully arranged so that the entire archive fits within one block.

Under this method, the image decoder reads the metadata, skips over the designated bytes, and renders the scan data. An archive extractor still reads from the end of the file, finds the EOCD record, and extracts the files without relying on trailing data beyond the JPEG's EOI marker.

Exploitation Context

Attackers use these techniques to defeat security mechanisms that enforce weak validation rules. For instance, a web application might validate an uploaded profile picture by inspecting magic bytes at offset zero and verifying that an image parser can render the file. Once uploaded, the file can be triggered by a secondary vulnerability (such as a Local File Inclusion vulnerability, a desktop application executing compressed archives, or an HTML smuggling script) that treats the same file as an archive, effectively bridging the gap between an innocuous image upload and arbitrary code execution.