Typosquatted npm packages exposed cloud and CI/CD secrets

At a glance

What this is: This is an analysis of a May 2026 npm supply-chain campaign where typosquatted packages ran at install time and attempted to steal cloud, Vault, GitHub Actions, and npm publishing secrets.

Why it matters: It matters because dependency installation can expose NHI credentials and release-pipeline privileges before application code ever runs, which changes how IAM, PAM, and secrets governance must be applied to developer and CI environments.

By the numbers:

• Only 44% of organisations are currently using a dedicated secrets management system.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Corgea's analysis of the npm supply-chain campaign targeting cloud and CI/CD secrets

Context

npm dependency installs are often treated as a build-time convenience step, but this campaign shows they can become an identity exposure point. When malicious packages execute during installation, they can reach cloud metadata, Vault tokens, and publishing credentials before application tests or runtime controls begin.

The primary governance problem is that developer laptops and CI/CD runners frequently hold high-value non-human identities in places that are easy to overlook, including shell profiles, pipeline variables, and package-manager tokens. In practice, that makes install-time execution a secrets boundary, not just a software integrity issue.

The package names in this case were chosen to blend into search and observability tooling workflows, which is a familiar pattern in supply-chain abuse. That starting position is typical for modern npm campaigns, but the second-stage focus on cloud and release credentials raises the impact beyond simple typosquatting.

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: What breaks when supply-chain poisoning reaches developer workstations and CI runners?

A: The main failure is assuming a compromised package only affects one project. In practice, developer hosts and CI runners often hold cloud tokens, source access, and signing credentials, so a poisoned dependency can become a broader trust-breach across repositories and deployment paths. Once that happens, traditional package scanning is no longer enough on its own.

Q: What do security teams get wrong about typosquatted packages?

A: They focus on the package name and miss the second-stage objective. In this pattern, the lure is only the delivery channel. The real goal is secret harvesting from metadata services, CI variables, and publishing workflows, which is why provenance, token scope, and install-time execution controls matter more than name similarity alone.

Q: Who is accountable when install-time malware exposes cloud or publishing secrets?

A: Accountability sits with the teams that own build trust, secrets lifecycle, and release access. If a runner can install untrusted code and reach high-value credentials, the governance gap is shared across platform engineering, IAM, and security operations. Frameworks such as NIST CSF and OWASP NHI both point to that overlap.

Technical breakdown

Install-time execution turns package installation into an attack boundary

Modern npm packages can execute lifecycle hooks such as preinstall, install, and postinstall before any application code imports them. That matters because the package manager, not the application, becomes the execution context. In this case, the malicious path used lifecycle scripts to launch a local stager, collect host details, and then trigger a second stage. The important architectural point is that code review of imported modules is too late if the package already executed during dependency resolution. Practical implication: treat dependency installation as an executable trust boundary and restrict lifecycle hooks wherever possible.

Practical implication: Disable unnecessary lifecycle execution in CI and require controlled installs for packages that do not need build-time hooks.

Credential harvesters target cloud metadata, Vault, and release tokens

The payload focused on high-value secrets sources rather than end-user data. Cloud metadata endpoints can expose temporary credentials, while Vault tokens and npm or GitHub Actions secrets can grant broader operational access. That combination is especially dangerous because it links local developer compromise to cloud control planes and software publishing pipelines. Once a token is harvested, the attacker can often pivot from one machine to multiple environments without reusing the same malware. Practical implication: credential scope and token lifetime matter more than endpoint cleanliness when install-time malware is in play.

Practical implication: Limit token scope, shorten credential lifetime, and separate development, build, and publishing identities.

Trust transfer in supply-chain attacks hides malicious tarballs behind familiar metadata

One tactic in the campaign was to spoof package.json metadata so that the package appeared to originate from a familiar upstream repository. That is a trust-transfer technique, where the attacker borrows the credibility of a known project while delivering attacker-controlled code. Reviewers may see the expected repository URL and assume the package is legitimate, even though npm is installing a different artifact. This is not just social engineering, it is a supply-chain integrity failure at the package metadata layer. Practical implication: validate provenance, not just package names and repository links, before allowing release or build-time installs.

Practical implication: Require provenance checks and signed artefacts for packages used in build and publishing workflows.

Threat narrative

Attacker objective: The attacker aims to steal high-value cloud and publishing credentials that can be reused to compromise infrastructure, release pipelines, and additional packages.

1. Entry occurs when a developer workstation or CI/CD runner installs one of the typosquatted npm packages and the lifecycle hook executes automatically.
2. Credential access follows when the stager harvests AWS credentials, Vault tokens, GitHub Actions context, and npm publish secrets from the host environment.
3. Escalation occurs when stolen publishing credentials or cloud tokens are reused to move into trusted automation, cloud control planes, or additional package compromise.
4. Impact is the exposure of cloud sessions and release-pipeline identities that can be used for lateral movement, further supply-chain compromise, or secret theft at scale.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Install-time execution is now a governance problem, not just a build problem. The campaign shows that dependency installation can execute code before tests, runtime protections, or application controls are relevant. That shifts the control question to package-manager policy, runner hardening, and lifecycle-hook governance. In identity terms, the risk sits at the point where NHI secrets are present on a build host and an untrusted package can reach them. Practitioners should treat install-time execution as a formal trust boundary.

Secrets exposed to developer tooling behave like standing non-human privilege. If cloud keys, Vault tokens, or publishing credentials are present in shell profiles or CI variables, they are effectively persistent access paths waiting to be harvested. That is a classic NHI governance gap, but it is amplified in software delivery because the same identity may exist across laptops, runners, and release automation. The control failure is not the secret alone, it is the absence of lifecycle scoping and offboarding discipline. Practitioners should collapse long-lived tooling secrets into short-lived, task-scoped access.

Trust-transfer attacks exploit metadata confidence, not just package names. Spoofed repository URLs and familiar package themes reduce reviewer suspicion even when the tarball is attacker-published. This is a useful named concept: metadata trust transfer, where legitimate project signals are copied to disguise malicious artefacts. For identity teams, the lesson is that provenance must extend beyond human trust cues to enforceable validation. Practitioners should require artifact provenance checks before build and release consumption.

Cloud and release identities need separate blast-radius boundaries. The package payload targeted AWS, Vault, GitHub Actions, and npm publishing workflows in one chain, which means a single local compromise can cross multiple identity domains. That makes shared credentials and over-broad token reuse especially dangerous. The broader market signal is that secrets management, workload identity, and developer platform controls are converging around the same problem: limiting what an attacker can do with one stolen token. Practitioners should separate build, publish, and cloud access paths.

Supply-chain malware is increasingly an identity theft problem first. The immediate aim is not always code corruption. In many cases, the attacker wants credentials that can be replayed against cloud APIs, package registries, or CI systems. That means the most effective controls are the ones that reduce credential value after theft, including short token lifetimes, scoped permissions, and strong revocation. Practitioners should measure success by how quickly stolen secrets become useless, not by how rarely malware appears.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• From our research: 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be critical than code-based leaks, according to The State of Secrets Sprawl 2026.
• Forward look: The 2024 State of Secrets Management Survey shows only 44% of organisations use a dedicated secrets management system, which helps explain why exposure windows remain so wide.

What this signals

Install-time malware is a reminder that secret governance has to start before the application runtime. When package managers can execute code and runners hold cloud identities, the practical control point is the build pipeline itself, not only the production environment. That is where NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 become operationally relevant.

Metadata trust transfer: attackers can now copy the appearance of legitimate repositories and package families to lower suspicion while the real target is credential theft. That means provenance validation, token scoping, and revocation speed have to be measured together. If stolen secrets remain valid for hours or days, the attacker has already won the race to reuse them.

For identity and platform teams, the next escalation is not better malware detection alone. It is deciding which secrets are allowed to exist on developer hosts, which identities can touch release tooling, and which lifecycle events trigger automatic revocation. That is the practical intersection between NHI governance and software supply-chain security.

For practitioners

• Block lifecycle hooks where they are not required Set install policies so npm lifecycle scripts do not run by default in CI and on build hosts unless the package is explicitly approved for trusted execution. This reduces the chance that a malicious preinstall or postinstall hook can harvest secrets before the build even starts.
• Separate build, publish, and cloud identities Use distinct credentials for development, CI build, package publishing, and cloud administration. Keep npm publish tokens, AWS access, and Vault access out of shared environment variables so compromise of one runner does not expose every control plane at once.
• Shorten the lifetime of all exposed secrets Replace durable credentials with short-lived tokens where possible, especially for AWS sessions, Vault authentication, and release automation. Pair that with automatic revocation so a stolen token stops being useful within minutes rather than days.
• Audit for affected package installs and cache contamination Search lockfiles, package caches, and runner histories for the reported package names, then rebuild from a trusted base image if any exposure is found. Treat install, build, cache restore, and artifact creation as potential exposure events, not just production deployment.
• Validate provenance before release-builder installs Require provenance checks for packages consumed by release automation and enforce allowlisting for tools that can publish to registries or touch cloud control planes. Familiar metadata is not enough when attacker-published tarballs can mirror trusted repository details.

Key takeaways

• Typosquatted npm packages are a secrets problem as much as a supply-chain problem, because install-time execution can reach cloud and release credentials before application controls apply.
• The campaign’s impact depends on credential value and lifetime, which is why short-lived tokens and rapid revocation matter more than detection alone.
• Build, publish, and cloud identities should be separated so a single malicious dependency cannot pivot into multiple control planes.

Key terms

• 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.
• Metadata Trust Transfer: A deception pattern where malicious software borrows the appearance of a trusted upstream project by copying repository URLs, names, or package metadata. The attacker uses that familiar surface to reduce suspicion while delivering attacker-controlled code and credential theft logic.
• Release-Pipeline Identity: The credentials, tokens, and service accounts that allow software to be built, signed, published, or deployed. These identities are high-value because compromise can turn a local developer or CI event into access to registries, cloud environments, and downstream customers.
• Secrets Boundary: The point in a workflow where credentials are present and can be exposed, stolen, or reused. In modern software delivery, the secrets boundary often sits in developer tooling, CI runners, and package-install steps rather than only in production systems.

What's in the full analysis

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact package names, version list, and install-time indicators that help teams confirm exposure in lockfiles, caches, and runner histories.
• The lifecycle-hook and stager sequence that shows how the malicious code executed before application tests began.
• The specific AWS, Vault, GitHub Actions, and npm token targets that matter when you are mapping blast radius across development and release systems.
• The remediation checklist for rotating exposed credentials, rebuilding trusted runners, and blocking the observed campaign infrastructure.

👉 Corgea's full post covers the package list, execution chain, and remediation steps in more operational detail.

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 for teams that need operational clarity. It helps security and platform practitioners connect identity controls to build, release, and runtime risk.