What matters first
- The maintainer identified two specific malicious versions and the injected dependency.
- Installation-time activity makes developer machines and CI runners relevant.
- A clean dependency change does not establish that an already exposed host or credential is safe.
What the maintainer reported
The Axios post-mortem identifies versions 1.14.1 and 0.30.4 and an injected plain-crypto-js dependency as part of the March incident. It states that the malicious dependency installed a remote-access trojan and that the affected releases were removed from npm. Use the maintainer’s current record for the incident timeline and indicators.
Do not convert a popular package’s download count into a victim count. A lockfile entry, downloaded artifact, executed install, and confirmed credential misuse are different pieces of evidence. Each should be established independently when assessing your organization’s exposure.
References: [1] Axios maintainer
Find where installation or execution happened
Review lockfiles, build logs, package caches, dependency mirrors, and release records for the affected period and package versions. Include ephemeral CI runners, developer environments, and test pipelines. A machine that never shipped an application may still have executed an install step with valuable credentials in its environment.
Map the secrets, repositories, cloud roles, and signing or publishing authority available to each potentially affected machine. Preserve relevant evidence before cleanup decisions remove it. Escalate suspected host compromise through your incident process rather than treating this only as a routine dependency update.
References: [1] Axios maintainer, [2] NIST
Recover from a trusted environment
Remove affected releases from the dependency graph and move to a current clean release according to maintainer guidance. Recreate build or development environments from trusted sources when incident assessment requires it. A small lockfile edit cannot undo malware that already ran on a host.
Revoke and replace exposed credentials from a clean administrative environment. Review identity activity and downstream access as part of containment. Rebuild artifacts through a trusted pipeline and establish which outputs are suitable for redeployment, including cached dependencies and reused runner images.
References: [1] Axios maintainer, [3] GitHub, [4] CISA
Strengthen the publishing and build boundary
For package maintainers, trusted publishing can reduce reliance on long-lived registry tokens by using an identity relationship with the build platform. It still requires careful workflow and repository controls. For package consumers, review dependency changes and installation behavior alongside conventional vulnerability scanning.
Separate untrusted pull-request jobs from privileged publishing or deployment jobs. Keep permissions and secret exposure narrow, and retain evidence about the source, lockfile, and artifact used for a release. These measures improve recovery clarity even when a trusted upstream package changes unexpectedly.
References: [5] npm, [6] GitHub, [7] npm
Your next steps
- Identify affected package versions in lockfiles, caches, and installation logs.
- Determine which machines executed installation and map their available credentials.
- Contain affected environments and rotate exposed credentials from trusted systems.
- Rebuild with clean dependencies and document the evidence supporting release recovery.
Questions teams ask
Is removing the malicious dependency sufficient?
It addresses future dependency use, but it does not establish the safety of a machine where malware already executed. Host and credential recovery require separate assessment.
Can a lockfile prevent all supply chain attacks?
No. It records selected dependencies and helps make changes reviewable, but a lockfile can include a malicious release if that release was accepted into the dependency graph.
Sources and editorial notes
Public-source facts are cited above. The review questions and action plans are Cyphen’s guidance for applying those lessons to your own systems. Sources checked on .