Notifications
Clear all
Topic starter
02/08/2026 12:18 pm
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.
NHIMG editorial — based on content published by Veracode covering a malicious npm package targeting GitHub Actions repositories
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Veracode's analysis of the malicious npm package targeting GitHub Actions →
Typosquatted npm packages in GitHub Actions: what should teams change now?
Explore further
02/08/2026 1:19 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Typosquatted npm packages expose CI/CD token abuse in GitHub Actions
