ChainDrop, a campaign linked to Shai-Hulud
On August 4, 2026, malicious npm package versions launched the ChainDrop campaign, which Singapore’s Cyber Security Agency (CSA) links to the Shai-Hulud family. Its August 6 advisory says the malware steals developer credentials and can spread to additional packages. Microsoft documented more than 400 affected packages at that time; the CSA lists more than 1,300 compromised versions. These figures count packages and versions, not confirmed installations or organisations compromised.
The CSA’s notable list includes keyv@6.0.0, flat-cache@6.1.24, file-entry-cache@11.1.6 and cacheable@2.5.1. The full list is broader and includes transitive dependencies: check the versions actually resolved in lockfiles rather than only direct dependencies. A preinstall script can run code with the permissions of the workstation or runner installing the package.
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. The CSA and Microsoft recommend identifying and removing affected versions, rebuilding affected systems, rotating exposed credentials and looking for unauthorised access or activity.
A practical sequence has five steps:
- Stop propagation. Pause deployments and automated installs connected to the affected project.
- Check the inventory. Search lockfiles, caches, developer workstations, runners and artifacts for the packages and versions.
- Isolate and rebuild. Do not use a potentially compromised runner or workstation as a trusted base; rebuild from a clean image.
- 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.
- 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
Microsoft and Elastic’s analyses add campaign-specific safeguards: review lockfiles, caches and build artifacts, pin known-good versions, and introduce a delay before adopting new releases. Provenance alone is not a guarantee: Microsoft notes that some malicious publications could use legitimate publishing workflows.
For a small team, that can become a monthly checklist:
- keep lockfiles under review when dependencies change;
- use
npm cior 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.
How Soclyde fits
Soclyde does not detect malicious npm packages and does not replace a machine-secret manager or your CI/CD platform’s secret controls. A local-first vault is mainly for human passwords and shared access; it should not become a place to copy pipeline tokens or API keys.
To review the architecture and boundaries of a local-first vault, read Soclyde’s guide to local-first password managers.
Key takeaways
After installing a compromised version, deleting the package is not enough: isolate and rebuild the environment, revoke credentials it could access, and review repositories, publications and produced artifacts. The CSA’s notable version list and Microsoft and Elastic’s analyses help scope those checks.
For handling shared access with clear sharing and revocation rules, see our guide to secure team password sharing.
To discuss managing human passwords, you can also contact Soclyde.
