The File That Passes Every Check
File security pipelines are built on a rarely challenged assumption: a file has one type. The detector names it and the policy routes it. Every downstream engine then analyzes the file as that type: anti-malware, sandbox, and sanitization.
Polyglot files break the assumption. A single byte stream can be a perfectly valid GIF and a perfectly valid Java archive at once. The same trick works with a JPEG that is also a RAR archive, or a PDF carrying a complete ZIP past its logical end. Each face is standards-compliant on its own, so no individual format parser sees anything wrong.
A polyglot in one picture: the classic GIF+JAR. Two parsers, two entry points, one file, and each face fully valid.
The security consequence is precise: the pipeline scans the file as the type it detected, and the other format rides through untouched. An image that is also a script becomes stored XSS when a web application serves it back. An archive hidden behind an image face carries its payload past content filters. Attack chains built on this idea, from the classic GIF+JAR combination to steganography-assisted exploit delivery, have been public for nearly two decades. Anti-malware engines remain largely blind to them because each face, inspected independently, is benign.
How the Engine Finds a Second Face
Our File Structure Validation engine adds polyglot detection as a pre-processing step that runs on every scanned file, before any format processor. The design rests on three ideas.
- Sweep the whole stream. The scanner checks the entire file against a list of format magic signatures. A second format announcing itself anywhere in the stream is surfaced with its exact offset, even when the file already has a detected type. That includes signatures appended after a PDF's end-of-file marker or tucked behind an image's pixel data.
- Know where a format legitimately ends. Container formats legally hold other files inside. An image inside a ZIP is ordinary content. The detector resolves each container's true end from the container's own structure. A PDF's trailer, a ZIP's central directory, and an OLE (Object Linking and Embedding) compound file's sector allocation each mark that boundary. PDF resolution accounts for incremental updates. Only signatures outside that structure count as a second face. This structural boundary is what separates a real polyglot verdict from a false alarm on every ordinary archive.
- Confirm before accusing. The engine carves each candidate face out of the stream and re-identifies it independently with our File Type engine before reporting it. Candidates that identify as unstructured data are discarded. A verdict means a second format genuinely parses at that offset. Stray magic bytes alone never produce one.
Drawn from a real sample: a PDF embedding a JPG and a PNG, with a ZIP and a TIFF appended behind its logical end. The verdict names the ZIP and TIFF and stays silent about the embedded images.
The result reports every face with its offset. A single .gif upload, for example, is identified as GIF89a at offset 0 and as a ZIP archive deeper in the stream. Policy decides the rest: report the finding, or block the file outright with an explanation listing the hits.
From Detection to Dissection
Detection is only half the answer, because the polyglot's whole trick is that each face is individually harmless-looking. After detection, the engine dissects the file. Every confirmed face is exported as its own object (polyglot_part_1.pdf, polyglot_part_2.zip, and so on) with its format, offset, and size. The engine hands each one back to the MetaDefender Core™ workflow for full processing as what it really is.
We verified this end to end on a live MetaDefender Core™ instance.
The engine split a PDF sample secretly carrying a Word document (a PDF+JAR+DOCX polyglot) into its PDF face and its ZIP face. Because JAR and DOCX are both ZIP containers, one ZIP face satisfies both specifications. The File Type engine then identified that face as a DOCX, and Deep CDR™ Technology sanitized it individually. The hidden face gets the same treatment it was built to evade.
Precision Is the Hard Part
Magic bytes occur naturally in innocent files, so the real engineering investment is in not crying wolf. Camera photos embed EXIF thumbnails that carry their own JPEG signature. Office documents embed images inside their container structure. Media files randomly contain byte runs that look like compression headers. The detection logic excludes bytes that a legitimate structure already accounts for, and this hardening is continuously extended format by format. A detector that flags every camera photo gets switched off, and a switched-off detector protects no one.
Tested Against Real Polyglots
We ran real polyglot samples through a live MetaDefender Core™ deployment with the File Structure Validation engine. Every one was caught, each face pinned to its exact byte offset:
Sample | Faces found (offset) | Outcome |
PDF hiding a Word document (PDF+JAR+DOCX in one file) | PDF @ 0 · ZIP @ 34,016 | Faces extracted; the hidden DOCX sanitized by Deep CDR™ Technology |
GIF hiding an archive and a second image | GIF89a @ 0 · ZIP @ 25,214 · TIFF @ 154,270 | Detected |
Office document hiding a PDF | OLE @ 0 · PDF @ 73,217 | Detected |
JPEG hiding a PDF | Three faces, PDF appended @ 26,830 | Detected |
PoC‖GTFO issue 3, the security-research zine built as a PDF+ZIP polyglot, 26 MB | PDF @ 25 · ZIP @ 12,224,072 | Detected: the second face found 12 MB deep by full scan |
GIF carrying a GZIP stream and a Java archive | GIF89a @ 0 · GZIP @ 427,764 · ZIP @ 937,265 | Blocked |
PDF embedding a JPG and a PNG, with a ZIP and a TIFF appended | PDF @ 0 · ZIP @ 204,849 · TIFF @ 257,395 | Blocked; the embedded images correctly not reported |
The last row is the reject rule at work: the verdict names the appended ZIP and TIFF and ignores the images inside the PDF. The container resolver accounted for them as the PDF's own content. MetaDefender Core™'s result JSON for that file (abridged):
The fsv_output_files list is the dissection described above, live: the three faces carved out and handed back to the workflow as their own objects.
Here are the screenshots of each sample result in MetaDefender Core™:
Coverage and Configuration
Coverage today spans the formats attackers actually combine: PDF, ZIP, OLE compound files, PNG, GIF, JPEG, TIFF, RAR, GZIP, and 7z.
Structural end-of-container resolution applies to the container formats. The feature ships configuration-first: detection, blocking, and full-file scanning are each policy switches, so operators choose between visibility and enforcement per deployment.
The Bottom Line
A file with two valid faces defeats any pipeline that assigns it one type, and single-type detection is what most scanning stacks are built on. Structural polyglot detection closes that gap by finding every face and proving each one parses. Policy can then block the file before any application picks the wrong interpreter.
Detection across the common attack formats is supported today. End-of-container resolution for the remaining archive formats follows on the roadmap.
See how File Structure Validation handles the file formats moving through your environment.
