Topic starter
11/08/2026 3:11 pm
TL;DR: Akeyless reports that Shai-Hulud spread through npm packages by harvesting long-lived credentials from developer workstations, CI/CD systems, and AI-assisted coding environments, affecting more than 400 infected packages and over two billion monthly installs. Static secrets, not software flaws, are now the easier supply-chain target, and blast-radius reduction has become the real control objective.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Shai-Hulud Returns: The npm Worm That Only Works Because Your Secrets Are Standing Still”.
Key questions
Q: What fails when package installs can read standing credentials?
A: The failure is credential residence, not package execution alone.
Q: Why do long-lived CI/CD or workstation secrets increase supply-chain risk?
A: They extend the useful lifetime of any secret that malware finds.
Q: What are the signs that credentials are too easy to harvest in development environments?
A: Common signs include secrets in .env files, tokens in pipeline variables, SSH keys on workstations, and AI tool configurations that persist access across sessions.
Practitioner guidance
- Remove standing secrets from developer workstations Move long-lived credentials out of .env files, local config, and other disk locations that routine package installs can scan.
- Issue runtime-scoped credentials for CI/CD jobs Replace reusable pipeline tokens with credentials fetched at execution time and limited to the job that needs them.
- Inventory AI assistant persistence mechanisms Review .claude settings, VS Code task files, and similar workspace hooks for stored tokens, cached access, or automatic execution paths that can outlive a session.
Bottom line: The attack shows that supply-chain compromise can start with ordinary credential exposure, not with a software vulnerability in the target application.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Specific examples of the credential locations the malware searched, including workstation files and CI/CD paths
- The article's step-by-step recommendations for reducing standing credentials across developer and pipeline environments
- Details on how the malware persisted through AI assistant and editor configuration changes
- A closer look at the zero-knowledge and distributed-fragment architecture claims in the source article
👉 Read Akeyless's analysis of Shai-Hulud and standing credential risk →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
11/08/2026 3:26 pm
Standing credentials have become the supply-chain control point: this attack worked because secrets remained reachable on endpoints and build systems long after they should have been ephemeral. That is not a tooling flaw alone. It is a governance failure in how organisations decide where credentials may live, how long they may persist, and which runtime contexts can read them. Practitioners should treat secret residence as a supply-chain risk variable, not a back-office storage detail.
A few things that frame the scale:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: How should teams respond when a package or maintainer account is compromised?
A: Assume any reachable credentials may be exposed, then rotate broadly across vaults, cloud secret managers, and developer tooling. The response should prioritise the credentials that could unlock other secrets, not just the first token named in the incident report.
👉 Read our full editorial: Shai-Hulud shows why standing credentials now drive supply-chain risk
This post was modified 4 days ago by NHI Mgmt Group