Skip to main content

North Korean Hackers Suspected in Supply Chain Attack on Popular Axios Project

open source, software, security, open-source, Lineaje, Linux, open source, report, study, Open source code
open source, software, security, open-source, Lineaje, Linux, open source, report, study, Open source code

North Korean hackers are accused of hijacking the npm account of an axios maintainer, a highly popular and widely used JavaScript HTTP client library, in the latest in a growing number of sophisticated attacks targeting open-source software developers.

For a brief few hours running from late March 30 into early March 31, the bad actors were able to hijack the npm account of the primary axios maintainer and publish two new malicious versions – “axios@1.14.1” and “axios@0.30.4” – that introduced a hidden runtime dependency, plain-crypto-js@4.2.1.

When a developer or CI/CD pipeline ran the npm install, the dependency installed a remote access trojan (RAT) that contacted a command-and-control (C2) server and dropped secondary payloads targeting macOS, Windows, and Linux systems, according to researchers for StepSecurity, one of several security vendors that analyzed the attack.

The RAT is capable of a range of threats, from running arbitrary commands to exfiltrating system data to establishing persistence on infected machines, according to Socket researchers. After executing, the malware automatically deleted itself, covering its tracks to make detection more difficult.

Broad Blast Radius

The broad adoption of axios, which offers a simple and feature-rich way to manage HTTP requests in browser-based and Node.js environments, in the industry is a significant factor in the attack. The library is downloaded more than 100 million times a week, it’s used in web applications, APIs, React Native mobile apps, serverless functions, CI/CD automation pipelines, and developer workstations, and is a transitive dependency in thousands of other packages, “meaning your organization may be using it even if no developer explicitly installed it,” SOCRadar researchers wrote.

“The blast radius of yesterday’s Axios npm supply chain attack is broad and extends to other popular packages that have dependencies on it,” Charles Carmakal, CTO of Google’s Mandiant business, wrote on LinkedIn. “Enterprises should assess the impact today.”

Austin Larsen, principal threat analyst for Google Threat Intelligence Group (GTIG), urged organizations to check if they’ve been compromised, writing that “if your environment recently pulled axios@1.14.1 or axios@0.30.4, you may have executed a backdoor payload via the malicious plain-crypto-js dependency.”

A Sophisticated Attack

Security researchers describe an attack that was meticulously planned and launched. The hackers compromised the npm account of Jason Saayman, the primary axios maintainer, and changed the account’s email to a ProtonMail address they controlled. That made it difficult for other Axios collaborators to stop the attack.

“When the attack first happened, Axios maintainers were unable to regain control of the project,” Socket researchers wrote. “In a public GitHub issue, a collaborator stated they could not revoke access from the account responsible for the malicious publish, noting that the attacker’s permissions exceed their own.”

StepSecurity analysts wrote that “there are zero lines of malicious code inside axios itself, and that’s exactly what makes this attack so dangerous. … This was not opportunistic. It was precision. The malicious dependency was staged 18 hours in advance.”

Pre-Built Payloads

They noted the three payloads were pre-built for the three operating systems, both release branches were poisoned within 39 minutes of each other, and that every artifact in the attack was able to self-destruct.

“Within two seconds of npm install, the malware was already calling home to the attacker’s server before npm had even finished resolving dependencies,” they wrote. “This is among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package.”

GTIG Points to North Korean Actor

Initial threat intelligence reports said the attack was pulled off by an unknown threat actor. However, GTIG analysts later attributed it to a North Korean group they track as UNC1069.

“North Korean hackers have deep experience with supply chain attacks, which they’ve historically used to steal cryptocurrency,” GTIG Chief Analyst John Hultquist wrote. “The full breadth of this incident is still unclear, but given the popularity of the compromised package, we expect it will have far-reaching impacts.”

Hultquist added that the attacks were not related to a series of supply chain attacks by Team PCP targeting developers that has been expanding over the last few weeks.

Popular Doesn’t Mean Trustworthy

Ilkka Turunen, field CTO at DevSecOps firm Sonatype, said the attack shows that bad actors “don’t need to compromise the code people trust if they can compromise the trust around it. In this case, the malicious capability was introduced through a staged dependency and designed to erase its own tracks, which made the attack harder to spot and slower to understand.”

Turunen noted how little visible change was needed to create significant downstream risk.

“When a widely trusted package can be turned into a delivery path like this, the issue is bigger than package hygiene,” he said. “It’s a trust problem in the software supply chain, and it’s why organizations need security controls that look at what’s actually being installed, not just what appears safe at first glance.”

Nigel Douglas, head of developer relations at Cloudsmith, a managed cloud-native artifact repository, said that developers need to understand that you can’t treat popularity as a proxy for trustworthiness. Just because a package has over 100 million weekly downloads, that doesn’t mean it can be trusted by default, and – in fact – that might just make it a bigger target. The software supply chain relies on the hard work of open-source maintainers, but they can’t be everywhere, and upstream repositories like npm are always a high-value target for attackers.”



from DevOps.com https://ift.tt/uJVv02x

Comments

Popular posts from this blog

Gremlin Adds Detected Risk Tool to Chaos Engineering Service

Gremlin's risk detection capability in its chaos engineering service automatically identifies issues that could cause outages along with recommendations to resolve them. from DevOps.com https://ift.tt/iaw9Q7D

Five Great DevOps Job Opportunities

DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience. Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so […] from DevOps.com https://ift.tt/7hqsg6o

Java 26 Arrives With AI Integration and a New Ecosystem Portfolio — What It Means for DevOps Teams

Oracle released Java 26 on March 17, 2026, and while every six-month release comes with its own set of improvements, this one carries a broader message: Java isn’t just keeping pace with the AI era — it’s actively positioning itself as the infrastructure layer where AI workloads will run. For DevOps teams managing large Java estates, that’s worth paying attention to. The Scale of What You’re Already Running Before getting into what’s new, it helps to remember what’s already in place. According to a 2025 VDC study, Java is the number one language for overall enterprise use and for cloud-native deployments. There are 73 billion active JVMs running today, with 51 billion of those in the cloud. That scale matters when you’re thinking about where AI fits in. Most of the systems where agentic AI will eventually operate — transactional platforms, backend services, data pipelines — are already running on Java. The question for DevOps teams isn’t whether to adopt Java for AI. It’s how to ...