The most dangerous payloads are not the loudest. They are the ones shaped so that your scanner reads them as safe while your loader runs them as code. This is the discipline that separates a scanner that demos well from one that survives contact with a real adversary.
Every post so far has described a payload. This one is about the gap between two programs looking at the same file and disagreeing about what it is. That gap is where the cleverest attacks live, and it is the single best test of whether a scanner is real.
The setup is always the same. There is the tool that inspects the file and decides it is safe. There is the loader that opens the file for real and executes whatever is inside. If an attacker can make those two programs disagree, so the scanner sees something benign and the loader sees a payload, then the scan is worthless no matter how good its detectors are. You do not have to defeat the detection. You only have to make sure the detector never looks at the real thing.
The shapes this takes
A few techniques come up again and again.
The first is hiding code in a format that is supposed to be safe. Formats like ONNX, GGUF and safetensors are built so they should never contain executable Python. That reputation is exactly why they make good hiding places. A scanner that assumes "this format is safe by design" and skips it gives an attacker a quiet corner to stash a payload that some other part of a pipeline later picks up. The presence of code-shaped strings inside a format that should have none is itself the anomaly worth catching, and catching it means actually looking rather than trusting the format's reputation.
The second is lying about what the file is. As we covered in the load-time post, loaders do not care about file extensions, but many scanners do. Rename a pickle to something unremarkable and an extension-driven scanner never opcode-checks it while the loader runs it anyway. The defence is not subtle to state, though it is work to do properly: identify the real format from the bytes, the actual headers and magic numbers, and inspect based on what the file is rather than what it claims to be.
The third is corrupting the file just enough. Some archive-based formats carry integrity fields, checksums and the like. A scanner built on a strict library will refuse to read an archive whose checksum does not match and may simply skip it as broken. The loaders, in several real cases, do not check, and load the tampered file regardless. So an attacker deliberately breaks the checksum: the scanner gives up, the loader proceeds, the payload runs. A scanner that wants to survive this has to be able to read the file the way the loader does, forgivingly, and it should treat a file that only a forgiving reader can open as suspicious in its own right, because an honest file is not built to be readable by exactly one of the two programs that will open it.
The fourth is wrapping. A payload buried under a layer of ordinary compression is invisible to anything scanning for opcodes at the surface, because the surface is just compressed bytes. The loader, or a helper library, decompresses and runs it. Meeting this means being willing to unwrap a bounded amount and look underneath, rather than stopping at the first layer.
The fifth is reaching the dangerous thing by an unusual route. Instead of calling a famous dangerous function by its famous name, an attacker reaches an equivalent capability through an obscure internal class buried deep in a standard library, something no blocklist of names will ever fully enumerate. This is why naming names is a losing strategy on its own. You cannot list every dangerous callable, because the list is effectively infinite and the attacker only needs one you forgot.
The lesson that ties them together
These are not five unrelated bugs. They are five faces of one idea: do not fight the detector, starve it. And they explain why we keep returning, across this whole series, to the same two commitments.
Read what the loader reads. If your scanner and the victim's loader can ever be made to disagree about what a file is, the attacker wins without touching your detectors. Identify by content, read as forgivingly as the loader does, unwrap what the loader would unwrap, and treat a read mismatch as a finding rather than a shrug.
Decide by what behaviour means, not by what it is named. Recognise the known-good world and make everything else justify itself, so that a novel gadget reached by an obscure path still has to look like it is doing something dangerous to get through. Enumerating evil is hopeless. Recognising good and being suspicious of the rest scales.
A public set of bypasses against a widely used pickle scanner in 2025, tracked as CVE-2025-10155, CVE-2025-10156 and CVE-2025-10157, were all variations on this theme: make the scanner and the loader disagree. We treat resilience to that whole pattern as a baseline requirement rather than a feature, because a scanner that has not been built with an adversary in mind is not a security tool. It is a formality, and formalities do not survive contact with someone who is actually trying.
