Supply Chain Alert: Malicious Axios Versions Published to npm

Prophet Security is tracking a high-impact supply chain attack involving Axios, one of the most widely used packages in the JavaScript ecosystem.

Attackers compromised a legitimate Axios maintainer account (initial reports from StepSecurity and Socket) and used that trust to publish malicious versions of the real package:

• axios@1.14.1
• axios@0.30.4

Those versions introduced a malicious dependency, plain-crypto-js@4.2.1, which used a postinstall hook to deploy a cross-platform remote access trojan affecting Windows, macOS, and Linux.

What is the Axios Supply Chain Attack?

This is a software supply chain attack delivered through a trusted dependency with broad downstream reach.

Axios is deeply embedded across developer workstations, CI/CD pipelines, backend services, and production builds. When a trusted package is compromised, the blast radius extends far beyond a single application or team.

A few things make this incident especially concerning:

• Axios has massive adoption across the JavaScript ecosystem
• The attacker used a legitimate maintainer account
• The malicious payload executed automatically during install
• The malware was designed to clean up after itself, reducing obvious evidence on disk
• Extensive reconnaissance and enumeration of systems, processes and files, suggesting intelligence gathering for future steps

Modern supply chain attacks move through trusted channels, execute quickly, and are easy to miss if teams are only watching for traditional exploit behavior.

{{ebook-cta}}

Why it matters

If your organization installed either malicious Axios version during the exposure window, treat this as a potential post-compromise event.

The impact can reach across:

• CI/CD systems
• engineering laptops
• backend infrastructure
• production servers and containers
• production workloads built during the exposure window

Patching alone is not enough. Security teams need to determine whether malicious code executed, what systems it touched, and whether secrets, build artifacts, or downstream environments should now be treated as exposed.

Axios also shows up in threat actor infrastructure, including phishing kits and phishing sites. That creates a broader downstream concern. If the attacker-operated phishing infrastructure was updating dependencies and not pinning to a known safe version of Axios, those environments may also have pulled the compromised package. Trusted packages with broad adoption can propagate risk across any infrastructure that pulls them, including both legitimate and malicious environments. Malicious infrastructure hijacking may lead to sudden changes from less disruptive threat activity, such as phishing and crypto currency mining, to more aggressive ransomware and other disruptive classes of attacks.

What to do now

Organizations should immediately:

• check for axios@1.14.1, axios@0.30.4, and plain-crypto-js in lockfiles and installed dependencies
• downgrade to known good Axios versions
  
  • npm install axios@1.14.0   # for 1.x users
  • npm install axios@0.30.3   # for 0.x users
• remove the malicious dependency from affected systems
• block known attacker infrastructure at the network layer (IOCs included below)
• review affected endpoints, build agents, servers, containers, and CI/CD systems for evidence of execution

If these versions were installed, assume compromise until proven otherwise and respond accordingly:

• rotate npm tokens, cloud credentials, SSH keys, and CI/CD secrets
• audit pipeline runs during the exposure window
• rebuild images and artifacts produced from impacted environments
• investigate engineering laptops, production servers, QA environments, and container workloads for follow-on activity

Indicators of Compromise (IOCs)

Malicious packages

Network IOCs

Endpoint and host IOCs

Hunt and detection guidance

Hunt for evidence of execution and persistence.

Look for:

• Outbound connections to sfrclak[.]com
• Connections to packages[.]npm[.]org/product0, product1, or product2
• Suspicious child processes spawned by npm or node
• Unexpected binaries or scripts written to system paths
• Persistence tied to the MicrosoftUpdate user run key on Windows
• Suspicious launchd-backed execution on macOS
• Execution of /tmp/ld.py on Linux, especially as root
• Use of nohup in connection with /tmp/ld.py or similar staged payload execution

This attack delivered attacker-controlled code through a trusted dependency and created the potential for remote access across engineering and production environments.

How Prophet AI helps

Supply chain attacks like this often present as a series of small but high-risk behaviors tied to trusted software and normal developer workflows. They can begin on an engineering laptop, show up in a CI/CD pipeline, and then land on a production server or container. Defenders need fast, contextual investigation that can connect the dots early.

Prophet AI helps customers investigate that activity in real time, reason through the surrounding context, and escalate clear malicious behavior before teams are left reconstructing the story after the fact.

In this case, Prophet AI has been identifying attacker-linked execution across the systems that matter most, engineering endpoints and production infrastructure. It's been able to connect the behavior to suspicious infrastructure and malware staging paths, delivering high-confidence determinations early enough for defenders to act.

That combination of speed, context, and judgment is helping customers respond to these supply chain events before they turn into broader security incidents. Request a demo of Prophet AI to see it in action.