Security Advisory: npm Supply-Chain Attack “Sha1-Hulud 2.0”

This security advisory is for companies with software development teams. If your teams use the public npm registry or GitHub (especially GitHub Actions), please read and share this advisory with your developers and DevOps teams.

There is an ongoing software supply-chain attack in the npm ecosystem, commonly referred to as “Sha1-Hulud” / “Shai-Hulud 2.0” or “The Second Coming.” Attackers have compromised npm maintainer accounts and released malicious versions of legitimate npm packages. When installed, these packages run code during the install phase (for example via preinstall scripts), often using the Bun JavaScript runtime to steal credentials, tamper with CI/CD workflows, and spread further.

Who may be affected

You are potentially affected if:

• Your developers or CI/CD systems run npm / pnpm / yarn against the public npm registry.
• You use GitHub (especially GitHub Actions) to build, test, or deploy.
• Developer machines or build agents have access to:
  • npm tokens
  • GitHub PATs / SSH keys
  • Cloud credentials (AWS, Azure, GCP, etc.)

Key risks

• Credential theft and public exposure: Stolen npm tokens, GitHub credentials, SSH keys, and cloud keys may be uploaded to public GitHub repositories created with compromised GitHub accounts, sometimes mixing data from multiple victim organizations.
• CI/CD takeover and persistence: Attackers can modify GitHub Actions workflows and register unauthorized self-hosted runners, giving them ongoing access to code, builds, and secrets.
• Destructive “wiper” behavior: Some variants attempt to delete user data (for example, home directories) if they lose access to GitHub or npm, such as after tokens are revoked or network access is blocked.
• Rapid spread: Using stolen tokens, attackers can republish trojanized packages and propagate via normal dependency updates and CI/CD jobs.

Indicators of Compromise (IoCs)

Ask your development and security teams to check for the following. Any positive hit should be treated as a serious incident. If you are a client of Bay State IT and need assistance checking for IoCs, reach out to our team.

1. Suspicious public GitHub repositories (critical)
   • Check all organization and user GitHub accounts for public repositories whose description is exactly: Sha1-Hulud: The Second Coming
   • If found, assume credentials and other sensitive data have been exposed.
2. Rogue self-hosted GitHub Actions runners
   • In GitHub, review self-hosted runners and look for unauthorized entries, especially with the name: SHA1HULUD
3. Unexpected GitHub workflow files
   • Search repositories for an unexpected workflow file: .github/workflows/discussion.yaml
   • Treat any unauthorized appearance of this file as an IoC.
4. Unexpected use of Bun
   • Review build logs and systems for use of the Bun JavaScript runtime where it is not normally used.
   • Examples include:
     • Bun being installed from bun.sh.
     • A Bun binary present on systems where it is not expected (for example under a user’s home directory).
5. Malicious preinstall scripts and loader files
   • In package.json files, look for suspicious preinstall scripts that reference files such as:
     • setup_bun.js
     • bun_environment.js
6. Suspicious exfiltration files in repositories
   • In any attacker-created GitHub repositories, look for files like:
     • cloud.json, environment.json, contents.json, truffleSecrets.json, actionsSecrets.json
   • These may contain exfiltrated secrets and environment data.

Immediate actions (if any IoC is found)

If any of the indicators above are present, treat this as an active compromise and take the following steps.

Note: if you are a Bay State IT client (or would like to become one), reach out to our helpdesk immediately if you have discovered any IoCs. We are here to assist your team with investigating and take any necessary remediation steps.

1. Identify and contain exfiltration repositories
   • Locate any repositories with the description Sha1-Hulud: The Second Coming.
   • Securely download and review their contents to identify exposed credentials and data.
   • Treat all secrets in those repositories as compromised and handle them according to your incident-response process.
2. Audit and clean CI/CD environments
   • In GitHub:
     • Remove unauthorized self-hosted runners, especially SHA1HULUD.
     • Remove unexpected workflows, especially .github/workflows/discussion.yaml.
   • In CI/CD systems generally:
     • Review recent builds for unexpected use of Bun or unusual preinstall scripts.
     • Where possible, rebuild CI runners and build agents from clean, trusted images.
3. Rotate credentials (assume full compromise): For any affected machines, accounts, or repositories:
   • Revoke and rotate:
     • GitHub PATs and SSH keys
     • npm tokens
     • Cloud credentials (AWS, Azure, GCP, etc.)
     • Any other API keys, database passwords, or secrets
   • Replace them with scoped, time-limited tokens wherever possible.
4. Isolate and rebuild affected systems
   • Isolate compromised developer machines and CI runners from the network.
   • Prefer reimaging or reinstalling from a trusted baseline over attempting in-place cleanup, due to persistence and possible wiper behavior.
5. Clean and rebuild dependencies in affected projects:
   • Remove existing Node.js dependencies (for example, clear node_modules and related caches using your standard process).
   • Update and commit lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml, etc.) to known-good versions.
   • Reinstall dependencies in a clean environment (for example using reproducible install commands such as npm ci in CI/CD).

Ongoing best practices for npm and supply-chain security

To reduce risk from this and future campaigns, we recommend:

• Pin dependencies and commit lockfiles for reproducible, auditable builds.
• Use deterministic installs in CI/CD (such as npm ci or equivalents) to avoid unexpected dependency changes.
• Limit lifecycle scripts:
  • In CI/CD, consider disabling install scripts by default and enabling them only where necessary.
• Minimize third-party and rarely maintained dependencies, especially deeply nested ones.
• Enforce MFA/2FA for npm and GitHub accounts and prefer trusted publishing or granular tokens over broad, long-lived tokens.
• Regularly rotate and tightly scope credentials, removing unused or overly privileged tokens.
• Continuously review GitHub security surfaces: workflows, self-hosted runners, webhooks, OAuth apps, deploy keys, and PATs.
• Run continuous dependency and security scanning to detect known vulnerabilities and suspicious packages.

Need assistance?

If you would like support reviewing your dependencies, CI/CD pipelines, or incident-response posture for this campaign, our team is available to assist. Reach out to us through the helpdesk or give us a call at (781) 229-7828.