Imagine you maintain one of the most popular libraries in the JavaScript ecosystem. Around 100 million weekly downloads. One day, the founder of a well-known company reaches out. They want to collaborate. They have a Slack workspace with real-looking channels, LinkedIn posts, the whole nine yards. You hop on a video call and the other side says they're having audio issues. Could you install this quick fix?
That "fix" is a remote access trojan. And now a North Korean state actor has full control of your npm account.
That is exactly what happened to Jason Saayman, the lead maintainer of Axios, in late March 2026. The attack, attributed to UNC1069 (also tracked as BlueNoroff and Sapphire Sleet by Microsoft), is one of the most significant software supply chain compromises in recent memory. I believe every developer who relies on open-source packages needs to understand how it worked and what it means going forward.
The Setup: Weeks of Manufactured Trust
UNC1069 did not rush this. According to Saayman's post-mortem and analysis from Google Mandiant, Huntress, and Kaspersky, the attackers spent weeks building rapport before making their move.
Here is what the social engineering operation looked like:
Cloned a real company's identity, including the founder's likeness and branding materials. Saayman described it as targeting him specifically.
Created a fake Slack workspace with plausible CI-style naming, real-looking channels, and LinkedIn posts being shared by "team members."
Scheduled a video call (via Microsoft Teams) and then triggered a fake audio error, prompting the target to install a "fix" that was actually malware.
In Saayman's words: "Everything was extremely well coordinated, looked legit, and was done in a professional manner." The Slack workspace, the cloned founder, the branded materials. All of it was built to withstand scrutiny from someone who is paying attention.
I see this pattern a lot in modern social engineering. The attackers do not need to fool everyone. They need to fool one person, one time, for about thirty seconds.
The Payload: WAVESHAPER and Friends
Once Saayman's machine was compromised, UNC1069 had everything they needed to publish to npm. On March 31, 2026, two malicious versions appeared:
[email protected] (tagged as "latest")
[email protected] (tagged as "legacy")
Both versions injected a dependency called [email protected], which used npm's postinstall hook to execute a dropper. The dropper was clever: it used dual encoding (string reversal plus Base64) followed by XOR encryption with the key OrDeR_7077 to decode its C2 infrastructure details. According to Elastic Security Labs' teardown, the script then reached out to sfrclak[.]com:8000 with HTTP POST requests disguised as npm registry traffic.
What came next was a cross-platform RAT deployment. The malware detected your OS and delivered the right payload:
macOS: CosmicDoor, a Nim-based backdoor (C++ compiled binary for stage 2)
Windows: A Go variant of CosmicDoor plus a PowerShell RAT
Linux: A Python-based RAT implementation
All three variants shared the same C2 protocol: HTTP POST with Base64-encoded JSON, a hilariously outdated user-agent string (IE 8 on Windows XP), 60-second beacon intervals, and support for command execution, binary payload delivery, and filesystem enumeration.
On top of the RAT, a stealer suite called SilentSiphon was deployed to harvest credentials from web browsers, password managers, AWS credentials, keychain access, and registry tokens for npm, GitHub, GitLab, Bitbucket, Yarn, pip, RubyGems, Cargo, and NuGet. Think of it as a vacuum cleaner for developer secrets.
The Blast Radius: Bigger Than You Think
The malicious versions were live for approximately three hours before npm pulled them. Three hours does not sound like much. But consider: Axios gets around 100 million downloads per week. Any project using axios@^1.14.0 or axios@^0.30.0 in its package.json would have auto-resolved to the compromised version on its next npm install. CI/CD pipelines run installs constantly. Every fresh build during that window was at risk.
As Socket's CEO Feross Aboukhadijeh put it bluntly: "2FA doesn't matter. OIDC publishing doesn't matter. Game over."
He is right. And that is the uncomfortable part. We have spent years pushing maintainers toward 2FA, signed commits, and OIDC-based publishing. Those measures protect against credential theft and unauthorized publishing. But when the attacker controls the maintainer's actual machine, those controls become irrelevant. The maintainer is the key, and the attacker already turned it.
Axios Was Not the Only Target
Socket's investigation revealed that UNC1069 ran a coordinated campaign targeting multiple high-impact npm maintainers simultaneously. The confirmed target list includes:
Jordan Harband (ECMAScript polyfills and shims)
John-David Dalton (Lodash creator)
Matteo Collina (Fastify, Pino, Undici lead maintainer)
Scott Motte (dotenv creator)
Pelle Wessman (mocha, neostandard, npm-run-all2, type-fest)
Jean Burellier (Node.js core collaborator, Express contributor)
Think about that list for a moment. Lodash, dotenv, Fastify, mocha. If UNC1069 had compromised even two or three of those maintainers, they would have had a foothold in a staggering percentage of the JavaScript ecosystem. This was a focused, strategic operation, not a scattershot phishing campaign.
The Anti-Forensics Were Impressive
One detail from Elastic's analysis that stood out to me: the dropper cleaned up after itself. It performed fs.unlink() to self-delete, then swapped the malicious package.json with a benign version. If you inspected your node_modules after the fact, you would find no trace of the postinstall script that actually ran. The malware erased the evidence of its own delivery mechanism.
The C2 communications also used a spoofed IE 8 / Windows XP user-agent string. On the one hand, this is an absurdly outdated fingerprint that made detection easier for security teams monitoring network traffic. On the other hand, it tells you something about UNC1069's tooling lineage. These are tools that have been evolving for years.
What Actually Helps
Saayman published his remediation steps, and they are solid. But I want to zoom out and talk about what the broader ecosystem should take away from this.
For individual maintainers
Treat your publishing machine like a production server. If you can publish to npm from it, it deserves the same security posture as any server handling sensitive data. Dedicated hardware or at minimum a hardened VM.
Never install anything during a video call. The "fake audio error" trick is now well-documented. If someone asks you to install a fix during a call, end the call.
Adopt OIDC publishing and immutable releases. These would not have stopped this specific attack. But they narrow the window for future variants and make post-compromise cleanup much faster.
For teams consuming open-source packages
Pin your dependencies. If you had
"axios": "1.14.0"instead of"axios": "^1.14.0", the malicious version would never have been pulled in automatically. The caret range is convenient, but convenience is what this attack exploited.Use lockfiles and verify checksums. A
package-lock.jsonoryarn.lockthat was committed before March 31 would have prevented resolution to the malicious version.Monitor for unexpected postinstall scripts. Tools like Socket, npm audit, and Snyk can flag new postinstall hooks in dependency updates. This dropper's entire delivery depended on postinstall execution.
Run CI builds with --ignore-scripts when possible. If your project does not need postinstall hooks (many do not), disable them. This single flag would have neutered the entire attack chain.
The Bigger Picture
The Axios compromise is a case study in a truth that security professionals have been warning about for years: the weakest link in any system is the human operating it. UNC1069 did not find a zero-day in npm. They did not brute-force a password or steal an API key from a misconfigured S3 bucket. They built a relationship with a real person, manufactured trust over weeks, and exploited a moment of inattention.
Taylor Monahan, a researcher who tracked the campaign, summarized it well: "They social engineer them and take over their accounts. This evolution to targeting [OSS maintainers] is concerning."
I think "concerning" undersells it. Open-source maintainers are now high-value targets for nation-state actors. Many of them are volunteers, working solo, without security teams or incident response plans. The fact that a single person's compromised laptop can propagate malware to millions of downstream installations is a structural problem with how we distribute software. And it is a problem we have known about for a long time without building adequate defenses.
The takeaway is straightforward: if your organization depends on open-source software (and it does), your security model needs to account for the possibility that the package you installed today was published by a compromised maintainer. Pin your dependencies. Audit your lockfiles. Disable postinstall scripts. And treat any unexpected "install this" request during a video call as a red flag, no matter how professional the other side looks.
Written by
Bruno Bonando
Fractional CTO and technology advisor. 23+ years shaping platforms for many companies across Europe and Latin America. Has had leadership roles at REWE, MediaMarktSaturn, Cazoo, and some others.
