Why WAFs Inspect JPEG Markers in File Uploads

Web Application Firewalls (WAFs) inspect JPEG marker segments during file upload workflows to detect and block malicious payloads disguised as legitimate image files. Attackers frequently exploit standard file upload mechanisms by embedding web shells, cross-site scripting (XSS) vectors, or binary exploits within the structural metadata of images. By parsing and analyzing JPEG markers, a WAF verifies structural integrity and ensures that hidden executable code cannot bypass perimeter defenses to compromise backend servers or client browsers.

The Structure of JPEG Marker Segments

A JPEG file is organized into a sequence of segments, each beginning with a two-byte marker starting with the byte 0xFF followed by a specific byte identifying the marker type. Common markers include:

Because the JPEG standard allows arbitrary data to be placed inside specific markers—such as the COM segment and various APPn segments—these fields provide an ideal hiding place for adversaries.

Preventing Polyglot Files and Web Shells

One of the primary reasons WAFs inspect marker segments is to identify "polyglot" files. A polyglot is a file that is simultaneously valid in multiple file formats, such as a valid JPEG that also functions as an executable PHP, ASPX, or JSP script.

An attacker can insert executable code (e.g., <?php system($_GET['cmd']); ?>) inside a JPEG COM marker or EXIF tag. If the hosting server allows user-uploaded files to be stored in an executable directory or processes them through a Local File Inclusion (LFI) vulnerability, the server interprets the embedded script while ignoring the surrounding binary image data. WAF inspection scans these marker payloads for known script signatures and language constructs before the file reaches storage.

Mitigating Parser Exploitation and Buffer Overflows

Web applications routinely rely on image processing libraries (such as LibJPEG, ImageMagick, or GD) to resize, crop, or re-encode user-uploaded photos. These libraries must parse the JPEG marker sequence to extract image dimensions, color profiles, and compression settings.

Attackers deliberately craft malformed marker lengths or corrupt marker sequences to trigger:

WAFs parse marker segment boundaries and lengths independently to ensure the file adheres strictly to RFC specifications, rejecting malformed structures before they reach underlying processing libraries.

Blocking Client-Side Attacks (Stored XSS)

JPEG marker segments are also inspected to protect end users from stored Cross-Site Scripting (XSS). If an application serves user-uploaded JPEGs directly to the browser with incorrect or permissive MIME types (or if Internet Explorer-style MIME-sniffing occurs), embedded HTML or JavaScript inside an APP1 or COM segment can execute in the victim's browser context.

A WAF looks for HTML tags, script delimiters, and JavaScript event handlers inside these marker sections to neutralize potential client-side script execution.

Detecting Trailing Payloads and Steganography

Valid JPEG files terminate with the End of Image marker (0xFFD9). Some attackers append malicious shellcode, secondary payloads, or archives to the end of a valid JPEG, beyond the 0xFFD9 marker. While standard image viewers ignore any data following the EOI marker, backend systems or extracted archives can still read and execute this trailing data. WAFs inspect the file layout to ensure no unauthorized data persists past the terminating marker.