PNG Files with Appended Data: Polyglots, Parser Differences, and Safer Handling

Reviewed October 6, 2026. A file that begins with a PNG signature and has extra bytes after the PNG end marker is not automatically a genuine two-format polyglot. The example discussed here is more precisely a PNG with appended data: an image reader handles the PNG stream, while a separate program must deliberately locate, extract, and interpret the trailing bytes.

Carrier file or true polyglot?

A true polyglot is one byte sequence that independent parsers each accept as a valid instance of a different format. Appending a marker and arbitrary data to a PNG demonstrates a carrier pattern. It becomes executable content only when another process extracts or passes those bytes to an interpreter; the image itself does not run them.

The diagram shows the conceptual layout. It is not a claim that every PNG decoder accepts trailing bytes: implementations may ignore them, report a warning, or reject the file.

Questions readers ask

Does viewing the image execute the appended content?

No. A normal image viewer decodes image data and displays pixels; appending script or binary bytes does not make the viewer execute them. A flaw in an image parser could still create a separate security risk, but that is not the same as automatic execution of the trailing payload.

Does a valid image signature establish safety?

No. A signature is only a small format hint. It does not prove that the complete file is well-formed, that every parser will agree, or that the content is safe to process. Validate the complete structure with a maintained parser and apply resource limits.

Is appended data always malicious?

No. Extra data can be benign or intentional. Its presence alone is not a verdict. Consider the source, expected format, parser behavior, and what downstream software does with the bytes.

Parser limitations and disagreement

PNG parsers walk a sequence of typed chunks with lengths and checksums and stop at the IEND chunk. Parsers differ in how strictly they validate lengths, checksums, ordering, unknown chunks, truncation, and data after IEND. A file can display in a tolerant viewer while a strict validator rejects it. The reverse can also happen when downstream code makes a different parsing decision.

File extension, HTTP content type, and a matching signature are not substitutes for full parsing. Decoding also consumes resources: very large dimensions, decompression expansion, or malformed structures can stress a service even when no code is executed.

Defensive handling

1. Use an allowlist of formats expected for the upload path. Check the actual bytes with a maintained parser; do not trust the extension or request header alone.
2. Decode in a restricted worker with file-size, pixel-count, memory, and time limits. Keep the parser updated.
3. Where policy expects a plain PNG, reject unexpected trailing bytes or decode and re-encode to a fresh PNG. Preserve the original separately if forensic review requires it.
4. Store untrusted originals outside executable paths. Do not automatically extract, launch, or pass trailing bytes to a shell or interpreter.
5. If a separate payload requires investigation, treat it as a new sample: hash it, record provenance, quarantine it, and inspect it in an isolated analysis environment.

When a separate binary investigation is needed

Beryllium DAP’s documented malware-analysis workflow is for supported executable formats such as PE, ELF, and managed .NET binaries. It is not a PNG parser, and this article does not claim that DAP analyzes PNG files. If the investigation concerns a suspicious executable extracted from another source, review DAP’s supported binary-analysis workflow.

Code examples: This revision omits the previous extract-and-execute snippets. They need separate validation before publication; the defensive guidance above does not depend on those snippets.