DEV Community

Abbas
Abbas

Posted on

Sha1-Hulud Attack: What Happened & How to Clean Your GitHub Safely

Github Commit History

If your GitHub repos were suddenly hit with unknown commits, modified README files, or a weird new repo you never created, you may have been affected by Sha1-Hulud, one of the largest npm supply-chain attacks in recent times.

This is a malware campaign that spread through compromised npm packages and silently impacted thousands of developers.

This post breaks down:

  • What Sha1-Hulud actually is
  • What it does to your system and GitHub
  • And the exact steps to recover safely

What Is Sha1-Hulud?

Sha1-Hulud is malware distributed through infected npm packages.

Attackers compromised legitimate package maintainers and injected malicious install scripts. The moment a developer installed one of these packages, the malware executed automatically.

Once active, it used the developer’s access to:

  • Steal secrets (API keys, tokens, cloud creds)
  • Spread further using trusted access
  • Push unwanted commits to repos on GitHub

This is called a supply-chain attack, attackers don’t hack you, they hack the tools you trust.

What It Does After Infection

Most affected devs noticed:

  • A new unknown repo suddenly appears
  • That repo contains double-encoded Base64 data
  • When decoded → it reveals leaked credentials
  • README files across many repos get modified
  • Commits appear that you never made

All of this originates from malicious packages coming through npm.

Why This Is So Dangerous

Even if the attack leaves visible clues, the real threat is silent:

  1. APIs can be abused
  2. Cloud bills can explode
  3. Databases can be accessed
  4. User data can leak

Once a secret is exposed, assume it’s compromised forever.

The First Thing You Must Do (Do This Immediately)

This is the most critical step:

  1. Find the new repo created by the attack
  2. Make that repository PRIVATE immediately
  3. That repo contains all your leaked credentials, only protected by double Base64 encoding (which is NOT real security).
  4. If it stays public, anyone on the internet can decode your secrets.

How to Fully Clean the Damage Safely

1. Rotate All Exposed Credentials
Immediately regenerate:

  • API keys
  • Access tokens
  • DB passwords
  • Cloud provider secrets
  • CI/CD tokens Never reuse old credentials.

2. Find All Repositories Modified by Sha1-Hulud
I created a script that:

  • Scans all your repos
  • Detects the ones touched by Sha1-Hulud
  • Lists all malicious commits

Run it here:
https://github.com/abbasmithaiwala/repo-manager

3. Revert the Malicious Commits (With Extreme Caution)
From the same repo, use the undo-commit script, which reverts the commits and force pushes.

⚠️ Important Warning Before Force Push

Make sure no legit commits were made after the malicious one

  1. --force is destructive
  2. Always review commit history
  3. If unsure → create a backup branch first
  4. One careless force push can permanently delete valid work.

How This Attack Actually Happened

This was:

  • Not a GitHub bug
  • Not a hash vulnerability
  • Not a direct account hack

It happened because:

  • A trusted npm package was compromised
  • Devs or CI pipelines installed it
  • The malicious install script ran automatically
  • Secrets were harvested and misused
  • This is the modern reality of open-source supply chain attacks.

How to Protect Yourself Going Forward

Basic but powerful habits:

  • Never commit:
  • .env files
  • Private keys
  • API tokens
  • Use .gitignore properly
  • Store secrets only in environment variables
  • Enable GitHub secret scanning
  • Lock dependency versions
  • Avoid blindly running install scripts in CI
  • Be cautious with rarely-maintained npm packages

Security is no longer “advanced stuff”, it’s basic dev hygiene.

Final Thoughts

Sha1-Hulud showed how one compromised dependency can silently touch:

  • Thousands of machines
  • Thousands of repos
  • And millions of users downstream

If you were affected:

  1. Make the leaked repo private
  2. Rotate all secrets immediately
  3. Revert commits safely
  4. Lock down your workflow

You didn’t fail, you just gained real-world security experience.

Top comments (0)