Search for a command to run...
What the Axios malicious package contained, how it was published, and how teams can check GitHub, Intune, CrowdStrike, and Jamf.
Specialized in uncovering vulnerabilities within software supply chains and dependency ecosystems. Creator of SCAGoat and other open-source security tools. Speaker at Black Hat, DEF CON, and AppSec conferences with research on malicious package detection, dependency confusion, and CI/CD security.
No comments yet. Be the first to comment.
As security researchers, we often analyze vulnerabilities in isolation. A Remote Code Execution (RCE) in a web app is one thing; sharepoint compromise in an enterprise cloud is another. But what happens when these two converge? To understand the true...
1. Introduction: The Attack of the Code Worm Imagine building a project with a set of Lego bricks, but one of the bricks is secretly malicious. Not only is it a bad piece, but it also has the ability to copy itself and sneak into all the other Lego s...
Static code analysis has come a long way from the days of simple string searches. With the rising complexity of applications and threats, our tooling has evolved to meet the demand for both precision and context-awareness. This blog takes you through...
In a startling turn of events, the widely-used Nx build system fell victim to a sophisticated supply chain attack. On August 26, 2025, malicious versions of the Nx packages were published to the npm registry, compromising the systems of potentially t...
Software supply chain attacks are landing one after another. Recent incidents involving Trivy, Checkmarx KICS, LiteLLM, Telnyx, and now Axios show the same pattern: compromise trusted developer tooling, get close to secrets, and turn routine installs into security incidents.
For developers and defenders, the key question is not only whether a package was malicious. It is whether any developer laptop, CI runner, or build system actually installed it.
The Axios incident was not a typosquat. The trusted npm package path for Axios was abused through malicious releases. Those versions pulled in a hidden dependency that executed code during installation.
That makes this more than a package hygiene issue. A normal npm install could become an endpoint compromise path.
The compromise appears to have used a staged dependency path instead of putting obvious malware directly into the main package logic.
At a high level, the flow was simple:
malicious dependency added
Axios releases referenced that dependency
install-time script executed during package installation
second-stage payload ran based on operating system
obvious traces were reduced after execution
This is why defenders have to inspect what was actually published and executed, not just what the source repository looked like.
The malicious Axios path reportedly used install-time execution through a dependency hook. That matters because package managers are often trusted too much in developer environments.
Simple commands such as these can become execution paths:
npm install
npm ci
yarn install
pnpm install
For developers, that means package install activity should be treated as code execution, not just dependency resolution.
If the malicious package executed on a workstation or CI runner, the blast radius may include more than source code.
Possible exposure can include:
GitHub or GitLab tokens
cloud credentials
SSH keys
browser sessions
package publishing credentials
CI secrets and deployment access
That is why removing the package is not enough. Teams have to determine whether the install actually ran and what access existed on that machine at the time.
Repository search is one of the fastest ways to understand likely exposure.
Use GitHub search to find:
axios in package.json
affected versions in lockfiles
workflow files that run package installation
self-hosted runner paths that may have executed the install
Example searches:
org:YOURORG "axios" path:**/package.json
org:YOURORG "1.14.1" path:**/package-lock.json
org:YOURORG "0.30.4" path:**/package-lock.json
org:YOURORG "plain-crypto-js"
org:YOURORG "npm ci" path:.github/workflows
org:YOURORG "pnpm install" path:.github/workflows
These searches do not prove execution, but they help identify where to correlate with endpoint and CI telemetry.
Intune helps narrow the endpoint population quickly.
Use it to identify:
managed developer devices with Node.js or JavaScript tooling
active endpoints during the exposure window
device groups that need triage or remediation
Intune will not always prove that the malicious version was installed, but it is useful for scoping which endpoints deserve immediate follow-up.
CrowdStrike should help determine whether a package reference turned into endpoint activity.
Investigate:
process chains from node, npm, yarn, or pnpm
suspicious child processes after install activity
unusual outbound network connections
dropped files in temp or cache paths
persistence or follow-on execution behavior
This is where the question changes from “Was the repo exposed?” to “Was the machine compromised?”
Jamf is especially useful for developer Mac fleets.
Use it to:
identify Macs with JavaScript development tooling
group likely affected developer devices
run targeted scripts or collect extra endpoint state
support rapid scoping without investigating every Mac equally
Jamf does not replace EDR, but it helps teams act fast across managed Apple devices.
Developers should not treat this like a routine version rollback.
Immediate actions should include:
identify whether affected versions appear in dependencies or lockfiles
determine whether installation actually occurred
preserve useful evidence where possible
review and rotate sensitive credentials if compromise is plausible
involve product security or SOC teams early
A strong response usually follows this sequence:
confirm the malicious versions and exposure window
search repositories and lockfiles
identify CI runners and build jobs that may have installed them
scope likely developer endpoints with device management tools
investigate confirmed systems in EDR
rotate or revoke reachable credentials
This kind of incident sits across AppSec, product security, endpoint security, and SOC workflows. Treating it as only a dependency issue slows response.
The Axios malicious package is a reminder that supply chain attacks now target the places developers trust most. For enterprises, the hard problem is no longer only finding the bad package. It is determining which endpoints, runners, and repositories actually executed it.
That is why GitHub search, Intune, CrowdStrike, and Jamf all matter in the same investigation. One shows where the dependency lived. The others help show where the compromise became real.
No. The concern was abuse of the trusted Axios package distribution path, which makes it more serious than a lookalike package.
Because package installation can execute code. A malicious dependency can turn a normal install into a malware delivery event.
No. Repository search shows where the package may exist. EDR and device telemetry help determine whether it was actually installed and executed.
Because package incidents become endpoint incidents when installation occurs on developer workstations or CI runners.