TL;DR: A typosquatted npm package mimicking @actions/artifact used a post-install hook, targeted GitHub-owned repositories, and attempted to exfiltrate build tokens for follow-on malicious publishing, according to Veracode Threat Research. The case shows that supply chain integrity and token scoping now matter as much as malware detection.
At a glance
What this is: This is a supply chain attack analysis showing how a typosquatted npm package abused GitHub Actions build trust to try to steal CI/CD tokens and republish malicious artifacts.
Why it matters: It matters because CI pipelines often hold high-value automation tokens, and identity scoping, package provenance, and build isolation all determine how far a compromised dependency can reach.
Context
Typosquatting in package registries is a simple but effective way to exploit build-time trust. The danger is not just malware execution, but the way CI/CD environments often expose tokens, repository context, and publishing permissions to code that has not been reviewed as a trusted workload.
In this case, the identity angle is direct: build jobs, package maintainers, and automation tokens behave like non-human identities with delegated authority. When a malicious dependency can execute during installation, the control failure is usually not endpoint detection alone but weak provenance, overbroad token scope, and insufficient separation between build and release trust boundaries.
The reported targeting of GitHub-owned repositories makes this a focused abuse of CI/CD identity assumptions rather than a generic malware event. That is a typical pattern for supply chain attacks that seek to pivot from package installation into credential theft and downstream artifact abuse.
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 standing CI/CD tokens create so much risk in supply chain attacks?
A: Standing tokens remain usable long after the moment they were created, so a compromise can persist through normal operations and even through partial remediation. In supply chain environments, that means one stolen token can be reused to push artefacts, alter tags, or seed downstream packages. Short-lived access and verifiable revocation are the controls that reduce that exposure.
Q: What do security teams get wrong about dependency scanning?
A: They often assume a clean manifest means a clean environment. In reality, package managers can resolve transitive code dynamically and execute scripts during installation. A scan can confirm what should have been installed, but it cannot prove what actually ran or what secrets the code reached.
Q: How should security teams reduce risk from compromised GitHub Actions workflows?
A: Security teams should treat workflows as privileged non-human identities. The practical fix is to inventory every secret and role a workflow can reach, shorten credential lifetimes, pin external actions to commit hashes, and monitor runtime behaviour for anomalies. If the workflow can deploy, read secrets, or call cloud APIs, it needs identity-level controls, not just code review.
Technical breakdown
How typosquatted packages reach build-time trust
Typosquatted packages imitate legitimate dependency names so they are selected by humans or automation during installation. In npm and similar ecosystems, this can be enough to place attacker-controlled code into a build pipeline before application testing or release checks occur. A post-install hook is especially dangerous because it runs automatically after package installation, often with access to the build environment, repository metadata, and ephemeral credentials. The key technical issue is that the package manager treats installation as execution, not just retrieval, so provenance and namespace control matter as much as malware scanning.
Practical implication: treat dependency selection as a control point and enforce provenance checks before installation.
Why CI/CD tokens are high-value non-human identities
Build and release systems commonly use tokens, service accounts, and other non-human identities to authenticate to source control, artifact stores, and cloud services. If those credentials are exposed to a dependency during a build, the attacker may inherit the pipeline's delegated authority rather than a human user's access. That makes token scope, short lifetime, and separation of duties central controls. The article's example shows how a malicious package can read environment variables, harvest build context, and then use those credentials for follow-on publishing or repository abuse.
Practical implication: narrow CI/CD token scope and remove publish permissions from ordinary build jobs.
What post-install hooks change in supply chain risk
A post-install hook turns a package install into executable code delivery, which expands the blast radius of dependency compromise. Instead of waiting for an application to start, the malware can run during the build itself and access secrets that never reach runtime. This is why package integrity, sandboxing, and artifact verification are essential across CI/CD. The article also shows how attackers may add time-based triggers or obfuscation to delay detection, which reduces the value of only scanning the final artifact after installation has already occurred.
Practical implication: isolate package execution in controlled build stages and verify artifacts before they can influence release outputs.
Threat narrative
Attacker objective: The attacker appears to have wanted build-system tokens that could be reused to publish malicious packages and abuse GitHub-owned repositories.
- Entry occurred through a typosquatted npm package, @acitons/artifact, that closely mimicked a legitimate GitHub Actions dependency and was likely chosen during normal build or dependency resolution.
- Credential access followed when the post-install hook attempted to read GitHub Actions environment variables and exfiltrate tokens available in the build environment.
- Escalation and impact were intended through reuse of the stolen tokens to publish new malicious artifacts and extend compromise into the software supply chain.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
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
Typosquatting has become a governance problem, not just a detection problem. The decisive failure is not whether a binary is eventually flagged as malicious, but whether untrusted package installation is allowed to inherit pipeline authority in the first place. Build-time trust, namespace trust, and token trust are being collapsed into a single event. Practitioners need to separate dependency acquisition from execution and publication rights.
CI/CD tokens now behave like high-value non-human identities. When build systems can read repository context and authenticate to downstream services, a compromised install path can become a privileged identity event. That makes token scope, revocation, and publishing isolation more important than broad malware inspection after the fact. The governance gap is standing authority inside automation, not just malicious code in a package.
Package provenance is the control plane for software supply chain integrity. The article's typosquat and post-install hook pattern shows why identity of the package source matters as much as code content. If the registry name can be imitated, the pipeline needs additional assurance before code is executed. Practitioners should treat provenance checks, signed artifacts, and build isolation as baseline controls, not optional hardening.
Software supply chain failures are now identity failures at release time. The article explicitly ties the campaign to OWASP's supply chain risk theme, and that framing is accurate because the attacker was exploiting delegated machine authority. This is where NHI governance and DevSecOps overlap: automated credentials must be inventoried, scoped, and monitored as identities with lifecycles. Security teams should assume dependency execution can become credential abuse unless release paths are independently constrained.
What this signals
Package provenance is now an identity control. Build systems that authenticate with broad automation tokens create a trust chain that malicious dependencies can exploit, so provenance checks and execution boundaries need to be treated as part of IAM for software delivery.
When package installs can reach publish-capable credentials, the practical control is not just malware detection but authority reduction. Teams should assume every CI/CD token is a non-human identity with its own lifecycle, scope, and offboarding requirements.
For practitioners
- Harden package name trust Block typosquatted dependency names through allowlists, internal mirrors, and repository-level package policy checks before any install step runs.
- Remove publish rights from build jobs Separate build and release identities so routine CI jobs cannot publish packages or write to production repositories after dependency execution.
- Scope CI/CD tokens to the minimum task Limit repository, registry, and cloud permissions for GitHub Actions tokens so a compromised install cannot reuse them outside the build context.
- Execute third-party packages in isolated runners Run dependency install and post-install scripts in sandboxed build workers with no direct access to long-lived secrets or signing keys.
- Verify package provenance before execution Require signed artifacts, provenance metadata, or internal promotion gates for dependencies that can influence release workflows.
Key takeaways
- A typosquatted npm package can turn ordinary dependency installation into a credential abuse path when CI/CD tokens are exposed to build-time code.
- The article illustrates a supply chain failure pattern where package provenance, post-install execution, and automation identity scope all intersect.
- Teams should constrain package trust, separate build and release identities, and remove publish rights from routine pipeline jobs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The attack seeks tokens exposed during package execution and build-time secret handling. |
| NHI-04 — Insecure Authentication | The campaign abuses build authentication paths to reach downstream publishing authority. | |
| NHI-07 — Long-Lived Secrets | Standing automation credentials create the blast radius this attack pattern tries to exploit. | |
| Recommendation — Scan build environments for exposed NHI secrets and remove any credentials reachable during dependency install. Restrict CI/CD authentication paths so untrusted packages cannot inherit publish-capable credentials. Replace long-lived pipeline secrets with short-lived credentials and offboard unused tokens quickly. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The payload attempts to steal build tokens and send them out of the environment. |
| Recommendation — Map package-execution telemetry to TA0006 and TA0010 to detect token theft and outbound exfiltration. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | CI/CD token scope and repository permissions are central to limiting the blast radius. |
| Recommendation — Apply PR.AA-05 to narrow automation entitlements and separate build access from release access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Pipeline identities and service accounts need lifecycle control like any other account type. |
| Recommendation — Manage CI/CD service accounts as first-class accounts and remove privileges that are not required. | ||
Key terms
- Typosquatting: Typosquatting is the practice of naming a malicious package so it looks like a legitimate dependency with a small spelling change. In software supply chains, the goal is to get developers or automation to install attacker code before provenance or behaviour checks catch the deception.
- 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.
- CI/CD Token: A machine credential used by build or deployment automation to authenticate, publish, or modify software artefacts. Because it can change code, infrastructure, or releases at scale, it should be managed as a privileged non-human identity with tight scope and frequent review.
- Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.
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 practitioners translate identity controls into resilient operating models for automation and release pipelines.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org