Stop Auto-Updating Everything. Seriously.

Something bad just happened and most people missed it.

Two weeks ago, a group called TeamPCP pulled off the largest supply chain attack in npm history. They compromised over 160 packages across npm and PyPI, including TanStack (12 million weekly downloads), Mistral AI, UiPath, OpenSearch, and Guardrails AI. The CVE is CVE-2026-45321. CVSS score: 9.6 out of 10.

Here's the part that should make you uncomfortable: the malicious packages were published by the legitimate CI/CD pipeline. Not a stolen credential. Not a rogue maintainer. The attacker poisoned the build cache through a pull request, and when the real maintainers merged their own code, the release pipeline packaged the malware and shipped it with valid signatures.

That means even if you were checking provenance attestations, even if you had SLSA Build Level 3 verification, you would have accepted these packages as trustworthy. Because technically, they were. The build system itself was compromised.

If you had auto-updates enabled or weren't pinning your dependency versions, you pulled this in automatically. No warning. No prompt. Just silent credential theft across AWS, Azure, GCP, Kubernetes, and about 90 other developer tool configurations.

This isn't new. This keeps happening.

Remember the xz backdoor in 2024? A single maintainer spent two years building trust in a critical Linux compression library, then slipped in a backdoor that would have given them remote access to basically every Linux server running OpenSSH. Someone caught it by accident because they noticed their SSH connections were 500 milliseconds slower than usual.

By accident. The entire security of the internet's infrastructure came down to one developer being annoyed about half a second of latency.

Before that, we had event-stream in 2018. A popular npm package maintainer handed over control to someone who seemed helpful, and that person added code to steal cryptocurrency wallet credentials. Millions of downloads before anyone noticed.

And now Mini Shai-Hulud, which is actually a worm. It doesn't just sit in one package. Once it compromises a developer's credentials, it uses those credentials to publish poisoned versions of every other package that developer has access to. It spreads. Exponentially.

The pattern is always the same: trusted package, legitimate-looking update, malicious payload that rides the supply chain right into your production environment.

Here's what you need to do. Today.

1. Pin your dependency versions.

Stop using ^ and ~ in your package.json. Stop letting your package manager decide what version to install. If you tested your application with react@19.1.0, then that's what should be running in production. Not react@19.1.1 that came out yesterday and nobody reviewed.

Your lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) should be committed to your repo and it should be the source of truth. If someone tells you not to commit your lockfile, they're wrong.

2. Turn off auto-updates.

I know this sounds backwards. "But Darius, you're supposed to keep things updated for security!" Yes. But there's a difference between updating deliberately and updating blindly.

Disable Dependabot auto-merge. Disable Renovate auto-merge. Disable automatic system updates on production servers. Disable automatic app updates on company devices during business hours.

Updates should be reviewed, tested, and deployed on your schedule. Not on the attacker's schedule.

3. Wait before updating.

When a new version of a dependency drops, don't install it the same day. Give it 48 to 72 hours. Let the community find the problems first. If a package gets compromised, it usually gets caught within that window, and the malicious version gets pulled.

This is not laziness. This is risk management. The people who got hit by Mini Shai-Hulud on May 11th were the fast adopters. The people who waited a day were fine.

4. Audit what you're actually running.

Run npm audit or pip audit or whatever your ecosystem's equivalent is. Actually read the output. If you see critical vulnerabilities in packages you depend on, deal with them.

Better yet, use a tool like Socket, Snyk, or Dependabot (for alerts, not auto-merge) to continuously monitor your dependency tree. These tools catch known malicious packages before they hit your build.

5. Review your CI/CD pipeline permissions.

The TanStack compromise happened because their GitHub Actions workflow had overly broad permissions. The attacker was able to poison a cache that was later used by a trusted workflow.

Your build pipeline should follow least privilege. If a workflow doesn't need write access to the package registry, don't give it write access. If a workflow doesn't need access to production secrets, don't give it access to production secrets. This sounds obvious but go look at your workflow files right now and tell me every permission is locked down tight.

6. Check for the specific indicators of this attack.

If you use any packages from TanStack, UiPath, Mistral AI, OpenSearch, Guardrails AI, or LiteLLM, check your lockfile for versions published between May 11-13, 2026. Check your .claude/ and .vscode/ directories for files you didn't put there. Rotate your npm tokens, GitHub personal access tokens, and cloud provider credentials if there's any chance you pulled an affected version.

The bigger picture for business owners.

If you're not a developer and you're reading this thinking "this doesn't apply to me," think again.

Your website runs on software. Your payment processor runs on software. Your email, your CRM, your accounting system, your scheduling tool, all of it depends on a chain of software packages maintained by people you've never met.

When that chain gets poisoned, it doesn't matter how good your password is or how well-trained your staff is. The software itself is the attack vector.

This is why you need someone watching your supply chain. Not just your firewall. Not just your email. The actual software running your business.

If that sounds like more than you can handle on your own, that's because it is. That's literally why we exist.

(773) 417-9994 or southsidechisolutions.com