Malicious axios Packages Published via Compromised Credentials: What Happened and Recommended Actions

On March 31st, two malicious versions of axios were published to npm: 1.14.1 and 0.30.4. Axios is one of the most widely used HTTP client libraries in the Node.js ecosystem. If your applications or CI pipelines pulled either of these versions, treat the affected system as compromised.

The issue is not related to a specific CVE or a flaw in axios being exploited. The attacker compromised a maintainer's credentials, bypassed the project's CI/CD pipeline entirely, and pushed packages directly via the npm CLI. The malicious payload was delivered through a malicious dependency injected into the package: plain-crypto-js@4.2.1.

The issues thread on Github can be viewed here.

Breach Impact

When a developer or CI system ran npm install and pulled axios@1.14.1 or axios@0.30.4, the installation process automatically executed a postinstall script bundled inside plain-crypto-js. That script dropped a cross-platform remote access trojan (RAT) on the host, supporting macOS, Windows, and Linux. The RAT connected to a live command-and-control server, downloaded second-stage payloads, then deleted itself, and cleaned its traces.

From that point forward, any secrets accessible on the compromised machine or in the CI environment were exposed: SSH keys, API tokens, cloud credentials, environment variables. The attacker had a clear foothold and the means to move laterally.

Attacks targeting npm are significant because for most developers npm install is not a conscious decision. It's baked into things like onboarding scripts, git hooks, Docker builds, and CI pipelines. In short, it just happens, which is what makes these attacks so effective at scale.

Immediate Recommendations

If you run Node.js applications or manage CI pipelines that use axios, the following actions are recommended:

• Pin your axios version. Move to axios@1.14.0 (for the 1.x line) or axios@0.30.3 (for the 0.x line). 
• Add --ignore-scripts to your npm install command in CI. This prevents post-install scripts from executing automatically. Make it a hardened default across all pipelines. The flag exists precisely for this scenario.
• Rotate credentials on any system that installed the malicious versions, such as API tokens, SSH keys, cloud access credentials, environment variables on affected machines or containers. 
• Audit your dependency manifest for plain-crypto-js@4.2.1. If it appears anywhere in a node_modules tree or lock file, that system requires immediate incident response in addition to remediation.

Specific inidiactors of compromise (IoCs) to look out for follow.

• IP address: 142.11.206.73
• File: Linux: /tmp/ld.py
• File: macOS: /Library/Caches/com.apple.act.mond
• File: Windows: %PROGRAMDATA%\wt and  %TEMP%\6202033.vbs/.ps1 which only exist briefly during execution
• Malicious Package: axios@0.30.4 sha-256 checksum: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
• Malicious Package: axios@1.14.1 sha-256 checksum: 2553649f2322049666871cea80a5d0d6adc700ca
• Malicious Package: plain-crypto-js@4.2.1 sha-256 checksum: 07d889e2dadce6f3910dcbc253317d28ca61c766

How Oligo Helps

Traditional scanning catches what packages are listed. Oligo tracks what is actually running.

On the posture side, Oligo identifies which library versions are loaded inside running applications. If axios@1.14.1 or axios@0.30.4 execute in a production workload, Oligo surfaces it. The window between a malicious version being published and your team receiving an alert is exactly the time attackers rely on. Ground truth about what is running closes that gap.

On the detection side, malicious execution leaves a trail. Unexpected outbound connections, process spawning, downloaded binaries writing to disk. Oligo's runtime sensor observes application-layer execution and correlates it with system-level activity, so the patterns generated by a postinstall dropper or an active RAT are visible to the teams who need to respond.

For SOC teams, that means faster triage with a clear signal. For AppSec and Cloud Security, it means knowing which workloads carry affected libraries before the next scheduled scan. For security leadership, it means your runtime environment reflects what is actually there.

Read more about how Oligo delivers active protection against supply chain attacks: Malicious Packages Don’t Stop at CI: How Oligo CADR Brings Supply-Chain Detection to Runtime

The Broader Pattern

Axios, Trivy, and LiteLLM all point to the same conclusion. Modern supply chain attacks are prevalent and happen quickly, requiring a stronger shift to detection and response for applications. Once an attacker can publish, sign, or ship through a legitimate channel, the package itself becomes the initial access vector.

This fundamentally breaks the assumptions behind most scanning programs. A manifest can tell you what should be there, and a periodic scan can tell you what is known to be risky. But neither can tell you what actually executed. That is the gap attackers are exploiting, and why we are seeing a rise in attacks like this recently.

‍