Typosquatted npm packages expose CI/CD token abuse in GitHub Actions

At a glance

What this is: A malicious npm typosquat targeted GitHub Actions builds to steal environment tokens and enable follow-on abuse of trusted publishing paths.

Why it matters: This matters because CI/CD dependencies can become credential-extraction points, and IAM teams must treat build-time tokens as high-value identities with strict scope and lifecycle controls.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Veracode's analysis of the malicious npm package targeting GitHub Actions

Context

Typosquatted packages exploit a basic governance gap: build systems often trust package installation paths before they have enough context to decide whether the dependency is legitimate. In CI/CD, that matters because installation-time code can run with access to environment secrets, repository tokens, and publishing permissions. This article is about supply chain abuse, but it also exposes an identity problem because build tokens behave like non-human identities inside the pipeline.

GitHub Actions is a particularly sensitive control plane because package installs, workflow execution, and release publishing can all share the same trust boundary. When an attacker can turn a dependency into a post-install execution path, the issue is not just malware delivery. It is standing access to ephemeral but highly privileged machine credentials, which is why this pattern sits at the intersection of software supply chain risk and NHI governance.

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 CI/CD tokens increase supply chain risk when they are over-scoped?

A: Because they behave like machine identities with real authority. If the same token can build, access secrets, and publish artifacts, one compromised dependency can turn a single installation into lateral movement across release and deployment paths. Narrow scoping, per-job issuance, and explicit separation of duties reduce that blast radius substantially.

Q: How do teams know whether pipeline identity controls are actually working?

A: Look for evidence that credentials cannot be reused outside the intended job, that install-time scripts are blocked or heavily constrained, and that publish actions require separate approval. If a malicious dependency can still reach secrets or release systems, the control model is failing even if the token expires quickly.

Q: Who is accountable when a build token is used to publish malicious artefacts?

A: Accountability sits with the organisation operating the pipeline, because the token design, workflow permissions, and dependency controls define the trust boundary. Security, platform engineering, and IAM owners should share responsibility for scoping, review, and monitoring. Regulatory expectations typically map to secure configuration, access control, and auditability rather than vendor blame.

Technical breakdown

How typosquatted npm packages weaponise install time

Typosquatting works by registering a package name that is visually close to a legitimate dependency, then waiting for automated installs to pull it into a build. In this case the malicious package used a post-install hook, which means code executed during installation rather than at runtime. That matters because build systems often grant install steps broad access to files, environment variables, and network egress. The attack does not need to compromise the repository first. It only needs a trusted pipeline to ingest the package and execute it inside the build context.

Practical implication: lock dependency sources, review install scripts, and block untrusted post-install execution in CI pipelines.

Why CI tokens behave like high-value non-human identities

The malware specifically searched for GITHUB_ variables and targeted repositories owned by GitHub, showing that build-time credentials are not generic secrets but scoped identities with operational meaning. In modern pipelines, those tokens can authenticate publish steps, access artefact stores, or reach internal services. If they are over-scoped, short-lived only in theory, or reused across jobs, a malicious dependency can convert a single package install into downstream privilege abuse. This is a classic NHI governance problem disguised as supply chain malware.

Practical implication: classify build tokens as NHIs, scope them to single jobs, and separate read, build, and publish privileges.

How exfiltration and follow-on publishing create supply chain persistence

The observed malware did more than steal data. It encrypted captured information, sent it out to a remote endpoint, and attempted to preserve access to a publishing path by abusing the credentials it found. That combination raises the blast radius from one compromised build to repeated malicious package publication or repository impersonation. When pipeline credentials can be reused to publish artifacts, compromise becomes a distribution mechanism, not a one-off theft event. This is why software supply chain security and identity governance converge in CI/CD.

Practical implication: separate build credentials from publish credentials and require explicit approval for artifact release actions.

Threat narrative

Attacker objective: The attacker wanted to steal GitHub Actions tokens and use them to publish malicious artifacts or deepen access to targeted repositories.

1. Entry occurred through a typosquatted npm package that mimicked a legitimate GitHub Actions dependency and was pulled during installation.
2. Credential access followed when the post-install hook searched for GitHub Actions environment variables and captured build tokens from the pipeline context.
3. Impact emerged as the malware exfiltrated encrypted data and attempted to reuse the stolen credentials for follow-on malicious publishing and repository abuse.

NHI Mgmt Group analysis

Typosquatted packages are now a credential-extraction problem, not just a malware problem. The important shift in this case is that installation-time code execution intersected directly with environment secrets and repository permissions. That means software supply chain controls and identity governance now overlap at the exact point where pipelines trust dependencies. Practitioners should treat package ingestion as an access decision, not merely a build step.

Build tokens are non-human identities with an exposure window that may be shorter than human review cycles. When a pipeline token can authenticate publishing, repository access, or internal service calls, it behaves like a machine identity and should be governed that way. The governance gap is not token existence alone, but token scope, reuse, and the absence of job-specific boundaries. IAM and PAM teams should therefore bring CI/CD credentials into the same entitlement discipline they apply to service accounts and privileged automation.

Software supply chain failures increasingly exploit the trust fabric around identity, not only code integrity. A malicious dependency can succeed because the environment grants it authenticated access before detection occurs. That turns dependency hygiene into a control-plane issue for NIST CSF, NIST SP 800-53, and OWASP NHI-adjacent governance. The practitioner conclusion is clear: identity-aware supply chain controls are now part of baseline resilience.

Ephemeral access is only protective if the privilege model is actually narrow. Short-lived tokens reduce persistence, but they do not help if the token can still publish artifacts, enumerate secrets, or reach internal systems during execution. This article reinforces a named concept we call the pipeline trust gap: the period where an automated build is trusted to run code before the organisation has established whether that code should have any authority at all. Teams should close that gap with explicit policy, not hope.

Targeted attacks on CI/CD show that machine identities can be selected, profiled, and abused like any other attack surface. The package logic inspected repository ownership and only activated for the intended target, which shows attacker selectivity rather than blind spraying. That is the same strategic pattern seen in broader NHI abuse: discover the right identity, abuse its privileges, and pivot through trusted automation. The practitioner takeaway is to govern build identities as first-class assets, not auxiliary technical detail.

What this signals

Pipeline trust gap: CI/CD governance now has to separate code provenance from execution authority. If build-time code can read secrets and reach publish systems, the organisation has granted a transient but powerful identity an access path that traditional software controls often leave implicit. Mapping those credentials to NIST SP 800-53 Rev 5 Security and Privacy Controls helps teams anchor that boundary in access control and audit requirements.

The next maturity step is to treat build identities as part of the wider non-human identity estate, not as engineering implementation detail. That means inventorying workflow tokens, constraining their use to single jobs, and checking whether package execution paths can still access sensitive artefacts or release functions. Where development pipelines support MITRE ATLAS adversarial AI threat matrix style red teaming for automation, similar thinking should be applied to supply chain trust paths and token abuse.

For readers building remediation plans, the priority is to align dependency trust, secrets handling, and publishing permissions into one operating model. If any of those are governed separately, the attacker only needs one weak boundary to turn a package install into a supply chain event. The lesson scales beyond npm: wherever a machine identity can execute code and reach secrets, the control model has to assume hostile inputs.

For practitioners

• Block install-time execution in high-trust pipelines Disable or tightly control post-install hooks for packages used in CI/CD, especially where workflows can reach secrets, artefact registries, or publish permissions. Add allowlists for package sources and fail closed on unexpected lifecycle scripts.
• Treat CI tokens as scoped non-human identities Assign each workflow its own token, restrict permissions to the minimum job boundary, and separate read, build, and publish actions. Remove any token that can authenticate across multiple environments or release steps.
• Audit dependency trust before build execution Require dependency provenance checks, signed artefacts where available, and policy gates before a new npm package can run in a protected repository. Use explicit approval for packages that introduce new lifecycle scripts.
• Monitor for unusual artifact publication paths Watch for workflow tokens used outside their expected repository, especially publish requests that originate from install-time code or from repositories that should only consume packages. Correlate package installs with downstream release activity.

Key takeaways

• Typosquatted packages can convert dependency installs into credential theft events when CI/CD trust boundaries are too broad.
• Build tokens behave like non-human identities, so scoping, separation of duties, and job-level boundaries matter more than token expiry alone.
• Practical defence starts by blocking install-time execution paths, separating publish privileges, and auditing dependency provenance before code runs.

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.
• 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.
• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• Pipeline Trust Gap: The mismatch between the trust a build or release system is given and the level of identity governance it actually receives. It appears when CI/CD accounts, signing identities, and automation tokens can change production outcomes without the monitoring, scope limits, or lifecycle controls usually reserved for privileged access.

What's in the full article

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

• The exact malicious package names, versions, and indicators of compromise used to detect or block the campaign.
• The post-install hook and obfuscated script behaviour that showed how the malware executed inside the build.
• The full exfiltration path and malware artefacts that reveal how the attacker handled captured environment data.
• The package firewall and triage actions used to prevent download or execution in protected environments.

👉 Veracode's full post covers the package behaviour, exfiltration path, and indicators of compromise.

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 helps security and identity practitioners translate identity controls into operational policy across modern automation estates.