The Package You Trusted: How the Axios Supply Chain Attack Happened

You ran npm install. You’ve done it thousands of times. Three seconds later, without any warning, without any error, your AWS keys, database passwords, and API tokens were silently copied to a server in a data center you’ve never heard of — and a remote access trojan began making itself at home on your machine.

This is exactly what happened to developers who installed axios@1.14.1 or axios@0.30.4 on March 31, 2026.

TL;DR

• Axios — a JavaScript HTTP library with 400 million monthly downloads — was backdoored for approximately three hours on March 31, 2026
• Attackers hijacked the npm account of the main maintainer and published two malicious versions that silently installed a RAT (Remote Access Trojan)
• The malicious packages were part of the “TeamPCP” campaign, which compromised five open-source projects in thirteen days
• The attack executed in 3% of affected environments before detection — significant given Axios’s scale
• Safe versions: axios@1.14.0 (or 0.30.3 for legacy) — check your lockfiles now

Why This Matters to You

If you write JavaScript, Node.js, or work in any environment that uses npm packages, this is your problem — even if you’ve never heard of Axios specifically.

Axios is one of the most downloaded packages in the history of npm. It’s used by Fortune 500 companies, startups, CI/CD pipelines, and hobby projects. It’s a dependency in roughly 80% of cloud and code environments. When a package this widely used gets backdoored, the blast radius is enormous.

But the Axios attack is also a template. TeamPCP, the group behind it, ran the same playbook against four other packages in the two weeks before Axios. The same technique works against any package with a maintainer whose credentials can be compromised. And there are hundreds of thousands of maintainers with publishing rights to packages that power critical infrastructure.

Table of Contents

• What Is Axios?
• The Attack: A Minute-by-Minute Timeline
• How the Backdoor Actually Worked
• TeamPCP: Thirteen Days, Five Packages
• Why npm and PyPI Are So Hard to Defend
• The Scale of the Damage
• What You Can Do Today

What Is Axios?

Axios is a JavaScript library that makes it easy for applications to communicate with servers over HTTP. Think of it as the standard plumbing that connects your app to APIs — whether you’re fetching weather data, processing payments, or sending authentication requests.

It’s not glamorous infrastructure, but it’s everywhere. Axios gets downloaded roughly 400 million times per month. It’s present in the vast majority of modern JavaScript projects, often several layers deep in the dependency tree — meaning your project might use Axios without you ever having typed its name.

That ubiquity is exactly what makes it a valuable target.

The Attack: A Minute-by-Minute Timeline

The attacker compromised the npm account of Jason Saayman, the main Axios maintainer. The method of credential theft has not been publicly confirmed — possibilities include phishing, credential stuffing from a prior breach, or token theft from a development environment.

With publishing access to the Axios npm package, the attacker had the ability to push code to every project in the world that uses Axios with automatic updates enabled.

They used that access carefully. The malicious packages looked almost identical to the legitimate versions. The only difference: a new dependency called plain-crypto-js@4.2.1 quietly added to package.json.

How the Backdoor Actually Worked

Understanding the attack mechanism requires understanding how npm dependencies work.

When you install a package, npm automatically installs all of that package’s dependencies too. If Axios lists plain-crypto-js as a dependency, every npm install axios also installs plain-crypto-js — automatically, silently, as part of the normal process.

plain-crypto-js was a package created by the attacker specifically for this attack. It had no legitimate functionality. Its entire purpose was to run a malicious script the moment it was installed.

The post-install hook

npm allows packages to run scripts automatically after installation — a feature called post-install hooks, designed for legitimate purposes like compiling native code or setting up configuration. The attacker used this feature to execute their payload.

When plain-crypto-js was installed, it immediately ran setup.js — an obfuscated dropper that:

1. Identified the operating system (Windows, macOS, or Linux)
2. Contacted the attacker’s C2 server at sfrclak.com / 142.11.206.73:8000
3. Downloaded the appropriate platform-specific payload
4. Executed it, establishing a persistent remote access connection

The C2 server served different malware based on the detected OS:

• /product0 — macOS payload
• /product1 — Windows payload
• /product2 — Linux payload

What the RAT did

A RAT — Remote Access Trojan — gives an attacker persistent, remote control over an infected machine. Unlike ransomware, which announces itself, a RAT is designed to be invisible. The goal is to stay hidden for as long as possible.

In this case, the RAT’s first action was credential harvesting: it swept the compromised machine for cloud access keys (AWS, Azure, GCP), database connection strings, SSH private keys, API tokens, and environment variables — the exact materials an attacker needs to move laterally into production systems.

Artifacts left by platform:

The malware was also designed to self-delete forensic evidence after execution — making post-compromise analysis significantly harder.

Why traditional defenses didn’t catch it

Your antivirus didn’t flag it. Your firewall didn’t block it. Your code review didn’t catch it. Here’s why:

• The malicious code was in a dependency of a dependency — most security tools don’t deeply inspect transitive dependencies at install time
• The payload arrived from a remote server after installation, meaning static analysis of the package itself would find nothing
• The C2 domain was newly registered and had no reputation history to flag
• The post-install script used obfuscation to defeat pattern matching
• The network traffic blended in with normal developer tool activity

TeamPCP: Thirteen Days, Five Packages

The Axios attack didn’t happen in isolation. It was the fifth operation in a coordinated campaign by a group researchers have named TeamPCP, which struck a series of widely-used open-source tools in rapid succession.

The targeting pattern is notable: TeamPCP focused on developer tools and infrastructure rather than end-user applications. Security scanners, AI libraries, network libraries — tools that run in CI/CD pipelines and development environments, where credentials and secrets are plentiful and often poorly protected.

The IAB model

Security researchers believe TeamPCP operates as an Initial Access Broker (IAB) — a threat actor that specializes in gaining access to environments and then selling that access to other groups, including ransomware operators, espionage actors, and nation-state teams.

This explains the apparent lack of direct financial payload in the Axios attack. No ransomware, no cryptominer. The attack was designed to harvest credentials silently and establish persistence — the raw material for more targeted follow-on attacks.

The absence of cryptocurrency mining or ransomware and the sophisticated, multi-platform design of the RAT suggests either APT (Advanced Persistent Threat) involvement or a high-end criminal operation selling to APT customers.

Why npm and PyPI Are So Hard to Defend

The Axios attack exploited a structural weakness in how open-source package ecosystems work — one that has no easy fix.

The trust model is inverted

When you install a package from npm, you’re implicitly trusting:

• The package itself
• Every dependency that package declares
• Every dependency of those dependencies (and so on, recursively)
• The npm accounts of every maintainer of every package in that tree
• The security practices of every one of those maintainers

A medium-complexity JavaScript project might pull in 500-1000 packages from hundreds of different maintainers. Each maintainer’s npm account is a potential attack surface. You’ve effectively outsourced your security decisions to people you’ve never met.

Maintainer accounts are high-value, low-security targets

The npm account of the Axios maintainer controlled distribution to 400 million monthly downloads. That’s enormous leverage — but the account was protected by the same basic authentication as any other npm user.

The open-source ecosystem runs largely on volunteer labor. Most maintainers aren’t security professionals. Many haven’t enabled mandatory 2FA on their publishing accounts. Credential theft, phishing, or even purchasing leaked credentials from data breaches gives attackers access to publishing rights that affect millions of installations.

Post-install hooks are a design feature being used as a weapon

npm allows packages to run arbitrary code on installation. This is a legitimate feature — it’s how packages compile native modules, generate configuration files, and set up integrations. But it means that installing a package can immediately execute code on your machine, before you’ve had any chance to review what that code does.

There’s currently no mandatory sandboxing of post-install scripts in npm. They run with the same permissions as your terminal.

The speed problem

Between publishing and removal, the malicious Axios versions were live for approximately three hours. In that window, the packages were downloaded by developers and CI/CD systems worldwide.

npm’s automatic update mechanisms — npm update, ^ version ranges in package.json — mean many environments pulled the malicious version without any human decision being made. A CI/CD pipeline that runs npm install on every build may have pulled and executed the backdoor multiple times before it was removed.

The Scale of the Damage

Quantifying the full impact is difficult. Execution was confirmed in 3% of affected environments — a number that sounds small until you multiply it against Axios’s scale.

Axios has approximately 400 million monthly downloads. Even using conservative estimates, hundreds of thousands of environments that pulled the malicious packages were in CI/CD pipelines, development machines, and cloud environments with access to production credentials.

The damage from credential theft doesn’t manifest immediately. An attacker who harvests AWS keys in March may use them to launch infrastructure in June, exfiltrate data in August, or sell the access to a ransomware group that deploys in September. The full blast radius of a supply chain attack is often only visible long after the initial compromise.

What You Can Do Today

Immediate: check for exposure

# Check if you have the malicious versions in any lockfile
grep -r "axios" package-lock.json | grep -E "1\.14\.1|0\.30\.4"

# Check for the malicious dependency
grep -r "plain-crypto-js" node_modules/ package-lock.json

If you find either, treat the machine as compromised: rotate all credentials that may have been accessible, check for the RAT artifacts listed above, and audit access logs for suspicious activity.

Audit your dependency tree

Most projects have never looked at the full list of packages they depend on. Change that:

# Show full dependency tree
npm ls --all

# Check for known vulnerabilities across all dependencies
npm audit

# Find packages with post-install scripts (potential attack surface)
grep -r "postinstall" node_modules/*/package.json | grep -v "#"

Lock your dependency versions

The ^ prefix in package.json allows automatic minor and patch version updates. This is convenient, but it’s also what allowed the malicious 1.14.1 to be pulled automatically by projects that had ^1.14.0 in their dependencies.

For production environments and CI/CD pipelines, lock exact versions and commit your lockfile:

// Less safe: allows automatic updates
"axios": "^1.14.0"

// Safer: exact version pinned
"axios": "1.14.0"

Commit your package-lock.json to version control and verify it in CI.

Use a software composition analysis (SCA) tool

SCA tools — Snyk, Socket, Dependabot, or similar — monitor your dependencies continuously for newly discovered vulnerabilities and compromised packages. They can alert you within minutes of a package being flagged, rather than hours or days after you’ve already run npm install.

Socket, specifically, analyzes package behavior rather than just known CVEs — it can detect suspicious post-install scripts, newly added network activity, and other behavioral signals that traditional vulnerability scanners miss.

Apply least privilege to your CI/CD environment

CI/CD pipelines are the highest-value target in a supply chain attack because they run with cloud credentials, code signing keys, and deployment access. Apply the same principle you’d use for any privileged account:

Enable 2FA on your npm account

If you maintain any npm packages, enable two-factor authentication on your publishing account. npm now supports hardware security keys and TOTP authenticators. This single step makes credential theft attacks significantly harder to execute.

The Bigger Picture

The Axios attack is alarming not because it’s unusual, but because it’s becoming routine. TeamPCP ran five operations in thirteen days. In 2025, researchers identified over 700 malicious packages on npm and PyPI. The ecosystem is under sustained, professional pressure.

The open-source supply chain is a critical dependency of virtually all modern software. It runs on trust, volunteer labor, and credentials protected to highly variable standards. Attackers have figured this out, and they’re exploiting it systematically.

The tools to defend against this are improving: better SCA tooling, behavioral analysis of packages, mandatory 2FA for high-impact maintainers, sigstore/npm provenance for package signing. Progress is real.

But deployment of those defenses is uneven, and the gap between “this attack is possible” and “every organization has protected itself” is exactly the window attackers are operating in.

For now, the most important posture is simple: treat every npm install as an action with security implications, lock your dependencies, and monitor what your builds actually do.

Related Posts

• When Trusted Agents Turn Rogue: The Rise of the Double Agent — the same “trusted by design” vulnerability that enables supply chain attacks applies to AI agents
• MCP Servers Through an Attacker’s Eyes — MCP server supply chain attacks follow the same rug-pull pattern as the Axios compromise
• GitHub Secrets Management Crisis: 65% of AI Companies Leaked Credentials — the credentials harvested in supply chain attacks end up in exactly this kind of leak
• Non-Human Identity Security: The Biggest Blind Spot of 2026 — CI/CD credentials and service tokens are the primary target of supply chain RATs

Sources

• SANS Institute — Axios NPM Supply Chain Compromise: Malicious Packages Deliver Remote Access Trojan
• BleepingComputer — Hackers compromise Axios npm package to drop cross-platform malware
• The Hacker News — Axios Supply Chain Attack Pushes Cross-Platform RAT via Compromised npm Account
• Wiz — Axios NPM Distribution Compromised in Supply Chain Attack
• Aikido Security — axios compromised on npm: maintainer account hijacked, RAT deployed
• Huntress — Supply Chain Compromise of axios npm Package
• Snyk — Axios npm Package Compromised: Supply Chain Attack Delivers Cross-Platform RAT
• StepSecurity — axios Compromised on npm: Malicious Versions Drop Remote Access Trojan
• Help Net Security — Axios npm packages backdoored in supply chain attack
• OX Security — Axios Compromised by Malicious NPM Dependency