Typosquatted npm packages exposed cloud and CI/CD secrets

At a glance

What this is: Typosquatted npm packages were used to execute install-time payloads that hunted for cloud, vault, and CI/CD secrets across developer and runner environments.

Why it matters: IAM, PAM, NHI, and DevSecOps teams need to treat dependency installation as a credential exposure point, because the attack targeted secrets and publishing tokens before application execution.

By the numbers:

• Corgea says 14 malicious packages were published within roughly four hours by a newly created maintainer account.

Context

Typosquatted packages are malicious dependencies that imitate legitimate tooling closely enough to pass early trust checks and run before application code starts. In this case, the risk sits in the install boundary, where package lifecycle hooks can execute with the same reach as the developer or CI runner that invoked them.

The identity angle is direct: the payload sought cloud access keys, vault tokens, GitHub Actions context, and npm publish tokens. That makes this a non-human identity and secrets governance problem as much as a software supply-chain issue, because compromised build identities can be reused for lateral movement and follow-on package compromise.

The article also shows why name similarity is only the entry point. The operational risk comes from trusted automation, cached credentials, and the assumption that dependency install is a passive step rather than an execution path.

Key questions

Q: What breaks when npm package installation is allowed to execute lifecycle scripts by default?

A: A malicious dependency can run code before installation completes, which turns normal package resolution into a payload delivery mechanism. That breaks the assumption that package trust equals install safety. Teams need to treat lifecycle execution as a privilege boundary and restrict scripts that are not essential to the build.

Q: Why do cloud and CI/CD secrets make typosquatted packages more dangerous?

A: Because the attacker does not need to break production directly if the install context already contains reusable credentials. Cloud sessions, Vault tokens, and publishing tokens can be used to move from a single compromised workstation or runner into control-plane access, secret stores, or package registries. The risk comes from credential reach, not package presence alone.

Q: How can security teams tell whether dependency installation is exposing secrets?

A: Look for install-time processes that touch metadata services, cloud APIs, secret managers, or registry endpoints before the application starts. Suspicious signs include npm or node processes invoking preinstall or postinstall hooks, unexpected outbound requests, and credential enumeration from environments that should only fetch code. Those signals indicate the install boundary is leaking trust.

Q: What should teams do after a malicious npm package has run in CI/CD?

A: Contain the build environment, assume secrets on that system are exposed, and rebuild from a known-good baseline before restoring access. Then rotate npm tokens, cloud keys, SSH keys, and pipeline secrets that were reachable from the compromised host. The goal is to remove attacker persistence before any cleanup can be trusted.

Technical breakdown

Why npm lifecycle hooks turn installs into execution

npm lifecycle hooks such as preinstall, install, and postinstall let package code run automatically during dependency setup. Attackers abuse that feature by placing a local stager in the tarball so the payload executes before tests, imports, or runtime controls ever see the module. In this campaign, the malicious package collected host context, sent it out, and then launched a second stage. The key architectural issue is that package provenance and package execution are separated: a reviewer may inspect metadata or repository links, but npm still runs code from the installed artifact. Practical implication: treat dependency installation as an execution boundary, not a file-copy operation.

Practical implication: Block lifecycle scripts by default where possible, and separately approve packages that require them.

How install-time payloads harvest cloud and CI/CD secrets

The payload was designed to find the credentials already present on the machine, not to break the target system directly. It checked cloud metadata endpoints, environment variables, Vault tokens, GitHub Actions context, and npm publishing data, then used those secrets for further access. That pattern is dangerous because developer laptops and CI runners often hold valid sessions with more privilege than production services. Once the attacker has a token or assumed role, they can move laterally into cloud control planes, secret stores, or package registries. Practical implication: the real control surface is the session, token, and runner context, not just the codebase.

Practical implication: Inventory secrets on build hosts and rotate exposed cloud, vault, and publishing credentials after any suspicious install.

Why trusted repository metadata can hide a malicious tarball

The campaign also abused trust transfer. Some packages spoofed repository metadata back to a legitimate OpenSearch client project, which can reassure reviewers even when npm is installing an attacker-published archive. In the later generation, the loader could also fetch a legitimate Bun release to make the activity look like normal tooling behaviour. That means defenders cannot rely on repository URLs, package names, or a single suspicious network event as the only signal. Practical implication: provenance checks, lockfile hygiene, and script execution controls matter more than visual similarity in package naming.

Practical implication: Verify package provenance and restrict install scripts on developer and release environments.

Threat narrative

Attacker objective: Steal reusable cloud and publishing credentials so compromised developer or CI environments can be turned into broader package and control-plane compromise paths.

1. Entry occurred when users installed typosquatted npm packages that impersonated OpenSearch, Elastic, DevOps, and configuration tooling.
2. Credential access followed as the install-time stager harvested AWS, Vault, GitHub Actions, and npm publishing secrets from the host environment.
3. Escalation was possible when stolen npm tokens or cloud sessions could be reused for lateral movement or a second-stage package compromise.
4. Impact was exposure of cloud control-plane access and CI/CD publishing rights, with the potential for downstream supply-chain abuse.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 supply-chain boundary: the security model for npm cannot stop at package integrity or reputation. Once lifecycle hooks are allowed to run automatically, dependency installation becomes an execution event with direct credential exposure potential. Practitioners should treat script execution as a governed privilege, not a default convenience.

Cloud sessions and publishing tokens are non-human identities in practice: the campaign targeted the credentials that let machines and automation act on behalf of the organisation. That means NHI governance, secrets lifecycle control, and CI runner hardening are now part of supply-chain defence, not separate disciplines. The practical lesson is to reduce the reach of any token that can survive a compromised install.

Package name similarity is a detection problem, but trust transfer is the governance failure: the malicious packages did more than impersonate tools, they borrowed legitimacy through metadata, repository references, and familiar build workflows. That creates a trust gap between what reviewers see and what the installer executes. Teams should focus on provenance enforcement and script restrictions, not just typo detection.

Dependency installs need blast-radius control: this campaign shows that the highest-value control is limiting what secrets are available to a runner or workstation at install time. If the environment can reach AWS, Vault, GitHub, and npm with standing access, a single malicious package becomes a multi-system event. Practitioners should narrow credential scope before they rely on package hygiene alone.

Secret sprawl remains the enabling condition: the packages succeeded because valuable credentials were reachable in the places developers and CI systems already work. That is the same failure mode secrets management programmes have been trying to close for years, but supply-chain attacks make the cost of partial coverage more visible. The decision point is whether secret access is still broader than the install context requires.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• Read next: Secrets Management Buyer's Guide

What this signals

Secret sprawl and install-time execution now intersect: the important failure is not whether a package is typed incorrectly, but whether the environment that installs it can also reach cloud, vault, and registry credentials. That is why dependency review has to be paired with secrets minimisation on build hosts. Use the Secret Sprawl Challenge as a lens for reducing the number of credentials exposed to installers.

Install-time control is the new provenance control: a package can look familiar, reference a legitimate repository, and still execute as an attacker-controlled tarball. The practical response is to make install scripts, lockfiles, and runner permissions part of the same governance conversation, because package trust without runtime restraint is incomplete.

The campaign also reinforces a familiar NHI lesson: standing access on developer machines and CI runners enlarges the blast radius of any supply-chain compromise. If those identities can authenticate to cloud control planes, secret stores, and package registries, a single malicious dependency can become a multi-system incident.

For practitioners

• Restrict lifecycle script execution Disable npm lifecycle hooks by default in environments that do not explicitly require them, and separate package acquisition from package execution in CI and on build hosts.
• Rotate exposed cloud and publishing credentials Revoke and replace AWS sessions, Vault tokens, GitHub Actions secrets, and npm publish tokens on any workstation or runner that installed the affected packages.
• Audit dependency provenance and lockfiles Search manifests and lockfiles for typosquatted names, unexpected repository URLs, and unapproved package updates, then rebuild from a trusted base image.
• Harden build runners against secret reuse Remove long-lived credentials from developer laptops and CI runners, and scope any remaining access so install-time code cannot enumerate cloud or registry secrets.

Key takeaways

• Typosquatted packages are dangerous because they turn the dependency installation step into a credential theft opportunity, not just a malware delivery path.
• The campaign targeted cloud, vault, and CI/CD secrets, which means the real exposure was reusable identity material that could support later compromise.
• Restricting lifecycle scripts, reducing secret reach on build hosts, and rotating exposed tokens are the controls that most directly shrink the blast radius.

Key terms

• Typosquat Package: A typosquat package is a malicious or misleading package name designed to resemble a legitimate dependency. Attackers rely on typing mistakes, autocomplete, or familiarity to get developers to install it, then use the trusted package manager path to deliver payloads or steal data.
• Lifecycle Hook: A lifecycle hook is code that runs automatically at defined stages of package installation or build processing, such as preinstall or postinstall. These hooks are powerful because they can execute before deeper inspection or controls are applied, making them a common abuse path in supply chain attacks.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Build-Host Secret Exposure: The condition where developer workstations or CI runners can reach cloud keys, vault tokens, or registry credentials needed for automation. It becomes a security problem when those secrets are present during dependency installation, because malicious packages can harvest them before any runtime control is applied.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the build and automation systems that attackers target.