What happened
The Axios HTTP client, one of the most widely used npm packages in the JavaScript ecosystem, was compromised through a targeted social engineering attack. The maintainer, Jason Saayman, has confirmed that North Korean threat actors tracked as UNC1069 were behind the incident.
The attackers did not exploit a technical vulnerability. They exploited a person.
UNC1069 approached Saayman under the guise of a legitimate founder, building rapport before eventually tricking him with a fake Microsoft Teams error fix. That fix gave them access to his account, which in turn gave them access to publish malicious versions of the Axios package on npm.
This is a textbook supply chain compromise. One trusted maintainer, one convincing pretext, and millions of downstream consumers affected.
Why this matters
Axios is not a niche library. It is a foundational dependency in countless applications, from internal business tools to customer-facing platforms. If your organisation builds software in JavaScript or TypeScript, there is a strong chance Axios sits somewhere in your dependency tree.
The attack highlights several realities that organisations need to take seriously.
Open source maintainers are high-value targets. A single individual often controls the keys to packages used by thousands of organisations. Nation-state actors know this and are investing in sophisticated, personalised social engineering campaigns to exploit it.
Social engineering is getting more precise. Saayman described the campaign as tailored "specifically to me." This was not a spray-and-pray phishing email. It was a carefully constructed approach designed to build trust over time. The fake Teams error fix was the final step in a longer chain of manipulation.
Technical controls alone are not enough. No amount of code scanning would have caught this before the malicious package was published. The compromise happened at the identity and access layer, not in the codebase.
What organisations should consider
- Audit your dependency tree. Know which packages you rely on and who maintains them. Tools like
npm audit, Snyk, and Socket can help identify compromised or suspicious packages.
- Pin your dependencies. Avoid automatically pulling the latest version of any package into production. Use lock files and review updates before merging them.
- Monitor for supply chain indicators. Subscribe to security advisories for your critical dependencies. If a package you depend on is compromised, you need to know within hours, not weeks.
- Treat identity as critical infrastructure. This applies to your own teams as well. Maintainer accounts, CI/CD service accounts, and publishing credentials should all be protected with phishing-resistant MFA and conditional access policies.
- Educate your developers on social engineering. Security awareness training should not stop at finance teams and executives. Developers with publishing rights to package registries or access to build pipelines are prime targets.
Metaphor's perspective
This incident reinforces something we see repeatedly in our security work. The most effective attacks do not brute-force their way in. They persuade someone to open the door.
North Korean threat groups have become highly capable at social engineering, particularly in the software development space. We have seen similar patterns in campaigns targeting cryptocurrency projects, cloud service providers, and SaaS companies.
For organisations that depend on open source, and that is nearly all organisations, supply chain security cannot be an afterthought. It needs to be part of your threat model, your procurement process, and your incident response planning.
If you are unsure where your exposure lies, or whether your current controls would catch a compromised dependency before it reached production, that is a conversation worth having.
Sources: The Hacker News, BleepingComputer