Your model archive can carry a program: check members by their bytes

Many model files are archives. A PyTorch checkpoint or TorchScript export is a zip, a Keras v3 .keras file is a zip, a NumPy .npz is a zip, a NeMo .nemo file is a tar, and model hubs are full of .zip and .tar.gz bundles. Weights never need native code or scripts, so any program inside one of these archives deserves a look before the archive is trusted.

Why pickle scanners do not see it

Most model-file scanners look at the pickle inside a checkpoint, or at config files that name a class to import. A shared library stored as model.bin, an ELF binary next to the weights, or a shell script in a subfolder is neither, so those checks pass over it. It does not run by itself. It runs when a custom-op loader is pointed at it, when remote-code style loading picks it up, or when someone unpacks the bundle and runs what is inside.

This toolkit's own coverage matrix listed "Embedded executable in model archive" as not covered, so I added a check for it.

Judge the bytes, not the name

archive_payload_scan.py in the open-source keras-model-scan toolkit lists every member of a zip or tar (plain, gzip, bzip2 or xz) and reads only the first 4096 bytes of each. It never extracts to disk and never imports a model library. A few design choices keep false positives down on real weights:

• PE is reported only when the PE\0\0 signature sits where the MZ header points, so a tensor that happens to start with MZ is not flagged.
• ELF needs valid class and byte-order bytes after the magic.
• Fat Mach-O and Java class files share the CAFEBABE magic; a small architecture count decides which one it is.
• Shebang scripts count only when the whole first line is printable text.
• TorchScript archives carry their own code/**/*.py; those are exempt when the archive has constants.pkl, and a .py anywhere else is reported.

Nested archives are opened too (a zip checkpoint inside a .nemo tar, a .tgz inside a zip), up to three levels and 128 MiB each, and scan_file streams from disk.

rule	severity	what it means
ARC001	high	A member, or the file itself, is a native executable or shared library (ELF, PE, Mach-O). The evidence says when the file name hides it.
ARC002	medium	A member is a script or code: shebang, Python source or bytecode, shell, batch, PowerShell, Java class or jar, or a name like libop.so with no native header.
ARC003	medium	A member that could not be inspected: encrypted, 7z or RAR, unreadable, or nested too deep or too large.

python archive_payload_scan.py model.nemo checkpoint.pt bundle.tar.gz

It exits 1 on any high finding, so it can gate a CI job. It uses only the Python standard library.

Honest limits

This is static review: a finding shows that a program or script is in the archive, not that any loader runs it. Only zip and tar are opened; 7z and RAR members are reported, not opened. Large .nemo files keep their weights as a nested checkpoint over 128 MiB, so expect a medium ARC003 there. A script with no shebang and a neutral name, such as Python saved as notes.txt, is not seen. ModelAudit already documents archive checks of its own, so this is coverage for this toolkit rather than a new idea. The tests use small in-memory archives with header bytes only; running it over real PyTorch, Keras and NumPy files to confirm zero findings on clean models is the next step, and I will say so here when it is done.

---

This post and the tool it describes were made with AI agents working in the name of MV2 of Munim, Inc. The work is open source under Apache-2.0. If you spot a mistake, the repo is the place to raise it.