- An attacker compromised the npm account of the primary maintainer of Axios and released versions 1.14.1 and 0.30.4 with a phantom dependency, plain-crypto-js, which deployed a cross-platform RAT during installation.
- The malware contacted a C2 server (sfrclak[.]com) and downloaded specific payloads for Windows, macOS, and Linux, performing system reconnaissance, maintaining periodic beacons, and in some cases, establishing persistence.
- The attack, attributed by Google and other researchers to the North Korean actor UNC1069, combined a window of exposure of about three hours with a sophisticated social engineering campaign against the maintainer to steal their credentials.
- Organizations that were able to install the affected versions must commit to taking action, searching for RAT artifacts, rotating credentials, pinning secure versions of Axios, and strengthening their supply chain, CI/CD, and dependency management controls.
The JavaScript development community has just experienced one of those scares that makes you rethink how much you trust your dependencies, as demonstrated by library vulnerability issues . Axios, one of the most widely used HTTP libraries in the ecosystem, was manipulated on npm to distribute a remote access trojan (RAT) through seemingly legitimate versions. The incident lasted only a few hours, but it has made it clear that the software supply chain hangs by a much thinner thread than many thought.
The serious issue isn't just that the attackers managed to sneak malware into a package downloaded tens or hundreds of millions of times a week. The real problem is that they did it by hijacking the main maintainer's npm account, publishing "official" versions that appeared normal and didn't touch a single line of the Axios source code . All the malicious behavior resided in a phantom dependency specifically designed for the attack.
How Axios' commitment to npm came about
To understand the magnitude of the incident, we need to start with the entry point. The attacker managed to take control of the npm account of “jasonsaayman,” the main maintainer of Axios, and changed the associated email address to one under their control , hosted on Proton Mail. From that moment on, they had free rein to publish new versions of the package as if they were the maintainer.
Using those credentials, he uploaded two malicious versions of Axios: 1.14.1 and 0.30.4 , covering both major branches of the project. The uploads were made just 39 minutes apart and, according to StepSecurity's analysis, were made directly from npm using a classic long-lived token, completely bypassing the usual CI/CD pipeline based on GitHub Actions.
Eighteen hours before the final attack, the actor had already published a "clean" version related to the malicious dependency in the npm registry . This preliminary step served to generate a history and prevent some automated checks from triggering when a completely new package appeared at the time of the attack.
What's striking is that the attackers didn't modify Axios' source code or make any visible changes to the GitHub repository . In fact, versions 1.14.1 and 0.30.4 had no corresponding commits or tags on GitHub; they only existed on npm. The key difference was in the package's dependency file, which was published in the registry.
Axios, under normal circumstances, only declares three dependencies: follow-redirects, form-data, and proxy-from-env . However, in the compromised versions, a fourth dependency appeared, one that was previously nonexistent in the project: plain-crypto-js, version 4.2.1. This phantom library was not used anywhere in the Axios codebase, but it included a post-install script that ran automatically when installing the package with npm, pnpm, or similar tools.
plain-crypto-js: the phantom dependency deployed by the RAT
The key to the attack lay in that additional dependency. plain-crypto-js was published on npm by a user named “nrwise”, also with a Proton Mail email address, and its sole purpose was to execute an obfuscated post-installation script in Node.js (setup.js) . That script acted as a dropper, that is, as the initial installer for the malware's second phase.
When installing Axios in one of its poisoned versions, the npm post-install lifecycle automatically triggered the plain-crypto-js code without any special action required from the developer . The dropper connected to a command and control (C2) server active in the sfrclakcom domain, listening on port 8000, and downloaded a payload specific to the operating system of the affected machine; this behavior can be identified through network traffic analysis.
Researchers at StepSecurity and other analysis teams describe a very careful behavior. After executing the malicious payload, the dropper removed its own traces: it deleted the postinstall script, replaced the package.json file with a "clean" version, and left a node_modules file that, at first glance, appeared harmless . This way, a subsequent manual inspection did not find the malicious code directly within Axios.
To identify the manipulation, the only reliable clue was in the lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock) and the presence of specific versions: axios 1.14.1 or 0.30.4 and plain-crypto-js 4.2.1, in addition to two versions of that package with intermediate numbers (4.2.0, 4.2.2) linked in some analyses. Socket, for its part, later detected that the same malware was also distributed through the packages @shadanai/openclaw (various versions 2026.3.xx) and @qqbrowser/openclaw-qbot (0.0.130), and security techniques such as honeypots can also help identify similar campaigns.
Cross-platform RAT: Windows, macOS and Linux in the spotlight
Once executed, the setup.js script acted as an orchestrator capable of detecting the operating system and following a platform-specific attack path . The campaign was clearly pre-prepared: according to StepSecurity, the attackers had three separate payloads pre-compiled, one for each system.
On macOS systems, the post-install process launched an AppleScript that downloaded a Trojanized binary from the sfrclakcom:8000 server . This binary was saved to the /Library/Caches/com.apple.act.mond path, its permissions were adjusted to make it executable, and finally, it was started in the background using /bin/zsh. Once the RAT was running, the AppleScript itself was deleted to further complicate forensic analysis.
On Windows machines, the malware located the system's PowerShell binary, copied it to %PROGRAMDATA%\wt.exe to disguise it as the Windows terminal, and generated a temporary VBScript . This VBScript then contacted the C2 server to download an additional PowerShell RAT script, executed it, and then deleted the downloaded file. Furthermore, the Windows variant created the %PROGRAMDATA%\system.bat file with a download routine that allowed the malware to retrieve itself at each login and added an execution key to the Windows registry to ensure persistence.
On Linux and other Unix-like systems besides macOS, the dropper used Node.js's execSync to launch a shell command that downloaded a Python script from sfrclakcom, saved it as /tmp/ld.py, and executed it with nohup to keep it running in the background . Unlike Windows, this variant did not exhibit a robust persistence mechanism, suggesting a more rapid data exfiltration-oriented approach or the occasional deployment of persistence via subsequent commands.
SafeDep and Elastic Security Labs analyzed the second-level payloads and concluded that the RATs for macOS (C++ Mach-O binary) and Linux (Python script) shared the same command set, C2 protocol, message format, and operational behavior . This type of analysis typically relies on scanning services like VirusTotal , which facilitate the correlation of samples and IOCs.
In all cases, each compromised host performed an immediate system reconnaissance: user directories, drive roots, active processes, and other metadata . This information was sent to the command and control server, and the agent maintained a beacon loop of about 60 seconds, waiting for new instructions, including the execution of additional scripts or the injection of binaries into memory.
Exposure window, objectives, and attribution to North Korea
The malicious versions of Axios were available on npm for approximately three hours, during a carefully chosen time frame. The compromised packages were published just before midnight on Sunday (a time that maximized defenders' reaction time), and the incident was contained by early Monday morning , after security firms alerted authorities to the anomalous behavior.
During that relatively short period, Huntress detected at least 135 systems connecting to the attacker's server . Given that Axios records more than 80-100 million downloads per week (according to various sources, even more than 300 million in some periods), that number likely represents only the tip of the iceberg, limited to the systems that come to the attention of analytics firms that have made their data public.
Google, through its Threat Intelligence team, attributed the attack to a suspected North Korean actor labeled UNC1069 . Elastic Security Labs reinforced this hypothesis by finding a strong similarity between the RAT delivered on macOS and WAVESHAPER, a C++ backdoor discovered by Mandiant and also linked to the same threat group.
Google analysts emphasized that North Korean-linked groups have been specializing in supply chain attacks and cryptocurrency theft operations for years . The pattern is consistent: compromising development infrastructure, widely used libraries, or trusted software to then move laterally toward targets that manage high-value assets, private keys, or credentials.
Several reports also highlighted that the moderation and design of the attack suggested a well-coordinated team : three parallel implementations of the same RAT (PowerShell, C++, and Python), a consistent C2 protocol, almost identical behavior across all variants, and a clear self-cleaning strategy to avoid leaving traces. Elastic emphasized that this consistency points to a single developer or a group working from a shared design document, far from improvisation.
Beyond the purely technical aspects, one of the most unsettling points of the case is how the main maintainer's npm account was hijacked. The Axios manager himself later explained that he had two-factor authentication enabled on almost all his services , and yet he still ended up granting access without realizing it.
According to the post-mortem analysis shared by the team, the attackers mounted a highly elaborate social engineering operation, supported by AI-powered tools, to gain their trust . They impersonated the founder of a company, copying its visual identity, photograph, and even the corporate branding. They created a real Slack space with the company logo, channels with posts supposedly synced with LinkedIn, and even fake profiles of employees and other open-source software maintainers.
Within that environment, they scheduled a meeting via Microsoft Teams in which a full group of professionals appeared to be participating . During the meeting, they simulated a technical problem and indicated that a component of their system was outdated. The maintenance technician, assuming it was a legitimate requirement related to the videoconferencing tool itself, downloaded and installed the suggested file.
That file was, in fact, the remote access Trojan that allowed the attackers to pivot to the victim's credentials and ultimately take control of the npm account used to publish Axios . The entire process was so well orchestrated, with so many believable details, that the victim described it as "perfectly coordinated, professional, and completely convincing."
This human element of the incident makes it clear that even technical measures like 2FA are insufficient when high-level social engineering is combined with visual impersonation, deepfakes, or detailed cloning of organizations . The weakest link, once again, is human interaction.
Impact on organizations and developers using Axios
From a practical standpoint, the main problem is determining who was actually affected. Any organization that installed [email protected] or [email protected] during the window in which they were available should assume that the machine or pipeline that performed the installation may be compromised.
The recommendations from firms like StepSecurity, Aikido, Huntress, and Elastic are unequivocal. In case of suspicion, a proactive approach is necessary, not simply "deleting and reinstalling node_modules ." The prudent course of action is to rebuild the affected machines or environments from trusted images and carefully review the CI/CD logs to identify which jobs or pipelines may have executed the compromised versions.
Furthermore, it is critical to rotate all credentials and secrets that the RAT might have accessed from those nodes : npm tokens, cloud provider keys, pipeline secrets, database credentials, SSH keys, etc. Leaving these credentials in circulation after such an attack leaves the door open for silent lateral movement.
At a technical level, teams should review their lock files (package-lock.json, pnpm-lock.yaml, yarn.lock) for references to the compromised versions of Axios and plain-crypto-js . If these elements are found, the next step is to inspect the affected systems for potential RAT artifacts: /Library/Caches/com.apple.act.mond on macOS, %PROGRAMDATA%\wt.exe and %PROGRAMDATA%\system.bat on Windows, or /tmp/ld.py on Linux.
In parallel, it is recommended to explicitly set secure versions of Axios, such as 1.14.0 and 0.30.3, and use overrides or resolutions to prevent transitive dependencies from resolving to undesired versions . Blocking outbound traffic to the sfrclakcom domain is also a sensible containment measure, at least while the full scope of the attack is being analyzed.
Security lessons for the software supply chain
The Axios incident is not an isolated event, but another link in a chain of supply chain attacks that includes cases like SolarWinds, Kaseya, 3CX, Polyfill.io, and vulnerabilities exploited in Log4j. The core idea is always the same: compromise a widely used, trusted component to maximize reach , rather than attempting to attack machine by machine.
One of the most frequently repeated lessons from experts is that trust cannot rely solely on the popularity of a library or the reputation of a maintainer . If the release channel (the npm account, the CI/CD pipeline, the build infrastructure) is compromised, everything released through it inherits that risk. Manual code review is also insufficient if malware hides in transitive dependencies and deletes itself after execution.
It has also been highlighted that the "default speed" for dependency updates comes at a cost in terms of attack surface . Always automatically adopting the latest version is incredibly convenient, but it opens the door for a malicious update to spread in a matter of minutes. Some organizations are already considering policies such as requiring a new version to have been in the ecosystem for a certain period before adoption, or requiring changes to critical packages to undergo additional manual review.
Regarding development infrastructure, CI/CD environments must be treated as highly sensitive assets . Any RAT executed during dependency installation will almost certainly seek pipeline secrets and access to other environments. Segmenting these nodes, monitoring them more closely, and rotating their secrets periodically is no longer an "ideal" recommendation but a necessity.
Finally, detecting these types of attacks requires combining information from multiple sources: installed versions, lockfiles, operating system indicators of compromise, and network telemetry . Tools that generate and manage Software Bill of Materials (SBOMs) help quickly trace which projects use which packages, which is vital when massive alerts like this one are triggered.
This entire episode with Axios illustrates the extent to which the dependency ecosystem, however mature and consolidated it may seem, still relies heavily on trust and constant vigilance. A seemingly innocuous library, maintained by a single person who falls victim to a well-executed social engineering attack, can become, in a matter of hours, a global vector for deploying cross-platform RATs against companies, freelancers, and organizations of all sizes . Strengthening controls around publishing accounts, pipelines, and critical dependencies is no longer an optional best practice, but a prerequisite for continued development in an environment where attackers are increasingly patient, resourceful, and equipped with better tools.
