This seems like a doomed approach. You can’t make a list of every “dangerous” function in every library.

is anyone calling it that? to me, "pickle bomb" would imply abusing compression or serialization for a resource-exhaustion attack, a la zipbombs.

"pickle bomb", the way you're using it, doesn't seem like a useful terminology -- pickles are just (potentially malicious) executables.

I thought the ecosystem had mostly moved to .safetensors (which was explicitly created to fix this problem) and .gguf (which I'm pretty sure also doesn't have this problem); do you really need to download giant chunks of untrusted code and execute it at all?

This is outrageous. Why not deprecate this cursed format and use something from the data frame community? Like, Parquet or something

Actually almost any binary format is better than this

One thing we ran into while working on similar problems is that static opcode scanning alone tends to give a false sense of coverage. A lot of real-world bypasses don’t rely on obvious GLOBAL os.system patterns and can evade tools that depend on pickletools, modelscan, or fickling.

We recently open-sourced a structure-aware pickle fuzzer at Cisco that’s designed specifically to test the robustness of pickle scanners, not just scan models:

• It executes pickle bytecode inside a custom VM, tracking opcode execution, stack state, and memo behavior • Mutates opcode sequences, stack interactions, and protocol-specific edge cases • Has already uncovered multiple scanner bypasses that look benign statically but behave differently at runtime

Repo: https://github.com/cisco-ai-defense/pickle-fuzzer

We also wrote up some of the lessons learned while hardening pickle scanners here (including why certain opcode patterns are tricky to reason about statically): https://blogs.cisco.com/ai/hardening-pickle-file-scanners

I think tools like AIsbom are a great step forward, especially for SBOM and ecosystem visibility. From our experience, pairing static analysis + fuzzing-driven adversarial testing is where things get much more resilient over time.

I thought the rule was, never use pickle, it makes no sense when other serialization formats exist and are just as easy to use

Many people prefer human writing. I get it, and I think I understand most of the underlying reasons and emotional drives. [1]

Nevertheless, my top preference (I think?) is clarity and accuracy. For technical writing, if these two qualities are present, I'm rarely bothered by what people may label "AI writing". OTOH, when I see sloppy, poorly reasoned, out-of-date writing, my left hand readies itself for ⌘W. [2]

A suggestion for the comment above, which makes a stylistic complaint: be more specific about what can be improved.

Finally, a claim: over time, valid identification of some text as being AI-generated will require more computation and be less accurate. [3]

[1]: Food for thought: https://theconversation.com/people-say-they-prefer-stories-w... and the backing report: https://docs.iza.org/dp17646.pdf

[2]: To be open, I might just have a much higher than average bar for precision -- I tend to prefer reading source materials than derivative press coverage, and I prefer reading a carefully worded, dry written documentation file over an informal chat description. To keep digging the hole for myself, I usually don't like the modern practice of putting unrelated full-width pictures in blog posts because they look purdy. Maybe it comes from a "just the facts, please" mentality when reading technical material.

[3]: I realize this isn't the clearest testable prediction, but I think the gist of it is falsifiable.