Supply Chain Is the New Frontier
Two major supply chain attacks in one week. Both hit packages with tens of millions of weekly downloads. Both got through because of the basics: stolen credentials, no MFA, and blind trust in package registries.
litellm: the .pth that exposed everything
A week ago, litellm versions 1.82.7 and 1.82.8 were published to PyPI with a malicious .pth file. Not a postinstall script. A .pth file dropped into Python’s site-packages that auto-executes on every Python interpreter startup. You didn’t need to import litellm. Running python --version was enough.
The payload harvested everything: ALL environment variables, SSH private keys, ~/.kube/config, AWS/GCP/Azure credentials. A Snyk deep-dive traced the root cause to a compromised Trivy GitHub Action in LiteLLM’s own CI/CD. The attacker (TeamPCP) stole PyPI publishing credentials through that vector.
The irony: the malware was so poorly written it outed itself. Callum McMahon at FutureSearch was testing a Cursor MCP plugin that pulled litellm as a transitive dep. His machine froze. RAM exhaustion. The .pth file spawned a subprocess that triggered another .pth execution, creating an accidental fork bomb. The credential stealer was caught because it was basically vibecoded.
PyPI quarantined it within 40 minutes. But litellm gets ~3.4 million downloads per day. CrewAI, Browser-Use, DSPy, Mem0, Instructor all depend on it.
For us at Cominty: we use IAM Identity Center (formerly AWS SSO), the recommended method for managing AWS credentials. It replaces long-term static access keys with short-lived, automatically refreshed temporary credentials. The biggest damage vector in these attacks is over-permissive AWS keys sitting on leadership machines that never get rotated. That one doesn’t apply to us. SSH keys, API tokens in env vars, k8s configs? Those were still at risk, but rotatable.
axios: a nation-state RAT in your node_modules
Today, axios 1.14.1 and 0.30.4 hit npm with a fake dependency (plain-crypto-js) that phoned home to a C2 server and deployed a cross-platform RAT. Both Google and Microsoft attributed it to North Korean state actors (Sapphire Sleet). ~100 million weekly downloads. Tagged latest. Live for 2 to 3 hours before npm removed it.
What it all boils down to
Strip away the technical details and both attacks share the same root cause: credential theft → account access → push malicious version → registry distributes it to millions before anyone notices.
The ecosystem trust model is the problem. npm and PyPI assume that if you have valid publishing credentials, you ARE the maintainer. No anomaly detection on publish patterns, no mandatory signing, no delay-and-scan window for new versions of critical packages.
(And honestly, maintainers of packages powering multi-billion dollar infrastructure still aren’t using proper MFA or password managers. Let that sink in.)
These attacks spread to millions of machines in MINUTES. The detection window is tiny. The litellm malware got caught because it was badly written. The axios RAT was professional. Next time we might not get lucky.
Karpathy put it well: supply chain attacks are “basically the scariest thing imaginable in modern software.” Every time you install any dependency, you could be pulling in a poisoned package anywhere deep inside its entire dependency tree. He even shared his own close call: a @googleworkspace/cli install resolved to an unaffected axios version by pure luck. Had he run it hours earlier, he’d have been compromised. His takeaway: package manager defaults need to change so that a single compromised package cannot spread through users via unpinned dependencies.
Mitigating locally
Right after the axios disclosure, I pushed Socket Firewall to the team as a first step. It’s relatively new but promising. It intercepts package manager requests and checks packages against Socket’s security intelligence before they hit your machine. Usage is straightforward: prefix your install commands with sfw (e.g. sfw npm install instead of npm install). I alias it in my .zshrc so I don’t have to think about it (.bashrc or equivalent on your system).
Supports npm, yarn, pnpm for JS/TS. For Python, pip and uv are covered (poetry is not, for now). One caveat: the free tier warns on AI-flagged packages but doesn’t block until a human at Socket confirms the threat. Enterprises should look at the paid version for real-time blocking. And after installing, clear your caches so old cached packages don’t bypass the firewall.
But this is just one layer for local dev safety. In production, dependency pinning should be the default. package-lock.json, poetry.lock, uv.lock. Update only when needed, review what changed.
The old-school playbook
Supply chain attacks are not new. What’s new is the scale: packages with 100M weekly downloads getting compromised, nation-state actors involved, and detection windows measured in minutes.
The defense hasn’t changed though. Pin your dependencies. Use short-lived credentials. Rotate secrets. Audit what you install. Don’t trust registries to do security for you.
It slows things down. That’s the point. Speed without supply chain hygiene is just shipping vulnerabilities faster.