Your Supply Chain Has Two New Holes: A Self-Replicating Worm and an ML Config RCE
The npm Worm That Spreads Itself
The Miasma worm is not just another malicious npm package. It's a self-replicating campaign that propagates autonomously across repositories with no human in the loop. It has hit 73 Microsoft GitHub repos across four organizations. A variant called IronWorm poisoned 50+ additional npm packages. The payload is a Rust-based information stealer, a compiled native binary that will not show up in JavaScript static analysis. The npm audit is blind to this.
The relevant question is not whether you installed a bad package directly. It is whether any transitive dependency pulled from a compromised Microsoft repo in the last N days. The campaign is ongoing and not contained.
Compromised repos infect their dependents automatically. If you auto-merge Dependabot PRs or float version ranges for Microsoft packages, you are in the blast radius. The signals worth grepping for are postinstall scripts downloading binaries, unexpected network calls during builds, and new native files appearing in node_modules.
ML Model Configs Are Now an RCE Vector
Hugging Face Transformers (2.2 billion installs) has a critical RCE reachable through model configuration files. The vector is config, not weights. Most teams already harden against pickle deserialization in weights, but nobody treats config.json as executable input. It is. The library evaluates or instantiates objects based on config values, which gives an attacker execution primitives in what looks like benign metadata.
The targeting is deliberate. GPU inference nodes typically hold training data access, model IP, cloud credentials, and lateral paths into ML infrastructure. In my context, anything calling from_pretrained() against an untrusted artifact runs in an isolated sandbox with minimal privileges and no network egress. If you are loading models you don't fully control from a request handler, do not do that.
The Meta-Signal: AI-Powered Discovery at Scale
An AI agent autonomously found 21 zero-day vulnerabilities in FFmpeg. FFmpeg is the media processing substrate of the internet, sitting under your video pipeline, thumbnail generator, browser, and mobile app. Similar agents are now being pointed at every foundational C/C++ library. In my context I am budgeting for 5-10x the patch velocity we planned for last year. The vulnerability management process most teams run was not designed for that throughput.
What to do
Run `npm ls` against known-bad package lists from GitHub advisories today. Scan for unexpected postinstall scripts or native binary downloads in recently-updated dependencies.
Audit all Hugging Face model loading paths this sprint — identify where configs are parsed from untrusted sources and add sandboxing or strict allowlisting.
Add runtime behavioral monitoring to CI/CD pipelines — detect unexpected network calls and native binary execution during npm install/build phases.
Inventory all FFmpeg usage (direct and transitive) and ensure media processing runs in sandboxed environments (gVisor, Firecracker) before patches drop.