Axios Compromised: Protect Your Stack from Supply-Chain Attacks

Recently we all have observed a trending topic where an npm package got compromised, especially Axios, which leads to a supply chain attack, a greater threat for companies and their security. To understand this blog, you should have prior knowledge of what a supply chain attack is and what a RAT (Remote Access Trojan) is: ref: https://lnkd.in/gswtNvdX ref: https://lnkd.in/gjQriJ9a Most developers are using Next.js because of its quality and the wide range of frameworks and packages available to build applications dynamically. Where options and features are wide, the vulnerabilities related to those features also become wider for attackers. The package that got compromised is Axios, which is used as an HTTP client in Node.js JavaScript. How it got compromised or poisoned? The attacker tampered with the maintainer account where the module packages of Axios are stored in the npm server, and poisoned it by adding a malicious script named: plain-crypto-js@4.2.1 People who recently installed these packages are affected by this attack. Below mentioned are the poisoned versions: axios@1.14.1 axios@0.30.4 What it does? When we install the package from the web, the malicious script file automatically drops into the system. It triggers automatically and runs a post-install script, which installs a RAT in the user’s system. The RAT reads sensitive files such as: 1. .env 2. Git tokens 3. AWS credentials 4. SSH keys It can also communicate with C2 (Command & Control) servers. Attack Chain: Your Application (code) ↓ axios installation ↓ plain-crypto-js ↓ postinstall script ↓ RAT infection How to validate whether you are affected by the attack using a simple command: grep -R "postinstall" node_modules Explore your package.json file and check whether it contains the following entry: { "name": "plain-crypto-js", "version": "4.2.1", "scripts": { "postinstall": "node install.js" } } Supply chain attacks like this remind us that even trusted open-source dependencies can become an entry point for attackers, so developers and security teams must always monitor and validate the packages they install. #CyberSecurity #SupplyChainAttack #OpenSourceSecurity #NodeJS #NPM #DevSecOps #ApplicationSecurity #InfoSec https://lnkd.in/gageJmxj

The 𝗮𝘅𝗶𝗼𝘀 𝗻𝗽𝗺 𝗽𝗮𝗰𝗸𝗮𝗴𝗲 was hit by a 𝘀𝘂𝗽𝗽𝗹𝘆 𝗰𝗵𝗮𝗶𝗻 𝗮𝘁𝘁𝗮𝗰𝗸 on March 31, 2026, and if you are a JavaScript developer, this one hits close to home. Axios has roughly 100 million weekly downloads. It is in almost every React, Node.js, or full-stack project out there. Two versions of it (1.14.1 and 0.30.4) were weaponized within a 3-hour window. Here is what happened: Attackers compromised the npm account of 𝗷𝗮𝘀𝗼𝗻𝘀𝗮𝗮𝘆𝗺𝗮𝗻, the primary axios maintainer, and changed the registered email to an attacker-controlled ProtonMail address. Using that access, they published two poisoned releases that injected a hidden dependency: 𝗽𝗹𝗮𝗶𝗻-𝗰𝗿𝘆𝗽𝘁𝗼-𝗷𝘀@𝟰.𝟮.𝟭, a fake lookalike of the legitimate crypto-js library. That package executed a postinstall script the moment you ran npm install, silently dropping a cross-platform 𝗥𝗲𝗺𝗼𝘁𝗲 𝗔𝗰𝗰𝗲𝘀𝘀 𝗧𝗿𝗼𝗷𝗮𝗻 (𝗥𝗔𝗧) targeting Windows, macOS, and Linux. The malware then contacted a C2 server (sfrclak.com:8000), harvesting SSH keys, cloud tokens, API keys, and environment secrets, then self-deleted to wipe its own traces. How was it caught? Three security firms independently identified this attack: - 𝗦𝗼𝗰𝗸𝗲𝘁.𝗱𝗲𝘃: Their automated scanner flagged the malicious plain-crypto-js within 6 minutes of publication (00:05 UTC) - 𝗦𝘁𝗲𝗽𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆: Their AI Package Analyst and Harden-Runner detected anomalous outbound connections during live CI runs, including in the widely used Backstage repository - 𝗦𝗻𝘆𝗸: Published a full technical breakdown of the attack chain and blast radius The malicious versions were live for roughly 3 hours (00:21 to 03:29 UTC) before npm pulled them. What makes this particularly alarming: The attack was pre-staged 18 hours in advance. Three platform-specific RAT payloads were pre-built. Both the 1.x and 0.x release branches were hit within 39 minutes of each other. The malware cleaned up after itself, so npm audit shows nothing. This was not opportunistic. If you use axios, act now: - Pin to version 1.14.0 or 0.30.3 (confirmed safe) - Use npm ci instead of npm install in CI/CD pipelines - Rotate any secrets from environments where the affected versions ran - Add plain-crypto-js to your dependency blocklist This is a reminder that open-source trust is one of our industry's largest attack surfaces. Lockfiles, postinstall script auditing, and runtime monitoring are not optional. They are baseline hygiene.

A hijacked maintainer account just poisoned millions of JavaScript projects in under three hours. The recent Axios npm attack demonstrates how fragile our software supply chain truly is. When attackers compromised a single maintainer's account, they managed to inject malware into one of the most trusted JavaScript libraries through hidden dependencies. The scope is staggering – Axios powers countless enterprise applications and developer tools worldwide. This isn't just another security incident; it's a wake-up call for every development team. The attack vector was sophisticated yet simple: compromise the human element, exploit trust relationships, and let automated systems do the rest. Traditional security scanning missed it because the malicious code was buried deep in dependency trees. What's your organization doing to audit third-party dependencies? How are you balancing development velocity with supply chain security? https://lnkd.in/eERCnjM3

When will the world learn? Automatically updating without any due diligence is a recipe for disaster. The second mouse gets the cheese.

One hijacked npm account and a two-line package.json edit put a RAT dropper inside one of the most downloaded JavaScript libraries on the internet. On March 31, 2026, attackers published two malicious versions of Axios, axios@1.14.1 and axios@0.30.4, through a compromised maintainer account. The packages were live for under three hours before npm unpublished them. Axios has between 100 and 300 million weekly downloads. The attacker hijacked the `jasonsaayman` maintainer account, changed the registered email to an anonymous ProtonMail address, and used a long-lived npm access token to publish manually, bypassing the project's trusted GitHub Actions publisher flow. The Axios source code was untouched. A single dependency was added to package.json: `plain-crypto-js@4.2.1`, a package the attacker had staged the previous day with a clean decoy version to build publishing history. That dependency's postinstall hook executed an obfuscated Node.js dropper that detected the operating system, beaconed to C2 infrastructure at sfrclak.com, downloaded platform-specific RAT payloads, then deleted itself and overwrote package.json with a clean version. The malware targeted SSH keys, cloud credentials, API keys, and crypto wallets before cleaning its tracks. Any CI/CD pipeline or developer workstation that ran npm install during the three-hour window with unpinned caret version ranges was exposed. Takeaways and Recommendations ● Audit lockfiles immediately for axios@1.14.1, axios@0.30.4, or plain-crypto-js@4.2.1. If found, rotate all secrets on that machine without exception. SSH keys, cloud tokens, npm tokens, and API credentials must be treated as compromised. ● Long-lived npm access tokens are a persistent attack surface. Maintainers of high-impact packages must use short-lived OIDC tokens via trusted publisher flows and revoke all legacy tokens. ● Run CI pipelines with `--ignore-scripts` to prevent postinstall hooks from executing during dependency installation. This single control stops this entire class of attack. ● Implement package age and integrity scanning tools such as Socket in CI pipelines. Brand-new packages added as dependencies to established libraries warrant immediate scrutiny. #CyberSecurity #SupplyChainSecurity #npm #SoftwareSupplyChain #DevSecOps

Ever wonder how a single 'npm install' can compromise your entire machine? As a MERN stack developer, I’ve been looking into the recent Axios security breach. The "magic" behind the attack lies in a built-in npm feature: the postinstall script. 𝐖𝐡𝐚𝐭 𝐢𝐬 𝐚 𝐩𝐨𝐬𝐭𝐢𝐧𝐬𝐭𝐚𝐥𝐥 𝐬𝐜𝐫𝐢𝐩𝐭?  In npm, 'lifecycle scripts' allow packages to automate tasks. A 'postinstall' script runs automatically as soon as a package (and its dependencies) are finished downloading. It was designed for helpful tasks, like compiling native code. 𝐇𝐨𝐰 𝐝𝐨 𝐡𝐚𝐜𝐤𝐞𝐫𝐬 𝐞𝐱𝐩𝐥𝐨𝐢𝐭 𝐢𝐭?  The danger is that these scripts run with the same permissions as the user who typed the command. 𝑯𝒆𝒓𝒆 𝒊𝒔 𝒕𝒉𝒆 𝒕𝒚𝒑𝒊𝒄𝒂𝒍 𝒇𝒍𝒐𝒘 𝒐𝒇 𝒂 𝒅𝒆𝒑𝒆𝒏𝒅𝒆𝒏𝒄𝒚 𝒂𝒕𝒕𝒂𝒄𝒌: ⦿ The "Dropper": The hacker injects a "postinstall": "node setup.js" line into the package.json of a compromised library. ⦿ Silent Execution: When you run 'npm install', your terminal silently executes that setup.js file. You usually won't see any red flags in the console. ⦿ The Payload: That script reaches out to a remote server to download a malicious payload—like a Remote Access Trojan (RAT)—specifically designed for your Operating System. ⦿ The Cleanup: Modern attacks (like the recent Axios one) are sophisticated enough to delete the malicious script and the evidence from your node_modules immediately after running, making 'npm audit' believe everything is fine. 𝐇𝐨𝐰 𝐭𝐨 𝐩𝐫𝐨𝐭𝐞𝐜𝐭 𝐲𝐨𝐮𝐫𝐬𝐞𝐥𝐟: ➊ Use --ignore-scripts: When installing a new or untrusted package, run 'npm install --ignore-scripts'. This prevents any lifecycle scripts from executing. ➋ Audit your CI/CD: Ensure your build servers are isolated and don't have unnecessary access to sensitive environment variables during the install phase. ➌ Move to Native: Where possible, use native APIs like 'fetch' to reduce the number of third-party dependencies in your graph. Security is a shared responsibility. Every dependency you add is a door you're leaving unlocked—make sure you know who has the key. #WebDevelopment #CyberSecurity #NodeJS #NPM #SoftwareEngineering #Programming #MERNStack #TechSecurity

🚨 Axios Supply Chain Attack A Critical Lesson for Developers & Security Teams A major supply chain compromise has impacted one of the most widely used JavaScript libraries, Axios. On March 31, 2026, attackers gained access to a maintainer’s npm account and published malicious versions: axios@1.14.1 axios@0.30.4 These versions included a hidden dependency (plain-crypto-js) that executed a post-install script, deploying a cross-platform Remote Access Trojan (RAT) affecting macOS, Windows, and Linux. According to Snyk, this attack allowed malware to execute simply by running npm install, meaning developers, CI/CD pipelines, and build systems could be compromised without any code changes. (Snyk) This was not a typical vulnerability. The attacker leveraged trust in the ecosystem by injecting a malicious dependency into an official package release. 📌 Official Advisory (CSA Singapore): https://lnkd.in/ghr7FUPn 📌 GitHub Incident Thread: https://lnkd.in/gWHuPPzY 📌 Deep Technical Breakdown (Snyk): https://lnkd.in/gErdDc86 🔍 What you should do Avoid axios@1.14.1 and axios@0.30.4 Audit lockfiles for affected versions Check for plain-crypto-js in dependencies Rotate credentials if exposure is possible Review CI/CD logs for unusual install-time activity Rebuild affected systems from a clean state if needed 🧠 Key takeaway This incident reinforces a critical shift in security: 👉 The biggest risk is no longer just vulnerabilities in code 👉 It is trust in the software supply chain itself Even highly trusted packages can become attack vectors within minutes when distribution channels are compromised. Strong practices like lockfile enforcement, dependency pinning, controlled updates, and monitoring install-time behavior are now essential. #CyberSecurity #SupplyChainSecurity #NodeJS #DevSecOps #Infosec

🚨 The Axios npm attack just happened — and if you use JavaScript, you need to read this. On March 31, 2026, one of the most widely used npm packages in the world — axios (100 million+ weekly downloads) — was weaponized in a precision supply chain attack. The attackers hijacked the npm credentials of the primary axios maintainer and published two poisoned versions: axios@1.14.1 and axios@0.30.4. Here's the scary part: there are zero lines of malicious code inside axios itself — and that's exactly what makes this attack so dangerous. So how did they actually do it? The attacker didn't touch any axios source files. Instead, they injected a fake dependency — plain-crypto-js@4.2.1 — into the package.json of the malicious axios releases. A clean decoy version, plain-crypto-js@4.2.0, was published 18 hours earlier to give it a brief history on the registry — making it look legitimate to anyone who glanced at it. When a developer or CI system ran npm install axios@1.14.1, npm resolved the dependency tree, pulled plain-crypto-js@4.2.1, and automatically executed its postinstall hook: node setup.js. That single script execution is where the compromise began. The dropper was double-obfuscated — reversed Base64 with XOR encryption — to dodge static analysis. What happened after that? The dropper contacted a live command-and-control server, delivered separate second-stage payloads for macOS, Windows, and Linux, then erased itself and replaced its own package.json with a clean decoy. A developer inspecting their node_modules folder after the fact would find no indication anything went wrong. The RAT was designed to harvest credentials, SSH keys, cloud tokens, and API keys — from both your CI/CD pipelines AND your local developer machine. The malicious versions were removed within a few hours, but axios's presence in roughly 80% of cloud and code environments meant rapid exposure, with observed execution confirmed in 3% of affected environments. Are YOU affected? Check right now. NetworkChuck has published a full detection guide with scripts for Mac, Linux, and Windows: https://lnkd.in/d2wyAdbX Quick check: npm list axios npm list -g axios If you see 1.14.1 or 0.30.4 anywhere — treat your machine as fully compromised. Rotate every credential immediately: npm tokens, SSH keys, API keys, cloud credentials, database passwords. All of it. Supply chain attacks are not slowing down. The question isn't if another one happens — it's whether you'll be ready when it does. #CyberSecurity #JavaScript #npm #SupplyChainAttack #DevSecOps #OpenSource #WebDev #Axios #Infosec #DeveloperAlert

North Korean state actor Sapphire Sleet compromised the project’s lead maintainer by stealing a long-lived npm access token. #javascript #axios #npm #infosec #devsecops #supplychain #cybersecurity #softwaredevelopment #opensource #technology https://lnkd.in/edGvDK6P

The Axios Supply Chain Attack: Why 100M Downloads Didn’t Protect the Ecosystem One of the most trusted building blocks of the modern web was turned into a delivery vehicle for malware this week. Axios, the HTTP client used in almost every major JavaScript project with over 100 million weekly downloads, fell victim to a highly sophisticated supply chain attack. This wasn't a simple case of "typosquatting" where a developer accidentally types a wrong name. This was a direct hit on a lead maintainer’s account, leading to the release of malicious versions (1.14.1 and 0.30.4) directly to the official npm registry. What makes this incident a critical case study for engineering leaders is how the attacker bypassed our modern security assumptions. For years, we have relied on CI/CD pipelines and SLSA provenance to ensure that the code we run is the code we see on GitHub. In this instance, the attacker bypassed those protections entirely by manually publishing the poisoned versions. There was no corresponding commit on GitHub, no pull request to review, and no CI/CD log to audit. The payload was equally surgical. Instead of modifying the Axios source code—which might have triggered automated scanners looking for sensitive API calls—the attacker simply added a new dependency: plain-crypto-js. This package was a Trojan horse. It sat dormant for 18 hours in a "clean" state to build credibility before being updated with a postinstall hook that deployed a cross-platform Remote Access Trojan (RAT). If your team ran an install or an automated build during the two-hour window on March 31, your environment might be compromised. The malware targets Windows, macOS, and Linux with equal precision, exfiltrating system data and establishing a persistent back-door to a C2 server. We often talk about "shifting left," but this attack proves that even if your own code is perfect, the ground beneath your feet can shift in seconds. Relying on unpinned dependencies or "latest" tags in a production environment is no longer just a bad habit—it is a massive liability. If you haven't checked your lockfiles for axios@1.14.1 or axios@0.30.4, do it now. If you find them, rotating every credential—from AWS keys to npm tokens—is the only safe path forward. Read the full piece here: https://lnkd.in/gpNBYsTa