A file arrives at a Cross Domain Solution (CDS). It's tagged as an image, a JPEG, nothing more. The CDS checks the file type, confirms it matches policy, and lets it through. On the other side of the domain boundary, that same file is opened not as an image, but as an executable. Nothing was misconfigured. The control worked exactly as designed. It just wasn't designed to catch this.

This is a polyglot file, and it's one of the more quietly dangerous techniques in the modern file-borne threat landscape, precisely because it doesn't try to sneak past your security tools. It exploits the fact that they're looking at the wrong question.

A file that's honestly two files

A polyglot is a single binary that simultaneously satisfies the parsing rules of two or more file formats. It's not corrupt, and it's not disguised in the way people usually picture it. There’s no forged header pretending to be something it isn't. A polyglot file is a valid PDF and a valid ZIP archive at the same time. Or a valid JPEG and a valid HTML document. Whether it's treated as one or the other depends entirely on which program touches it.

That ambiguity is the whole point. Most security tools, cross domain solutions included, make allow/deny decisions based on file type. Type-based filtering asks a fast, simple question: does this file match an approved format? A polyglot answers "yes" twice, and the tool only ever checks once.

Why this matters more at the domain boundary than almost anywhere else

Cross domain solutions exist to do one job: enforce policy on what moves between classification levels. They are, by design, the approved pathway, which also makes them the highest-value target. If an adversary can get a file through a CDS by having it read as an approved type on the way in and then executed as something else on the other side, they've turned the most trusted control in the architecture into the delivery mechanism.

This isn't a hypothetical edge case or a theoretical vulnerability class. It's documented in NSA Raise the Bar guidance as a technique specifically designed to exploit type-based security enforcement, which tells you two things: it's real enough that NSA felt the need to name it, and it's common enough across CDS deployments that guidance had to address it directly.

Why detection doesn't fix this

The instinct is to ask security tooling to get better at recognizing polyglots, a smarter classifier, a more thorough file-type check. But that's still playing the same game the polyglot is built to win. As long as the control is asking "what type is this file," a file engineered to have more than one honest answer will keep finding a way through. The fix isn't a better guess at the file's type. It's not needing to guess at all.

Structural verification instead of type-based filtering

This is the core difference between type-based filtering and Content Disarm and Reconstruction (CDR). CDR doesn't ask what a file claims to be. It disassembles the file down to its structural components, validates every element against the published specification for a known format, and rebuilds a clean, conformant version, discarding anything that falls outside that specification. A polyglot structure doesn't pass a permissive type check; it simply doesn't survive reconstruction, because the extraneous format layer isn't part of what a legitimate file of that type is supposed to contain.

This is the core difference between type-based filtering and Content Disarm and Reconstruction (CDR). CDR doesn't ask what a file claims to be. It disassembles the file down to its structural components, validates every element against the published specification for a known format, and rebuilds a clean, conformant version, discarding anything that falls outside that specification. While the file is disassembled, CDR can also apply targeted checks that reach beyond what the specification itself defines, and content management policies let operators tighten those rules further still. A polyglot structure doesn't survive this process, because the extraneous format layer isn't part of what a legitimate file of that type is supposed to contain — and under a hardened policy, there is no form in which it survives at all.

Glasswall's CDR engine, validated under NSA Raise the Bar for cross domain content filtering, applies exactly this approach at the pathways where polyglots do the most damage: coalition file exchange, CDS transfer points, and DevSecOps ingest. The output isn't a probabilistic judgment about whether the file looked safe. It's a rebuilt file that conforms to spec, regardless of what it might have also been.

The bigger picture

Polyglot files are a clean illustration of a pattern that shows up across file-borne threats generally: the attack doesn't fight your access controls; it slips past the question they're built to ask. Type-based filtering asks whether a file is approved. Identity and access controls ask whether the sender is trusted. Neither asks whether the content itself is safe to open. Closing that gap is what completing the Zero Trust data pillar actually requires.

Talk to an expert about closing the polyglot gap in your CDS environment.