Here is a one-line change that makes a malicious scikit-learn model invisible to several popular pickle scanners: No change to the payload. The same __reduce__ gadget that a scanner would catch in a raw .pkl sails straight through once it is compressed — and joblib.load still runs it. This is not theoretical: public proofs of concept show a joblib-compressed gadget bypassing picklescan 1.0.4 and ModelScan with zero detections, and it is one of the 22 pickle loading paths catalogued in The Art of Hide and Seek (USENIX Security '26, arXiv:2508.19774). Why it works A pickle scanner reads opcodes. It expects the file to begin with the pickle PROTO opcode (80 04) or a protocol-0 opcode like c (GLOBAL). But joblib.dump(..., compress=...) writes the compressor's magic bytes first: codec leading bytes zlib 78 9c / 78 da gzip 1f 8b bzip2 42 5a 68 (BZh) xz fd 37 7a 58 5a 00 lz4 04 22 4d 18 Point pickletools.genops at 78 9c ... and it fails at offset 0: that is not a valid opcode, so the scanner reports "no issues found". Meanwhile joblib integrates six decompression backends and peels the wrapper transparently before unpickling. The loader sees a pickle; the scanner saw compressor noise. A tool that routes purely on file extension (.joblib → pickle scanner) or on pickle magic has a blind spot exactly the width of a zlib.compress call. The fix is to decompress like the loader does The remedy is simple and symmetric: if the loader transparently decompresses before unpickling, the scanner has to as well. I added joblib_pickle_scan.py to the open-source keras-model-scan toolkit. It sniffs the compressor magic, peels up to four stdlib-decompressible layers (zlib/gzip/bz2/xz) in memory — bounded, bomb-guarded — and then disassembles the inner pickle with pickletools. It never imports joblib, never writes to disk, and never unpickles or executes anything. JLB001 (high, CWE-502): a compression-wrapped stream decompresses to a pickle that imports a code-execution callable. The one opcode-only scanners miss. JLB010 (medium): a compression-wrapped pickle with a real object graph but no dangerous import — still a pickle a magic/extension router skips. JLB012 (medium): an lz4-frame container. lz4 is not in the standard library, so the scanner reports it as unscannable rather than guessing — joblib.load with the lz4 backend would still read it. python joblib_pickle_scan.py model.joblib model.pkl.gz One detail worth calling out: I deliberately do not match the legacy lzma "alone" format on its magic byte, because its first byte 0x5d collides with the pickle EMPTY_LIST opcode (]). Matching it would turn an ordinary list-first pickle into a false positive. The xz format has an unambiguous six-byte signature, so that is the one worth keying on. Honest limits This is static source review, not exploitation. It flags the compression wrapper and the imports inside; it does not prove a given file is exploitable and runs no proof of concept. It peels at most four layers and lz4 frames are reported, not opened. The nuanced top-level-package gadget classification lives in sibling modules in the same repo. The takeaway is small and, I think, underserved: a compressed pickle is still a pickle, and joblib.load treats the wrapper as transparent — so your scanner should too. 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.