The npm Supply Chain Attack Explained · Burstiness and Perplexity

The npm Supply Chain Attack Explained

The npm Supply Chain Attack Explained: What You Need to Know (And What To Do)

A plain-language guide to the Shai-Hulud "Second Coming" attack—and how to protect yourself

The Situation in Plain English

If you're a developer, you probably use npm install regularly. It's one of those commands that feels as routine as checking your email. You type it, lean back, and wait for your project's dependencies to install.

What if I told you that between November 21-24, this year, that simple command became dangerous?

Here's what happened: attackers compromised some of the most popular npm packages used by developers worldwide—including tools made by Zapier, Postman, PostHog, ENS Domains, and AsyncAPI. When developers ran npm install to use these packages, malicious code ran automatically before the installation even finished. Most developers never noticed.

The malware didn't install ransomware or encrypt your files. It did something arguably worse: it stole your secrets—every API key, GitHub token, AWS credential, and authentication token sitting on your machine—and uploaded them to public GitHub repositories where attackers could access them.

Think of it like someone stealing your house keys. You might not notice the keys are gone for days. By then, the thief has already made copies and given them to accomplices.

What Makes This Different? The "Worm" Aspect

Traditional malware might infect one package. You'd catch it, the security team would fix it, and life goes on.

This attack uses "worm" tactics. It's self-propagating.

Here's how: The malware didn't just steal your secrets—it used those stolen credentials to log into npm and upload even more infected versions of other packages. Those new infected packages then did the same thing to the next developer who ran npm install.

Result: In just four days, the attack spread to over 425 packages and compromised 25,000+ GitHub repositories full of stolen credentials. That's roughly 1,000 new breaches every 30 minutes.

The attackers even named it after the sandworms in Dune—massive, self-replicating creatures that devour everything in their path. The metaphor is uncomfortably accurate.

The Attack Surface: What Could Be Compromised?

If you ran npm install (or similar commands) between November 21-24, 2025, here's what was at risk:

What the Malware Looks For (And Steals)

The malware uses a sophisticated tool called TruffleHog that scans your entire machine for:

GitHub personal access tokens — your keys to GitHub
npm authentication tokens — your access to npm packages
AWS credentials — your cloud infrastructure access
Azure and Google Cloud credentials — more cloud accounts
SSH private keys — your secure shell authentication
API keys from services you use
Database connection strings — passwords for your databases
.env files — configuration files full of secrets

Where It Looks

The malware scans:

Your home directory (everything under /home/username or ~/)
Git configuration files
SSH key folders
npm configuration files
Environment variable files
Browser cache and history
Any text file that might contain credentials

How It Escapes Detection

Once installed, the malware:

Creates a backdoor that lets attackers run commands on your machine anytime they want
Uses GitHub Actions (a legitimate automation tool) to hide its activity
Can wipe your entire home directory if it can't exfiltrate data—a destructive fallback
Spreads to other packages by using stolen credentials to compromise npm maintainer accounts

The Consequences: What Actually Happened?

Let's translate the numbers into what they mean:

Impact

What It Means

425-500 packages infected

If you used tools from Zapier, Postman, PostHog, ENS Domains, or AsyncAPI—or dozens of other open-source packages—you might be affected

132 million monthly downloads

Developers who use these tools regularly use them for production applications, meaning this could affect end users too

25,000+ GitHub repos with stolen secrets

Someone has access to cloud accounts, API services, databases, and deployment credentials belonging to thousands of development teams

775 GitHub tokens compromised

Attackers can now access source code repositories, push malicious code, or delete projects

373 AWS credentials compromised

Attackers could spin up expensive infrastructure, access databases, or modify cloud configurations

300 GCP and 115 Azure credentials

The same risks apply to Google Cloud and Microsoft Azure customers

New secrets exposed every 30 minutes

The attack was still ongoing as of November 24, with new compromised repositories being added continuously

Real-World Risks

If your credentials were stolen, attackers can:

Access your cloud infrastructure and run expensive operations (costing you thousands)
Deploy malware to your production servers affecting your users
Steal your source code (a massive IP loss)
Modify your applications to include backdoors or steal user data
Impersonate you to other developers or services
Delete critical infrastructure out of spite
Access customer data if your applications store it in compromised databases

How to Check If You're Affected

Step 1: Identify When You Last Used npm

What you need to know: Did you run npm install (or npm ci, npm update, yarn, pnpm install, etc.) anytime between November 21 and November 24, 2025?

If you're not sure:

Check your terminal history (type history | grep npm)
Check your project's files for recent modification dates
Ask your team members if they deployed anything during those dates

If the answer is "I don't know" or "maybe": Assume you're affected. It's better to be safe.

Step 2: Check Your package.json File

This file lists every package your project depends on. Here's how to check it:

On Mac or Linux:

On Windows (PowerShell):

What to look for: If the command returns any results, your project uses one or more of the affected packages.

Step 3: Check the Dates on Your Lock File

Your package-lock.json or yarn.lock file shows when packages were installed.

On Mac or Linux:

ls -la package-lock.json

Look at the date. If it's between November 21-24, 2025, and you had any of the packages mentioned above, you could be affected.

Step 4: Check GitHub for Your Stolen Secrets

This is the scary step, but it's crucial.

Go to GitHub search: https://github.com/search

Search for: "Sha1-Hulud: The Second Coming"

What you're looking for: Repositories containing YOUR credentials. If you see your API keys, AWS credentials, or other secrets, your machine was infected.

If you find your secrets:

Do not panic — many credentials were already revoked by GitHub/npm
Take a screenshot — evidence of what was exposed
Delete the repository (if it's yours or if the owner allows it)
Report it to GitHub — they have a security form
Assume compromise — treat all credentials that were exposed as stolen

Step 5: Audit Your Machine's Activity

Check for suspicious GitHub Actions workflows:

ls -la .github/workflows/

Look for files you didn't create, especially:

discussion.yaml
sha1_update.yaml
Anything with recent modification dates

If you see files that aren't yours, the malware installed a backdoor.

What To Do If You're Affected

Immediate Actions (Do These First)

1. Rotate Every Credential on Your Development Machine

You need to assume that every secret on your machine is now in attacker hands.

Credential Type

How to Rotate

GitHub Personal Access Tokens

Go to github.com → Settings → Developer settings → Personal access tokens → Delete old ones, create new ones

npm Tokens

Run npm logout, then npm login to create new credentials

AWS Credentials

Go to AWS Console → IAM → Users → Security credentials → Create new access key, delete the old one

Azure Credentials

Go to Azure Portal → App registrations → Manage certificates & secrets → Revoke and create new

Google Cloud Credentials

Go to Google Cloud Console → APIs & Services → Credentials → Delete old service accounts

SSH Keys

Delete old SSH keys from ~/.ssh/; generate new ones with ssh-keygen -t ed25519

2. Update Any Service That Used These Credentials

If you use these credentials in:

GitHub Actions workflows
CI/CD pipelines
Deployment configurations
Local .env files

Update them to use the new credentials you just created.

3. Check for Unauthorized Access to Your Accounts

Go to each service and check for:

Recent login attempts
New API calls or activity
Deployed resources you don't recognize
Modified configurations

For AWS specifically, check your CloudTrail logs for suspicious activity.

Medium-Term Actions (Within 24 Hours)

4. Clean Your Machine (The Safe Way)

Option A: The Conservative Approach (Recommended if you're unsure)

Back up your important project files (source code, configuration, but NOT .env files with secrets)
Reinstall your operating system
Restore only your project files, not your entire home directory
This is the "nuclear option" but guarantees the malware is gone

Option B: The Active Cleanup (If you're technical)

Delete all SSH keys from ~/.ssh/ and generate new ones
Delete all .env files and recreate them with new credentials
Delete npm cache: npm cache clean --force
Delete package-lock.json and node_modules, then run npm installwith fresh packages
Audit what .github/workflows contains and delete unauthorized files
Check system logs for unusual process execution

Long-Term Actions (This Week)

5. Review and Improve Your Secret Management

Going forward:

Use a secrets manager (1Password, LastPass, AWS Secrets Manager) instead of storing secrets in .env files
Never commit secrets to Git — use .gitignore to exclude .env files
Use environment variables in CI/CD systems instead of committing credentials
Rotate credentials quarterly as a best practice
Audit who has access to your deployment credentials

6. Notify Your Team and Users (If Applicable)

If you're part of a team or run applications with user data:

Tell your security team immediately
If customer data was accessible through compromised credentials, you may need to notify users
Review audit logs to see if anyone actually accessed data with stolen credentials
Document what happened for future security reviews

7. Enable Two-Factor Authentication (2FA) Everywhere

Activate 2FA on:

GitHub
npm
All cloud providers (AWS, Azure, GCP)
Any other service that supports it

This prevents attackers from using stolen passwords even if they have them.

Quick Reference Checklist

Print this and work through it:

[ ] I know when I last ran npm install (November 21-24, 2025 or unknown)
[ ] I checked my package.json for Zapier, Postman, PostHog, ENS Domains, or AsyncAPI packages
[ ] I searched GitHub for "Sha1-Hulud: The Second Coming" to see if my secrets were exposed
[ ] I checked .github/workflows/ for unauthorized files
[ ] I rotated all my GitHub tokens
[ ] I rotated all my npm credentials
[ ] I rotated all my AWS/Azure/GCP credentials
[ ] I rotated all my SSH keys
[ ] I updated credentials in my CI/CD pipelines and GitHub Actions
[ ] I enabled 2FA on GitHub, npm, and cloud services
[ ] I informed my team (if applicable)
[ ] I notified affected users (if applicable)

Why This Attack Was Possible (And How to Think About Risk)

The fundamental problem: We trust package managers with our entire development environment.

When you run npm install, you're saying: "Download and automatically execute code from the internet, created by people I've never met."

Usually, this works because:

Package maintainers are generally trustworthy
npm has some security measures
The development community self-polices

But attackers targeted the weak link: package maintainers themselves. They compromised the accounts of people who maintain popular packages, giving them the keys to the kingdom.

This isn't a failure of npm specifically—it's a fundamental challenge of modern software development. Every modern tech stack has the same risk.

What You Can Do About It

Audit dependencies — Know what packages you're using and why
Keep packages updated — Security patches matter
Use lock files — package-lock.json prevents unexpected version changes
Implement security scanning — Tools like Snyk and Dependabot scan for known vulnerabilities
Limit permissions — Your CI/CD system shouldn't need access to everything
Monitor for unusual activity — Set up alerts on your cloud accounts

The Bottom Line

The Shai-Hulud "Second Coming" attack is real, serious, and currently ongoing.

If you used npm between November 21-24, 2025:

Check if you're affected (using the steps above)
If you are: Rotate credentials immediately
Clean your machine or reinstall your OS
Implement better secret management going forward

This type of supply chain attack is becoming more common. The good news: you can protect yourself through good practices and prompt action.

The better news: if you act now, you can prevent the worst-case scenario.

Additional Resources

npm Security Advisories: https://www.npmjs.com/advisories
GitHub Security Alerts: Check your repository's Security tab
AWS Security: https://aws.amazon.com/security/security-best-practices/
CISA Alerts: https://www.cisa.gov/ (US government cybersecurity agency)

Questions? Common Concerns

Q: If I wasn't using npm during those four days, am I safe? A: Likely, but check your package-lock.json date to be sure. If you installed a package after November 24, you should also check that package's integrity.

Q: What if I'm not a developer? Should I care? A: If your company uses any of these tools (Zapier, Postman, PostHog, etc.) in their development process, your technical team should know about this. Applications you use might be affected.

Q: Can this happen again? A: Yes. Supply chain attacks are a growing threat. The best defense is staying informed, keeping software updated, and following security best practices.

Q: I found my secrets in a GitHub repo with that name. What do I do? A: Rotate all credentials immediately. Report the repository to GitHub. Check for suspicious activity in any service those credentials access. Document it. You've been compromised, but quick action limits the damage.

Last Updated: November 25, 2025 Status: This attack is ongoing as of the publication date. Check npm advisories for the latest information.

1 comment

Burstiness and Perplexity

skool.com/burstiness-and-perplexity

Master AI use cases from legal & the supply chain to digital marketing & SEO. Agents, analysis, content creation--Burstiness & Perplexity from NovCog

Leaderboard (30-day)