Axios malicious package: what developers and defenders should check
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.
Why this matters
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.
What happened in the Axios incident
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.
How the malicious package was published
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.
What the malicious package contained
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.
Why enterprises should care
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.
What to check in GitHub
Repository search is one of the fastest ways to understand likely exposure.
Use GitHub search to find:
axiosinpackage.jsonaffected 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.
What to check in Intune
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.
What to check in CrowdStrike
CrowdStrike should help determine whether a package reference turned into endpoint activity.
Investigate:
process chains from
node,npm,yarn, orpnpmsuspicious 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?”
What to check in Jamf
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.
What developers should do
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
What SOC and product security teams should do
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.
Closing
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.
FAQ
Was the Axios incident just a typosquat?
No. The concern was abuse of the trusted Axios package distribution path, which makes it more serious than a lookalike package.
Why is install-time behavior so important?
Because package installation can execute code. A malicious dependency can turn a normal install into a malware delivery event.
Is repository search enough?
No. Repository search shows where the package may exist. EDR and device telemetry help determine whether it was actually installed and executed.
Why include Intune, CrowdStrike, and Jamf in the response?
Because package incidents become endpoint incidents when installation occurs on developer workstations or CI runners.
