Shai-hulud: how a compromised npm dependency exposes team secrets

A dependency can become privileged access

On 6 August 2026, Singapore’s Cyber Security Agency published an advisory about an active campaign targeting the npm ecosystem. The Shai-Hulud malware, in the variant described as “ChainDrop”, uses malicious package versions to steal developer credentials and spread to additional packages.

The alert names compromised versions of keyv, flat-cache, file-entry-cache, cacheable and related packages. The risk is not limited to application code: a package can also run install scripts in the context of the developer workstation or CI runner downloading it.

What the attacker is really after

The malware’s name is memorable, but the operational risk is straightforward: a compromised dependency can inspect the environment it is given.

That may include:

• GitHub or GitLab tokens exposed as environment variables;
• API keys stored in a local file or terminal session;
• cloud, SSH, Terraform or Kubernetes credentials;
• reusable CI/CD secrets available to an over-permissioned runner;
• configuration files or already-authenticated sessions.

A secret left in a .env file, shell script or pipeline variable is therefore not “just local”. Once a third-party tool runs with the same permissions, it can become a bridge into the organisation.

The immediate response for a small team

If a potentially affected version was installed, treat the machine and pipeline as suspicious. CSA recommends identifying and removing affected versions, rebuilding affected systems, rotating exposed credentials and looking for unauthorised access or activity.

A practical sequence has five steps:

1. Stop propagation. Pause deployments and automated installs connected to the affected project.
2. Check the inventory. Search lockfiles, caches, developer workstations, runners and artifacts for the packages and versions.
3. Isolate and rebuild. Do not use a potentially compromised runner or workstation as a trusted base; rebuild from a clean image.
4. Revoke and replace. Rotate tokens, API keys, SSH keys and cloud secrets reachable from the affected environments. A new secret does not help if the old one remains valid.
5. Review the evidence. Check logins, package publications, workflow changes and permission changes since the first suspicious install.

Prioritise rotation: start with admin accounts, code-publishing credentials and identities that reach sensitive data or production. Record who rotated each secret, when, and where the replacement is stored.

Three types of secrets that should not be mixed

A password vault is mainly for human secrets: SaaS accounts, shared access, recovery codes and administrative credentials. It should support unique secrets, controlled sharing and a recovery process.

Machine secrets — API tokens, SSH keys and cloud credentials — need tight time, scope and usage limits. They should not be copied into a shared document simply because a team has not formalised its process yet.

CI/CD secrets should be injected through the controls provided by the platform. Prefer dedicated, short-lived and least-privileged identities; isolate runners and audit sensitive workflows. Soclyde does not replace a CI/CD secret manager: its role is to reduce risky copies and sharing around human secrets with an encrypted, local-first vault.

Reduce the attack surface before the next incident

Google Threat Intelligence’s guidance extends the emergency response with realistic guardrails: wait before adopting a newly published version, verify artifact integrity and provenance, disable install scripts by default when compatible with the project, and allow only necessary dependencies.

For a small team, that can become a monthly checklist:

• keep lockfiles under review when dependencies change;
• use npm ci or the reproducible equivalent in CI;
• apply a release-age cooldown to freshly published versions;
• run installs in an ephemeral runner with restricted outbound access;
• inventory tokens, owners, scopes and expiration dates;
• protect branches and review workflows that can access secrets;
• keep human passwords in an encrypted vault instead of tickets, spreadsheets or messages.

The goal is not to make the team distrust every package. It is to ensure that a compromised package finds neither a permanent token, nor a reusable runner, nor a collection of secrets copied everywhere.

To review the architecture and boundaries of a local-first vault, read Soclyde’s guide to local-first password managers.