What are the signs that an npm supply chain attack has reached secret-exposure stage?

What “secret-exposure stage” looks like in an npm supply chain attack

Once an npm compromise moves from tampering to secret exposure, the observable pattern usually shifts from one-off malicious package changes to activity that is harvesting, staging, or reusing credentials. That often means the attacker is now trying to persist access, expand reach, or pivot into CI/CD, registries, and source-control systems rather than just ship bad code.

Watch for the combination of secret exposure in the Shai Hulud npm malware campaign and package-linked behavior that creates or alters repositories, because that pairing is consistent with credential collection rather than simple defacement. A single suspicious publish is noisy; repeated actions that produce new secret-bearing artifacts or mirror stolen material into attacker-controlled locations are more meaningful.

Another strong indicator is unexpected automation around the package lifecycle. If a package install, postinstall hook, or dependency update is followed by fresh CI activity, new workflow runs, or newly registered runners, the attacker may have already obtained tokens or session material from developer or pipeline environments. That is especially concerning when the activity occurs outside normal build windows or on repositories that did not previously use that automation.

How to distinguish harvesting from ordinary package compromise

Secret-exposure stage is less about the initial malicious artifact and more about the follow-on effects. In practice, you are looking for evidence that the compromise reached a place where secrets could be read, copied, or replayed, such as npm tokens, GitHub tokens, cloud keys, signing material, or CI variables. The eslint-scope npm compromise is a useful example because the malicious package specifically targeted npm tokens in local files, which is the sort of behavior that changes the incident from code integrity to credential compromise.

Look for unusually rapid growth in secret-bearing artifacts, repeated access to repository metadata, or evidence that a package execution path touched developer workstations and CI environments in the same time window. When the attacker is exfiltrating secrets, the environment often gets “messier”: more clones, more temp files, more token use, more build noise, and sometimes new private repositories or forks created to stage stolen content.

That distinction matters because code tampering can sometimes be rolled back with a clean rebuild, while secret exposure means the attacker may still possess valid access. Once a secret has been copied, the damage can continue even after the malicious package is removed.

Why these signals require immediate containment

Secret exposure in an npm attack is a control failure as much as a malware event. If the package execution path can reach tokens, runners, or publish credentials, then the attacker may be able to reuse the same trust relationships your delivery pipeline relies on. The Nx s1ngularity attack shows why this stage is dangerous: secret theft can cascade into broader repository exposure and downstream abuse of developer tooling.

At this point, the key question is not whether the package was malicious, but whether any exposed credential can still authenticate to anything important. If yes, assume blast radius until proven otherwise. That means revoking tokens, invalidating sessions, rotating secrets, and checking for unauthorized repository, CI, and cloud access before spending time on deeper code forensics.

Risk and Threat Considerations

Secret-exposure stage is the point where an npm compromise stops being a software integrity issue and becomes an access-control problem. The main risk is that stolen tokens or keys can be replayed quietly, letting an attacker persist, exfiltrate more data, or modify additional packages and workflows from trusted accounts.

Failure mechanism: Malicious package code, postinstall logic, or poisoned CI automation reads secrets from local files, environment variables, caches, or runner contexts, then exports them to attacker-controlled infrastructure or uses them to create new access paths.

Impact: Incident scope expands from one compromised package to repository takeover, CI/CD abuse, cloud access, or secondary package compromise, and cleanup must include credential invalidation rather than simple package removal.

Practitioner Guidance

What to verify: Confirm whether any exposed token or key still works, and treat every successful authentication attempt from unusual infrastructure as a live compromise signal. Check GitHub, npm, cloud, and CI logs together, because secret theft often shows up as a chain of small actions rather than one obvious breach event.

Decision rule: If the attack has touched a secret-bearing environment, prioritize revocation and runner isolation before root-cause analysis. If you wait for certainty of theft, you may leave a valid credential in circulation long enough for the attacker to reuse it.

Practitioner takeaway: In npm incidents, the move to secret exposure is the line where containment must shift from package cleanup to credential and session recovery, because access persistence is now the primary threat.

Related resources from NHI Mgmt Group

• What are the signs that an npm supply chain attack is using staged payloads instead of a single malicious package?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How should security teams reduce the risk of secret theft from npm supply chain attacks?
• How do teams respond when a supply chain attack affects a trusted npm package?