Your email gateway scans attachments. Your web proxy blocks known malicious file types. Your employees know not to open .exe files from strangers. Yet attackers can still conceal payloads and stolen data inside files few people suspect: the humble PNG image.
An image is just pixels, right? Wrong. A PNG file is a structured container, and criminals have become very creative about what they put inside it.
One correction first: a PNG does not run itself. Hidden content remains inert until another component extracts or interprets it. Steganography conceals payloads, commands, or stolen data within a larger attack chain; it does not provide execution by itself.
Image files carry traffic in both directions.
Coming in: payloads:
π¨ Hidden in the pixels - Attackers hide code in the least significant bits of a PNG's pixel values. The image still displays normally and is still a valid image. Worok's PNGLoad harvested the low bits of each pixel's red, green, blue, and alpha channels, reassembled them, and ran the result. Note the sequence: the loader was on the machine first.[ref]
πΌοΈ Polyglots - One file may be a valid PNG and a working ZIP or JAR. HTML combinations depend on MIME type, response headers, filenames, and browser behavior. The danger appears when one component validates an image, but another handles it as something else.[ref]
π¦ Metadata, and past the end marker - PNG text chunks can hold inert scripts or C2 URLs. Attackers can also append a payload after IEND, the end of the valid PNG datastream. Many decoders ignore those trailing bytes; others warn or reject the file.[ref]
π Hosted where you already trust - Witchetty hid an XOR-encrypted backdoor inside a Windows-logo bitmap on GitHub, making the download less likely to raise reputation-based alerts.[ref]
Going out: your data:
π€ Steganographic exfiltration - The same trick in reverse. Duqu encrypted gathered information, hid it inside an image and sent it to C2. The insider version needs no malware: embed a customer list in holiday photos and upload them. Controls limited to extension, MIME type, signatures, or known hashes may see only a valid, previously unknown image. DLP capabilities vary significantly, so test your own controls against representative scenarios.[ref]
When the image itself triggers the problem:
π₯ Bugs in image processing - Automatically decoded images can reach vulnerable code without a steganographic loader. CVE-2023-4863 was an exploited-in-the-wild memory-safety flaw in the widely embedded WebP libraryβnot PNG, but a useful example of broader image-decoding risk. Whether it is zero-click depends on how the affected application processes the image. This is what patching is for.[ref]
Two lookalikes worth separating:
π Fake images in the supply chain - In late 2025, 19 malicious VS Code extensions shipped a banner.png that was not an image at all, but an archive of two binaries unpacked by a tampered copy of a trusted npm dependency. No steganography, just a file extension worn as a disguise.[ref]
π§ Image-based phishing - A PNG screenshot of a convincing message with a QR code, sailing past text-based filters. Nothing is hidden inside the file. The file is the lure.
What can we do:
For individuals:
- Patch, and let things restart. Applications may process images even when you do not open them.
- Treat image-only emails pushing you toward a QR code or a link as hostile until proven otherwise.
For organizations:
- Deploy EDR that watches process behaviour, not only signatures. The carrier may look benign; the extracting process does not.
- Treat structural anomalies as signals, not proof. Check for data after IEND, unusual chunks, and disproportionate sizes. Entropy reveals little because PNG data is compressed; attackers can also generate valid CRCs. Correlate them with process activity, network connections, and the file's origin too.
- Where practical, decode and re-encode images, stripping metadata and trailing data. This disrupts many polyglots and appended payloads, but not necessarily pixel-level steganography.
- Combine application allowlisting with script controls, attack-surface-reduction rules and restrictions on user-writable content.
- Review build pipelines for unsigned extensions and bundled dependencies that do not match their public counterparts.
- Ask your DLP vendor directly whether it inspects outbound images at the content level. Most do not.
The most dangerous file isn't always the one that looks dangerous.