tensorlake npm compromise exposed cloud and GitHub credentials

At a glance

What this is: Flatt Security says a malicious tensorlake npm package used a preinstall hook to steal cloud, source control, Kubernetes, and Vault credentials, then exfiltrate them and watch for token rotation.

Why it matters: This matters because package installs can become credential theft events, so IAM, secrets, and NHI teams need controls that detect malicious install-time execution and limit blast radius across tokens, keys, and browser-stored credentials.

Context

A compromised package can turn ordinary software installation into a credential compromise, especially when preinstall scripts are allowed to run without review. In this case, the risk spans both human and non-human identities because the stolen material included AWS credentials, GitHub tokens, Kubernetes access, and Vault secrets used by workloads and operators alike.

The governance gap is not just malicious code in a package registry. It is the assumption that trusted build and install paths are safe enough to expose secrets, plus the failure to separate sensitive credentials from environments where package execution can read them.

Key questions

Q: What breaks when malicious npm packages execute during CI/CD installs?

A: The main failure is that package installation becomes code execution inside a trusted build context. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.

Q: Why do developer secrets make supply chain incidents much harder to contain?

A: Because developer secrets often act like non-human identities with broad runtime reach. If the same token can publish code, access cloud services, or trigger automation, one compromise can spread across multiple systems without needing a new exploit. Containment becomes difficult when credential scope is wider than the code path that exposed it.

Q: What are the signs that an npm-based supply chain attack is stealing credentials?

A: Look for unexpected lifecycle script execution, outbound connections after install, reads of local secret files, access to browser profile data, and new use of cloud or GitHub tokens from unusual systems. A malicious package often leaves a pattern across endpoint telemetry, secrets access logs, and identity provider audit trails rather than one obvious alert.

Q: What should teams do when a malicious package has already been installed on developer machines?

A: Isolate affected systems, identify every machine that installed the package, and remove the dependency from build paths and caches. Then hunt for follow on downloads, temporary files, suspicious Python processes, and outbound requests to the attacker infrastructure. Rebuild affected environments from trusted sources, rotate any credentials exposed on those systems, and add detections for the package name and its indicators of compromise.

Technical breakdown

How a preinstall hook becomes a supply chain entry point

npm lifecycle scripts such as preinstall execute automatically during package installation. That means a package can run code before an application is even built or started, which creates an execution path inside developer workstations, CI jobs, and deployment runners. If those environments hold authenticated sessions, cached browser passwords, local config files, or cloud credentials, the package can harvest them immediately. The risk is not limited to the package registry itself. It is the trust boundary around install-time execution and the broad file and environment access granted to that process.

Practical implication: Treat install-time scripts as an execution boundary and restrict them in build and developer environments where credentials are present.

Why stolen NHI secrets create cross-environment blast radius

The article shows the malware targeted AWS access keys, GitHub tokens, Kubernetes config, Vault tokens, .npmrc files, SSH private keys, and browser-stored passwords. That is a classic NHI compromise pattern because the stolen material is not one account, but a portable set of reusable secrets that can unlock multiple services. Once exfiltrated, those credentials can be used for cloud access, code repository access, cluster access, and secret store access without further user interaction. The impact depends on whether the credentials are long-lived, broadly scoped, and shared across environments.

Practical implication: Reduce blast radius by separating secret scopes, shortening lifetime, and removing reusable credentials from install paths.

Why token monitoring can extend the attacker timeline

The malware reportedly spawned a background service that checked whether the stolen GitHub token remained valid and, if it had been rotated, could delete files on the infected host. That behaviour matters because it turns a one-time compromise into a monitored persistence pattern. The attacker is not just stealing secrets, but also detecting response activity and attempting to punish remediation. This is a governance failure as much as a malware detail, because token revocation must be paired with containment of the infected endpoint or runner.

Practical implication: Assume credential rotation alone may trigger hostile response logic and isolate the host before revoking exposed tokens.

Threat narrative

Attacker objective: The attacker aimed to collect reusable cloud and developer credentials from build or workstation environments and preserve access long enough to expand compromise or disrupt response.

1. Entry occurred when malicious code was injected into the tensorlake npm package and executed through the preinstall hook during package installation.
2. Credential harvesting followed as the malware stole AWS, GitHub, Kubernetes, Vault, SSH, and browser-stored secrets from the infected environment.
3. Impact emerged through exfiltration of the stolen credentials and the malware's ability to react to token rotation by deleting files on the host.

Breaches seen in the wild

• Rspack npm compromise 2024: A compromised npm token let an attacker publish Rspack 1.1.7 with a postinstall cryptominer that also sent cloud credentials out.
• Solana web3.js npm compromise 2024: A phished maintainer's npm access let attackers publish two @solana/web3.js versions that stole private keys from bots and apps.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Install-time execution is the real trust failure: package managers are often treated as distribution channels, but this case shows they are also runtime execution channels. Once preinstall scripts are permitted, the package author can reach whatever secrets the host can read. For identity teams, that means software supply chain policy and secret exposure policy are the same control problem from a governance standpoint.

Browser-stored passwords and local config files are now shared attack surface: the malware did not need a novel exploit chain if it could read credentials already present on the machine. That collapses the separation between developer convenience and enterprise identity security. Practitioners should treat local password stores, .npmrc files, SSH keys, and cloud session tokens as high-value NHI assets, not incidental artifacts.

Credential rotation without host containment is incomplete response: the article's note about file deletion after token invalidation shows why response sequencing matters. Revoking a GitHub token can be the trigger that reveals hostile logic on the host, so containment, evidence preservation, and credential revocation need to be coordinated. The practitioner lesson is to align incident response with the behaviour of the malware, not only with the existence of the exposed secret.

Software supply chain attacks are increasingly identity attacks: this incident is not just about code integrity, but about identity material embedded in environments where code is executed. That is where NHI governance becomes relevant. The same controls that govern secret discovery, workload identity scope, and short-lived access also reduce the damage from malicious packages. The field needs to treat install-time secret access as a core identity security issue, not a side effect.

Standing secrets create a predictable compromise window: the attacker did not need to wait for interactive abuse when the environment already contained long-lived credentials. That is the governance assumption this breach breaks. If a build or developer host can read persistent tokens, the compromise window starts at execution and persists until every exposed credential is invalidated and the host is cleaned. Practitioners should treat standing secrets as the fault line, not the package itself.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.

What this signals

Standing secrets turn software installs into identity events: when a package can read long-lived tokens from a runner or workstation, the compromise is no longer confined to code integrity. It becomes a credential governance problem, and the response has to focus on where secrets are stored, how long they live, and whether install paths can reach them.

Supply chain security and NHI governance now overlap directly: teams that manage GitHub tokens, cloud keys, Kubernetes credentials, and vault-issued secrets need to assume third-party code may encounter them during routine installs. According to the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

Credential rotation must be paired with environment isolation: once malicious code has executed on a host, revoking tokens is necessary but not sufficient if the same machine can still read new secrets or trigger destructive behaviour. Practitioners should align revocation, backup, host isolation, and secret re-issuance as one sequence rather than separate tasks.

For practitioners

• Restrict package install-time script execution Block or review lifecycle scripts such as preinstall in build and workstation environments that can access secrets. Where blocking is not possible, run installs in isolated sandboxes with no cloud tokens, repo tokens, or secret-store access.
• Separate developer secrets from install paths Keep AWS keys, GitHub tokens, Kubernetes configs, Vault tokens, SSH keys, and browser password stores off hosts that routinely execute third-party code. Use scoped, short-lived credentials for any workflow that must touch external packages.
• Revoke exposed credentials in a defined sequence Back up affected systems, isolate the host, stop any persistence service, then rotate tokens and keys that may have been accessible during installation. Preserve evidence before revocation if the malware may react to invalidation.
• Hunt for package-driven credential access Review endpoint, CI, and cloud logs for unusual reads of .npmrc, .env, cloud credential files, browser profile data, and secret-store interactions shortly after npm install activity. Correlate that activity with outbound connections to suspicious domains.
• Treat npm trusted paths as identity-sensitive Apply the same control thinking to package execution that you use for privileged identity workflows: minimal access, narrow scopes, and rapid revocation when compromise is suspected. Package trust is part of the credential lifecycle.

Key takeaways

• This incident shows that a malicious package can convert a routine npm install into a multi-identity compromise affecting cloud, source control, and secret-store access.
• The practical scale comes from credential reuse and local secret exposure, not just from the package itself.
• The limiting control is not only faster token rotation but also denying install-time code access to reusable secrets and isolating the affected host.

Key terms

• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• Credential exfiltration: Credential exfiltration is the theft of usable authentication material such as tokens, keys, or certificates. In NHI environments, the stolen item is often already valid and can be replayed immediately. That is why detection must be paired with revocation and entitlement review rather than relying on alerts alone.
• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• NHI Blast Radius: NHI blast radius is the amount of damage a compromised machine identity can cause before it is contained. It includes unauthorized access, data exposure, AI misuse, and spend impact. Reducing blast radius means limiting permissions, shortening credential lifetime, and monitoring for unusual behaviour at runtime.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to real-world operational risk.