Your AI Wrote the Code. The Attacker Wrote the Dependency.

A guide to the axios supply chain attack, the conversations you need to have with your team and why this changes the risk calculation for every organisation that builds or buys AI software

By Dan Tinsley, Founder of DTN Advisory

1 April 2026 - Additional source verification and editorial corrections applied.

When I read the news on Tuesday about the axios compromise, I thought someone had jumped the gun on April Fools. A North Korean threat actor hijacking one of the most popular packages in the entire JavaScript ecosystem through a single compromised credential? On the 31st of March? You could not write it.

Sadly it is very real. So I have spent the last twenty four hours with coffee reading through every blog, advisory, vendor analysis and threat intelligence report published on this so you do not have to. What follows is part executive coaching, part technical reference. The front half is what matters more to me; how to frame this for your leadership team or peers, what conversations need to happen this week and what it means strategically regardless of whether you were directly affected. The technical detail is in the second half for those who want it.

If you are a CISO, a security leader, or someone who has to translate cyber risk into business language for people who control budgets and strategy, this is written for you. If you are a CTO or an engineering leader trying to explain to the board why supply chain security needs investment, send them this. If you are a startup founder who has never heard of npm, read the whole thing. You are probably more exposed than anyone.

TLDR:

If you think your organisation may have been affected, skip straight to What You Should Do Right Now and come back to the analysis after.

One compromised credential. One tampered package. 100 million weekly downloads. A North Korean state nexus threat actor deploying a remote access trojan on developer machines across macOS, Windows and Linux. If your organisation builds or buys software, this one is for you.

What happened: Someone compromised a single set of credentials and used them to poison a software component that most of the internet depends on

Who did it: North Korea group attributed by Microsoft (Sapphire Sleet) & Google (UNC1069) to the same group behind the 3CX attack in 2023

How fast it spread: ~600,000 downloads in three hours according to CyberScoop, citing SANS Institute

Who is exposed: Any organisation that builds or buys software. Present in roughly 80% of cloud and code environments according to Wiz

Why this is not just a cyber problem: If you were affected, engineering stops shipping product while every credential in the environment gets rotated. The security team knew in minutes but the engineering team that pulled the dependency had no idea. That gap between detection and the people who can actually act on it is the real problem. Attribution adds sanctions implications and regulatory notification timelines on top, but even without the geopolitics this is an operational risk that touches engineering, procurement, legal, finance, not just the security team.

How I Would Frame This For Your Leadership Team

Here is how I would frame it. The analogies are deliberate. The detailed strategic context for each conversation is further down the article.

Briefing your CTO: “Imagine we gave a master key to every office in the building to a contractor, and that contractor got robbed. That is what just happened. A core dependency our engineering team relies on was compromised by North Korea. Every credential on affected machines should be treated as stolen. I need to know: can we catch something like this in real time? The exposure window was three hours. If we cannot respond faster than that, we have a gap.”

Briefing your CISO peers: Google attributed this to UNC1069. Same North Korean crew behind the 3CX attack. Socket flagged it in six minutes. The question you should be asking your team: would we have caught this in the exposure window, or would we have found out from Twitter or Bleeping Computer? If the answer is Twitter, that is the gap to close this week.

Briefing your CIO: “Think of it like food safety. The restaurant does not blame the health inspector when a supplier sends contaminated ingredients. Everyone in the kitchen is responsible. Every AI coding tool our teams use pulls in unverified external components automatically. A foreign government just exploited that. This needs shared ownership across engineering, procurement and every team adopting AI tooling. I need you to own this alongside security, not delegate it.”

Briefing your CFO: “Think of this like the water supply in a building. You did not install the pipes, but if someone poisons the water, every floor shuts down. That just happened to a component present in 80% of cloud and code environments. If it hit us: engineering stops shipping, we rotate every credential in the company, we likely need an external IR team at six figures, and we may face notification costs and fines. I need funding for supply chain security tooling. The cost is a rounding error compared to the alternative.”

Briefing your Risk lead: “Think of it like insuring a building. You would not let facilities assess fire risk alone when the tenants are storing flammable materials. Same here. Third party software risk needs re rating and shared ownership. A sanctioned nation state just compromised a component most of the internet depends on. Three incidents in seven months. The current rating of medium with quarterly review does not match the threat velocity. I need us to re rate, assign cross functional ownership and agree a response timeline.”

Briefing your Legal team: “Imagine a foreign intelligence service was caught inside our building with access to filing cabinets containing customer records. That is the digital equivalent. Two things need your attention now. Notification obligations may start immediately, not when forensics are complete. And the sanctions angle is real. A sanctioned entity accessing our systems has implications beyond data protection law. I need you to scope this with us today.”

Briefing your Board: “Think of our software supply chain like a shipping port. Thousands of containers come through every day. We trust most of them because they come from known suppliers. North Korea just poisoned one of the most commonly shipped containers on the internet by stealing a single set of credentials. Third time in seven months. If we were affected: product delivery stops, we bring in external specialists, and we may need to notify customers and regulators. This is a national security threat landing on commercial infrastructure. We need to discuss whether our investment in supply chain security matches the risk we are carrying.”

Briefing your dog: You are a very good boy and none of this is your fault. But maybe stop chewing on the laptop that has axios installed.

What Happened and Why It Matters

At 23:59 UTC on 30 March 2026, someone published a package called plain-crypto-js to npm. It had never existed before. It contained a remote access trojan disguised as a postinstall script.

Eighteen hours later, two new versions of axios appeared. axios@1.14.1 at 00:21 UTC. axios@0.30.4 at 01:00 UTC. Both injected plain-crypto-js as a runtime dependency. Neither version went through GitHub. Neither went through code review. Neither triggered a pull request. The attacker had compromised the npm credentials of a lead maintainer, changed the account email to a Proton Mail address and published directly through the npm CLI.

On 31 March 2026, Google Threat Intelligence Group attributed the attack to UNC1069, a North Korean financially motivated threat actor that has been active since at least 2018. Microsoft Threat Intelligence independently attributed the same attack to Sapphire Sleet, their designation for the same North Korean state actor. The malware deployed was identified as WAVESHAPER.V2, an updated version of a backdoor previously used in North Korean operations. This is not some script kiddie having a go. This is the same group linked to the 3CX supply chain attack in 2023, one of the most significant supply chain compromises in recent history.

Axios is not some obscure library. It is one of the most used packages in the entire JavaScript ecosystem. Around 100 million downloads per week. Present in roughly 80% of cloud and code environments according to Wiz. CyberScoop reported approximately 600,000 downloads during the three hour exposure window, citing SANS Institute faculty fellow Joshua Wright. If your organisation builds software, it is almost certainly in your dependency tree somewhere. Probably in more places than you think.

StepSecurity, who identified the compromise alongside Socket, called it “among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package.” They are not wrong. The attack was not a smash and grab. The malicious dependency was staged 18 hours before the axios versions that pulled it in. Both release branches, the current 1.x and the legacy 0.x, were poisoned within 39 minutes of each other. Three separate RAT payloads were pre built for macOS, Windows and Linux. After execution, the dropper deleted itself and replaced its own package.json with a clean copy. Evidence destruction was part of the design.

By 03:29 UTC, both malicious versions were pulled from npm. Three hours of exposure. In that window, any developer or build system that ran npm install on a project with axios as a dependency could have pulled the compromised version and executed the trojan.

The numbers back this up. Wiz observed a 3% execution rate across affected environments. Huntress reported detecting compromised systems among their customers during the exposure window. Do the maths on your own estate.

It Was North Korea. That Changes the Risk Calculation.

The attribution changes everything.

When this looked like a lone attacker or a criminal group, it was a supply chain security problem. Now that Google Threat Intelligence Group has attributed it to UNC1069, a North Korean state nexus threat actor, it is a national security problem landing on commercial infrastructure.

John Hultquist, who leads threat intelligence analysis at Google, put it clearly: “Korean hackers have deep experience with supply chain attacks, which they’ve historically used to steal cryptocurrency.” Charles Carmakal, Mandiant’s CTO, went further: “The secrets stolen over the past two weeks will enable more software supply chain attacks” and ransomware operations. Read that again. The secrets your developers had on those machines, the SSH keys, the cloud credentials, the API tokens, those are now potential ammunition for the next attack.

Your risk register probably does not capture what comes next…

The threat actor is persistent and well resourced. UNC1069 has been operating since at least 2018. They are not opportunistic criminals who got lucky. They have a track record of targeting supply chains, cryptocurrency platforms and developer infrastructure (often via Linkedin). Their 3CX compromise in 2023 was a supply chain attack used to deliver another supply chain attack. They build campaigns that compound.

North Korea uses cyber operations to generate revenue. According to a UN Panel of Experts report, North Korean cyber theft totalled approximately $3 billion between 2017 and 2023, most of it funding weapons programmes. When your developers’ credentials end up in North Korean hands, you are not just dealing with a data breach. You are potentially contributing to sanctions evasion and weapons proliferation. That is a conversation your legal team needs to have, especially if you operate in regulated sectors or deal with government contracts.

The tradecraft was professional but not exotic. WAVESHAPER.V2 is competent malware but it is not a zero day exploit chain. The initial access was a compromised credential. The distribution channel was npm’s trust model. The lesson here is not that North Korea has “magical capabilities”. It is that the open source ecosystem has structural weaknesses that nation states can exploit with relatively modest effort. That should concern you more, not less, because it means the barrier to entry for this kind of attack keeps dropping.

Think of it this way. If someone broke into your office and stole a laptop, that is a police matter. If a foreign intelligence service broke into your office and stole a laptop, you would be on the phone to your government’s cyber agency, your lawyers, your insurance provider and probably your board. The technical impact might be identical. The risk implications are completely different. That is the shift this attribution represents.

What Every Leader Needs to Discuss This Week

The briefings above give you the language. This section gives you the strategic context behind those conversations what to push for, why it matters beyond the incident itself and where the real gaps are. Do not forward this to security and move on. The axios compromise touches every part of the organisation. These are the conversations that need to happen.

Your CTO and engineering leadership need to answer a specific question: do we have visibility into what our build pipelines are pulling and can we respond within hours, not days? If the answer is “we would have found out eventually,” that is not good enough when the exposure window is three hours. Engineering owns the dependency decisions. They need to own the risk that comes with them too.

Your CIO needs to understand the infrastructure exposure. Developer machines are not just code editors. They are connected to cloud consoles, internal wikis, CI/CD systems, container registries and production infrastructure. A RAT on a developer laptop is a pivot point into everything that developer has access to. CIOs who treat developer endpoints as lower risk than production servers are making a mistake this attack just proved.

There is a harder conversation here too. I have worked with organisations running 40 plus AI tools across the business. Every quarter, every vendor is pushing AI in their business reviews. Marketing wants an AI content tool. Finance wants AI powered forecasting. HR wants an AI recruitment screener. Operations wants AI workflow automation. And a lot of it delivers genuine value. I have seen significant cost savings from AI adoption across operations, financial modelling and marketing. My job as a security leader is to support the business running effectively and securely, not to say no to everything. But every one of those tools introduces dependencies, integrations and attack surface that somebody needs to understand. When “let’s just AI tool it” becomes the default answer to every problem, and nobody is asking what packages those tools pull in or what access they require, you are building on a foundation you have never inspected. This attack is what happens when that catches up with you.

Your CFO has probably never been briefed on npm. Start with the ROI: supply chain security tooling costs money. Socket, Snyk, Aikido, these are not free. But the cost of not having them is a credential rotation across your entire engineering team, an incident response engagement, potential notification costs and possible regulatory fines. Frame it simply. You would not let your finance team use unaudited spreadsheets to process payments. Why are you letting your engineering team use unaudited dependencies to build your product?

Your Legal and compliance team needs to consider the sanctions angle. The attack has been attributed to a North Korean government backed group. Depending on your jurisdiction, there may be reporting obligations related to sanctions exposure. If customer data was potentially accessible from compromised systems, notification timelines start now, not when the forensics are finished. Joshua Wright from SANS warned that stolen credentials could pivot to AWS accounts and GitHub repositories, expanding the potential data exposure significantly.

Your Risk and governance team needs to update the risk register. “Third party software risk” sitting at medium with a quarterly review cycle is not adequate when a sanctioned nation state just demonstrated it can compromise a package present in 80% of cloud and code environments. This needs re rating with the new attribution context and the actual blast radius data from Wiz.

Media and communications should already have a holding statement drafted. If this becomes public, either through your own disclosure, regulatory requirement or because a journalist calls, you want to be ahead of it. The statement should acknowledge awareness of the axios supply chain compromise, confirm your organisation has taken appropriate steps and note that investigation is ongoing. Do not wait until you are surprised.

What This Actually Means For Your Environment

Say you have 500 developers and 200 active repositories. Most have axios in the dependency tree somewhere. During the three hour window, any CI/CD pipeline, any npm install, any automated build would have pulled the compromised version. The postinstall script executes automatically. No user interaction. The RAT deploys, connects to C2 and starts beaconing every 60 seconds.

Now think about what lives on those machines. SSH keys. Cloud credentials. API tokens. Source code. Secrets in environment files. Forget credential stealer. This is a full access toolkit deployed by a nation state.

Carmakal’s warning bears repeating the secrets stolen from these machines will enable more attacks. Not a one and done incident. It is the reconnaissance phase for what comes next. The framing for your executive team is not “we have a vulnerable dependency.” It is “a North Korean threat actor may have had full access to our development infrastructure for up to three hours and we need to determine what they took and what they can do with it.”

The Vibe Coding Problem and Why Small Companies Are Most Exposed

Everyone is vibe coding right now. Cursor, Claude Code, Copilot, Lovable, Bolt. Developers are describing what they want in natural language and AI generates the code. The features ship. The demos look great. The startup launches in a weekend.

Nobody reads the dependency tree.

A team I know well, Unit 42 at Palo Alto Networks published research this month showing that most organisations have no formal risk assessment for vibe coding tool usage. The AI models are optimised for function. They generate working code fast. They are not checking whether the package they just imported has a maintainer whose credentials were stolen twelve hours ago. Research from multiple sources including Checkmarx and Black Duck suggests that a significant proportion of AI generated code contains security vulnerabilities. Both have published analyses showing that vibe coding introduces dependency risks that traditional code review was never designed to catch. There is no human in the loop who understands what was imported or why.

In February 2026, a social networking site called Moltbook, built entirely through vibe coding, got breached. Wiz Research found 1.5 million API authentication tokens and 35,000 email addresses exposed through a misconfigured Supabase database. The founder disclosed on social media that he had not personally written any of the platform’s code, relying entirely on an AI assistant. The application worked. The security did not.

Now think about who is most exposed here.

The coverage of supply chain attacks always focuses on enterprises. Big companies with security teams and budgets and incident response plans. But axios is not just used by banks and tech giants. It is used by every startup that has ever made an HTTP request from JavaScript. Every small business that hired a freelancer to build their website. Every agency that scaffolded a client project from a template. My own mother could load up Claude code and launch a web app and be none the wiser.

These organisations do not have a SOC. They do not have a CISO. They probably do not have anyone who knows what npm is. Their “security programme” is hoping nothing bad happens and trusting that the tools they use are safe.

A startup founder who vibe coded their MVP in a weekend would have had no idea that axios was in their project, let alone that it had been compromised by North Korea. They would not know to check. They would not know what to look for. They would not have the context to understand the advisory even if they saw it.

Connect the dots. Every developer who ran npm install during that three hour window extended a North Korean threat actor’s access into their environment. If they were vibe coding, they almost certainly had no idea what axios was. It was a dependency of a dependency. A line in a lockfile they never opened. A trust decision they did not know they were making.

And that is the multiplier nobody is talking about. AI tools are democratising software development and that is broadly a good thing. But they are also democratising exposure to supply chain attacks and nobody is building the guardrails for the people who need them most.

The new attack surface is not the code your engineers write. It is the code they import without understanding. Every AI tool that makes software development faster is also making that surface bigger and harder to see.

If you are a small company reading this: run the commands in the “What You Should Do” section below. If you have no idea what those commands mean, find someone who does. You cannot deal with this later when the threat actor is a nation state.

What Has Happened Before and What We Can Learn

npm trust has been exploited to deliver malware before. Many times.

The event-stream incident in 2018 was the early warning. A maintainer handed off a popular package to a stranger who injected a targeted attack against the Copay bitcoin wallet. The ua-parser-js compromise in 2021 hit a package with 8 million weekly downloads. The colors and faker sabotage in 2022 showed that even intentional maintainer actions can break the supply chain at scale. The 2024 xz Utils backdoor was arguably the most sophisticated supply chain attack in open source history, where an attacker spent two years gaining trust before injecting a backdoor into a core Linux compression library.

And then there is 3CX. In 2023, North Korean hackers compromised the 3CX desktop application, a supply chain attack that was itself enabled by a previous supply chain attack on Trading Technologies. That is a supply chain attack built on top of another supply chain attack. The same cluster of activity, the same nation state, now hitting npm with WAVESHAPER.V2.

But here is the part that should worry you more than the history. The last seven months have seen three major npm supply chain compromises, all starting with stolen maintainer credentials. In September 2025, the Shai-Hulud worm hit npm. A single phished maintainer account self replicated across more than 500 packages, harvesting npm tokens, cloud credentials and GitHub secrets as it spread. In January 2026, Koi Security’s PackageGate research dropped six zero day vulnerabilities across npm, pnpm, vlt and Bun that punched through the very defences the ecosystem adopted after Shai-Hulud. Then axios on 31 March.

Three incidents. Seven months. Every single one started the same way: a compromised credential gave an attacker publishing rights to a trusted package.

After Shai-Hulud, npm overhauled its entire authentication model. Classic tokens were deprecated. Granular access tokens with seven day expiry became mandatory for publishing. FIDO based two factor authentication was required. Trusted publishing via OIDC from GitHub Actions was introduced. Sound familiar? Every enterprise has a version of this story where the new policy is in place but the legacy exception is still live. On paper, the problem was solved. In practice, the axios publish workflow still had a long lived NPM_TOKEN sitting as an environment variable, and that token bypassed every one of those new controls. The attacker did not need to defeat the new security model. They just used the old one that was still lying around.

The pattern is not just repeating. It is accelerating. And the fixes keep failing to hold because they address the mechanism without addressing the structural problem: a single credential remains the only thing standing between a trusted package and a global compromise.

Countermeasures That Actually Work

Generic advice like “improve your supply chain security” changes nothing and get filed under nice to have. Here is what actually works from my experience.

Immediate technical controls:

Use npm ci --ignore-scripts in CI environments. This blocks postinstall script execution, which is exactly how the axios RAT deployed. Yes, it will break some legitimate packages. That is a conversation worth having with your engineering team. The tradeoff between “some packages need manual setup” and “a nation state can execute arbitrary code through your build pipeline” is not a close call.

Set a minimum release age:

npm config set min-release-age 3

blocks any package published less than three days ago from being installed. This single setting would have stopped the axios attack cold. The compromised versions were live for three hours. A three day cooling off period means your systems never see a poisoned package before the community catches it.

A trusted peer in app security (Thanks Nick!) made a fair point when I discussed this. Some best practice advice sounds tidy on paper and then gets messy fast in large, complex estates. The better control is often not pretending you can perfectly inspect every package at scale. It is slowing the spread, forcing packages through an internal source of truth, watching the feeds that matter, blocking known bad packages early and knowing exactly where a dependency has travelled once it lands.

That means putting a cooling off period in front of packages coming through your approved internal repo, not letting every laptop, dev team or pipeline pull direct from the internet. It means watching sources like OSV and your own tooling closely enough to stop malicious or badly vulnerable packages entering the estate in the first place. It means having proper inventory so if something goes toxic you know whether it hit JFrog, CI, a developer endpoint, UAT or prod. And it means prod should not be reaching out to the internet unless there is a genuinely solid reason.

That is less brash than shouting about signatures and hashes in a slide deck, but it is far more useful when something goes wrong at 2am.

Pin your dependencies properly. Commit your lockfiles. Review lockfile diffs as part of code review. If nobody on your team is looking at what changed in the lockfile when dependencies update, you have a structural blind spot that endpoint detection will never cover.

Deploy a supply chain security scanner. Socket, Snyk, Aikido. These are not nice to have. Socket flagged this attack in six minutes. Six. If your organisation had Socket integrated into your pipeline, you would have known before the axios versions were even published. That is the difference between “we caught it” and “we are rotating every credential in the company.”

Organisational controls:

Establish a supply chain alert channel that bridges security and engineering (AKA Fusion Model I’ve talked about before). When Socket or Snyk publishes an advisory for a package in your dependency tree, that alert needs to reach someone who can act on it within the hour. Not get filed in a JIRA backlog. Not wait for the weekly triage meeting. The exposure window was three hours. Your response time needs to be faster than that.

Run a tabletop exercise for supply chain compromise. Most incident response plans were written for phishing and ransomware. Walk your team through this scenario: “A critical dependency has been compromised. The compromised version was live for three hours. 200 of our developers may have installed it. Go.” If your team cannot articulate who does what in that scenario, you have a gap that will cost you when it happens for real.

Strategic controls:

Treat open source dependencies as third party suppliers. You would not let an unvetted vendor plug directly into your production infrastructure. But that is exactly what npm install does. Start applying the same due diligence framework to critical dependencies that you apply to critical vendors: who maintains it, how is it funded, what happens if the maintainer’s account gets compromised.

Fund the open source you depend on. Not charity. Risk management. Packages maintained by a single person working for free on weekends are the soft targets. The ones with funding, governance and security practices are harder to compromise. If axios is critical to your business, you should care about the security of the people who maintain it.

If You Are in Singapore or APAC, Read This

The Cyber Security Agency of Singapore issued a formal advisory on the axios compromise (AD-2026-002). If you operate in Singapore, that advisory is not optional reading. It is the government telling you this matters.

Singapore sits at the centre of APAC’s tech ecosystem. The startup density here is enormous. The number of organisations running JavaScript stacks built by small teams, outsourced developers or vibe coding founders is higher per capita than almost anywhere. Every coworking space in One North and Launchpad i’ve had coffee in has someone running npm install right now without thinking twice about what it pulls in.

If you are a Singapore based organisation, you should be checking your exposure against the CSA advisory and reporting through the appropriate channels if you were affected. If you are subject to MAS Technology Risk Management Guidelines, a supply chain compromise attributed to a sanctioned nation state is exactly the kind of event that requires documented assessment and potential notification. Do not assume this only matters for US companies. The attacker did not check your jurisdiction before deploying the RAT.

For organisations across APAC more broadly: the exposure window hit between 08:21 and 11:29 SGT on 31 March. That is the middle of a working morning. If your developers were online and your pipelines were running, the timing was not in your favour. Check your build logs for that window specifically.

The Gap That Keeps Showing Up

I keep seeing the same pattern across incidents like this, and it gets worse the bigger the organisation.

The SOC is watching network traffic and endpoint alerts. Engineering is pulling dependencies and shipping code. Risk is maintaining a register that gets updated quarterly. Legal is waiting for someone to tell them there is a problem. None of them are talking to each other about what just happened.

In military terms, think of it like the air force and the infantry operating in the same battlespace but looking at different maps. If you do not know what is on the ground, you cannot defend it. If your security team does not have a software bill of materials, if they do not know what dependencies your developers are building on, they are defending an environment they cannot see. The SOC can monitor every endpoint and every network flow, but a compromised npm postinstall script executing on a developer laptop during a CI/CD build sits in a gap that neither the SOC nor the engineering team was built to cover on their own. This attack lives in that gap. It is not a network intrusion. It is not a phishing email. It is a trusted package doing exactly what trusted packages are supposed to do, except the trust was stolen.

The problem is wiring, not tools. The information exists. The detection exists. The analysis exists. What does not exist in most organisations is the connective tissue that gets the right information to the right person fast enough to make a decision - I call this decision velocity. I wrote about this in my previous article on intelligence fusion. The same structural problem that stops threat intelligence reaching the people who need it also stops a supply chain alert reaching the engineer who can act on it.

That does not require a massive organisational restructure. It requires some basics. A shared channel where security and engineering alerts land. A defined escalation path for supply chain events. Someone whose job it is to watch the feeds that matter. An agreement about what constitutes “act now” versus “review tomorrow.”

The organisations getting this right are not doing anything exotic. They are just doing the basics consistently. They have someone watching Socket or Snyk alerts. They have a software bill of materials that gets maintained, not filed. They have a process for validating unexpected dependency changes. They have engineers and security people who actually talk to each other, not once a quarter, but when something happens.

The lesson is simple. You do not need to build a threat intelligence fusion centre to handle supply chain risk. You need to wire the people and processes you already have so that a six minute detection does not become a three week discovery.

What You Should Do Right Now

Immediate Actions

Check whether axios@1.14.1 or axios@0.30.4 exists anywhere in your environment. That means production, staging, development, CI/CD runners, feature branches and open pull requests that have not been merged yet. Run this:

grep -E ‘”axios”’ package-lock.json | grep -E ‘1\\.14\\.1|0\\.30\\.4’
npm ls plain-crypto-js
find node_modules -name “plain-crypto-js” -type d

​

Pin to the safe versions immediately: axios@1.14.0 for the 1.x branch, axios@0.30.3 for the 0.x branch. Block sfrclak[.]com and 142.11.206.73 at your network layer.

Do not stop at axios. Two additional packages carried the same payload: @shadanai/openclaw (versions 2026.3.31-1 and 2026.3.31-2) and @qqbrowser/openclaw-qbot@0.0.130. The attacker hedged across multiple distribution channels. If your threat hunt only covers the axios versions, you are not looking broadly enough.

If You Installed the Compromised Versions

Assume full compromise. Re-image or restore from a verified clean backup taken before 30 March 2026. Do not just remove the package and carry on. The RAT had arbitrary code execution and process injection capabilities. You do not know what else was dropped. Rotate all credentials on affected systems: npm tokens, AWS access keys, SSH private keys, cloud credentials, API keys and database passwords. Everything.

Hunt for RAT artefacts at these paths:

macOS: /Library/Caches/com.apple.act.mond

Windows: %PROGRAMDATA%wt.exe and the MicrosoftUpdate registry Run key

Linux: /tmp/ld.py

Monitor for outbound connections to 142.11.206.73:8000. Check for the User Agent string mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0) in your proxy logs. If you find it, this is a full incident. Given the DPRK attribution, consider engaging your national cyber security agency.

For Your CI/CD Environments

Use npm ci --ignore-scripts in CI environments to block postinstall script execution. Pin your dependencies. Commit your lockfiles. If you are not already using a supply chain security tool like Socket, Snyk or Aikido, today is the day to start.

The Technical Details

For those who want the full breakdown, here is the magic in the tradecraft.

Account Compromise: The attacker obtained a long lived classic npm access token for the jasonsaayman account. The registered email was changed to ifstap@proton.me. The GitHub account was not compromised. The attacker went straight to the distribution channel, bypassing the source code repository entirely. They did not attack the factory. They stole the keys to the delivery truck.

Attribution: Google Threat Intelligence Group attributed the attack to UNC1069, a North Korean state nexus financially motivated threat actor active since at least 2018. The same cluster is linked to the 2023 3CX supply chain compromise. Microsoft Threat Intelligence independently attributed the attack to Sapphire Sleet, their designation for the same actor. The malware deployed is tracked as WAVESHAPER.V2, an updated version of the WAVESHAPER backdoor previously used in North Korean cyber operations. Elastic Security Labs published independent analysis confirming the cross platform RAT capabilities.

Payload Obfuscation: The postinstall script (setup.js) used a two layer encoding scheme. An array of 18 command strings was first reversed and Base64 encoded, then XOR encrypted with the key OrDeR_7077 using a constant value of 333. Not sophisticated cryptography. But enough to defeat static scanners and a quick eyeball review.

Platform Payloads:

macOS: AppleScript dropper downloaded a C++ Mach-O universal binary from sfrclak.com:8000. Dropped to /Library/Caches/com.apple.act.mond (disguised as an Apple system process). Self signed using codesign --force --deep --sign to bypass Gatekeeper.

Windows: VBScript chain spawned PowerShell, downloaded stage2.ps1, wrote the executable to %PROGRAMDATA%wt.exe (disguised as Windows Terminal). Established registry persistence via a Run key named MicrosoftUpdate. Also dropped a batch file to re download the payload if deleted.

Linux: Python script dropped to /tmp/ld.py.

C2 Infrastructure: All payloads connected to sfrclak[.]com on port 8000, IP 142.11.206.73, campaign path /6202033. The RAT generated a 16 character victim ID and beaconed every 60 seconds with a spoofed User Agent: mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0). Internet Explorer 8 on Windows XP. In 2026. Make of that what you will.

RAT Commands: Four remote commands identified. peinject: downloads and injects binaries into running processes with code signing bypass. runscript: executes arbitrary shell commands or AppleScript. rundir: enumerates /Applications, ~/Library and application support directories. kill: terminates the RAT process.

Forensic Countermeasures: After deployment, the dropper deleted setup.js, removed the malicious package.json and replaced it with a clean stub. Evidence destruction built into the attack chain from the start.

Map This

For CTI analysts: this maps cleanly to established frameworks.

Cyber Kill Chain: Reconnaissance (high value target identification). Weaponisation (cross platform RAT with C2, WAVESHAPER.V2). Delivery (compromised credential, trusted distribution channel). Exploitation (npm postinstall auto execution). Installation (OS specific persistence). Command and Control (sfrclak.com:8000). Actions on Objectives (arbitrary execution, process injection, enumeration, credential theft enabling future operations).

MITRE ATT&CK: T1195.002 (Compromise Software Supply Chain). T1059 (Command and Scripting Interpreter: PowerShell, AppleScript, VBScript, Python). T1547.001 (Registry Run Keys). T1036 (Masquerading). T1070 (Indicator Removal).

Threat Actor: UNC1069 (UNC1069 (Google/Mandiant designation) / Sapphire Sleet (Microsoft designation). North Korea nexus. Financially motivated. Active since 2018. Previously linked to 3CX supply chain compromise (2023). Malware family: WAVESHAPER.V2.

My previous article covers the intelligence tradecraft and frameworks referenced here: Your Threat Intelligence Team Is Collecting Data and Calling It Intelligence

Dan Tinsley is the founder of DTN Advisory, providing cybersecurity, resilience and intelligence advisory services from Singapore across the Asia Pacific region.

dtnadvisory.com

Indicators of Compromise

IndicatorTypeNotesaxios@1.14.1Malicious packageSHA256: 5bb67e88846096f1f8d42a0f0350c9c46260591567612ff9af46f98d1b7571cdaxios@0.30.4Malicious packageSHA256: 59336a964f110c25c112bcc5adca7090296b54ab33fa95c0744b94f8a0d80c0fplain-crypto-js@4.2.1Malicious dependencySHA256: 58401c195fe0a6204b42f5f90995ece5fab74ce7c69c67a24c61a057325af668sfrclak[.]comC2 domainPort 8000, path /6202033142.11.206.73C2 IPAssociated with sfrclak.com/Library/Caches/com.apple.act.mondmacOS RATSHA256: 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a%PROGRAMDATA%wt.exeWindows RATPersistence via MicrosoftUpdate Run key/tmp/ld.pyLinux RATSHA256: fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cfmozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)User AgentRAT beacon identifier@shadanai/openclawSecondary vectorVersions 2026.3.31-1 and 2026.3.31-2@qqbrowser/openclaw-qbot@0.0.130Secondary vectorContains tampered axiosUNC1069Threat actorNorth Korea nexus, active since 2018, GTIG/Mandiant designationWAVESHAPER.V2Malware familyUpdated backdoor, attributed to UNC1069

Sources

Google Threat Intelligence Group — Attribution to UNC1069 (North Korea), WAVESHAPER.V2 identification. https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package

Elastic Security Labs — Independent cross platform RAT analysis. https://www.elastic.co/security-labs/axios-one-rat-to-rule-them-all

CyberScoop — ~600,000 downloads during exposure window. https://cyberscoop.com/axios-software-developer-tool-attack-compromise/

The Record — Google links axios attack to North Korea. https://therecord.media/google-links-axios-supply-chain-attack-north-korea

Socket Security — Original detection and technical analysis. Flagged within six minutes. https://socket.dev/blog/axios-npm-package-compromised

Feross Aboukhadijeh (Socket) — Original public disclosure on X/Twitter.

Feross@feross

🚨 CRITICAL: Active supply chain attack on axios -- one of npm's most depended-on packages. The latest axios@1.14.1 now pulls in plain-crypto-js@4.2.1, a package that did not exist before today. This is a live compromise. This is textbook supply chain installer malware. axios

2:35 AM · Mar 31, 2026 · 11.9M Views

---

533 Replies · 4.08K Reposts · 16.3K Likes

Wiz — Cloud impact analysis. 80% of cloud environments affected, 3% execution rate. https://www.wiz.io/blog/axios-npm-compromised-in-supply-chain-attack

Aikido Security — Detailed technical analysis of account hijack and payload delivery. https://www.aikido.dev/blog/axios-npm-compromised-maintainer-hijacked-rat

Snyk — Independent analysis with full IOC table and RAT command breakdown. https://snyk.io/blog/axios-npm-package-compromised-supply-chain-attack-delivers-cross-platform/

StepSecurity — Confirmed compromised versions and remediation guidance. https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan

Unit 42 (Palo Alto Networks) — Research on vibe coding security risks. https://unit42.paloaltonetworks.com/securing-vibe-coding-tools/

GitHub Issue #10590 — Community reported issue. https://github.com/axios/axios/issues/10590

GHSA-fw8c-xr5c-95f9 — GitHub Security Advisory.

Huntress — Detection of compromised systems during exposure window. https://www.huntress.com/blog/supply-chain-compromise-axios-npm-package

Cyber Security Agency of Singapore — Advisory AD-2026-002. https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-002/

VentureBeat — Axios compromise impact analysis and Huntress data. https://venturebeat.com/security/axios-npm-supply-chain-attack-rat-maintainer-token-2026

SOCRadar — CISO remediation guide with re-imaging guidance. https://socradar.io/blog/axios-npm-supply-chain-attack-2026-ciso-guide/

The Hacker News — npm authentication overhaul timeline post Shai-Hulud. https://thehackernews.com/2026/02/npms-update-to-harden-their-supply.html

Microsoft Security Blog — Independent attribution to Sapphire Sleet, mitigation guidance. https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/

Disclaimer

The information in this article is provided for general informational purposes only and reflects the author’s analysis of publicly available frameworks, policies and data as of the date of publication. It does not constitute legal, regulatory, tax or professional cybersecurity advice. Organisations should seek independent professional advice before acting on any of the information contained here. DTN Advisory accepts no liability for any loss or damage arising from reliance on the content of this article. All references to government frameworks, deadlines and programmes are based on published sources and may be subject to change.