On March 30, 2026, Elastic Security Labs’ automated supply chain monitoring flagged something wrong with a package that 100 million JavaScript projects download every week.
The axios npm package — the ubiquitous HTTP client used in everything from enterprise web applications to embedded IoT device firmware — had been compromised. The attacker had taken over the npm account of jasonsaayman, one of axios’s primary maintainers, and within a 39-minute window published two backdoored versions of the package.
Those versions contained a cross-platform Remote Access Trojan (RAT) delivered through a malicious postinstall hook. The RAT was designed to run silently on macOS, Windows, and Linux — meaning any developer or CI/CD pipeline that ran npm install during that window potentially received malicious code.
Google Threat Intelligence Group has attributed the attack to UNC1069, a North Korea-nexus financially motivated threat actor that has been operating since at least 2018. The group updated a known tool — WAVESHAPER.V2 — to deliver the payload.
Why This Matters Far Beyond JavaScript
If you work in IoT, embedded systems, or industrial device development and your first reaction to this story was “I don’t use npm,” read on. The axios compromise is a supply chain attack — and the supply chain attack problem is not confined to npm, JavaScript, or web development.
The specific incident is alarming on its own merits. axios is one of the most downloaded packages in the entire npm ecosystem. It is used in:
- Enterprise web applications
- Node.js backend services
- IoT device management dashboards and cloud platforms
- Firmware build pipelines that include JavaScript-based tooling
- CI/CD systems that use Node.js-based build tools
But the pattern it represents is universal:
A trusted maintainer account is compromised. A malicious version of a trusted package is published. Every project that installs or updates the package receives the malicious payload. The window before detection is measured in minutes to hours, during which thousands of automated systems have already pulled the malicious code.
This attack vector works against npm. It works against PyPI. It works against RubyGems. It works against the firmware repositories used by embedded device manufacturers. It works against the vendor update servers used by industrial control system components.
The North Korea Angle: Why DPRK Targets Open Source Infrastructure
UNC1069 is a financially motivated North Korean threat actor, which means its operations are ultimately in service of generating hard currency for the DPRK government — circumventing sanctions by stealing cryptocurrency, conducting financial fraud, and selling access.
The axios attack fits this pattern: a successful compromise could provide persistent access to developer environments and CI/CD pipelines, which can then be used to:
- Steal credentials for code repositories, cloud platforms, and financial systems
- Compromise software that downstream projects distribute to their customers — extending the impact beyond the direct victim
- Access cryptocurrency wallet software under development — a high-value target for DPRK actors
- Establish persistent access to enterprise environments through compromised build pipelines
North Korea has demonstrated sophisticated understanding of software supply chains. The DPRK’s Lazarus Group pioneered large-scale supply chain compromise with the 3CX attack in 2023. UNC1069’s axios operation follows the same playbook: compromise a trusted intermediary to reach targets who would be difficult to breach directly.
The IoT Firmware Supply Chain Problem
The axios incident crystallizes a risk that the IoT and embedded device industry has not adequately addressed: the security of the software supply chain used to build device firmware.
Modern IoT device firmware is not written from scratch. It is assembled from:
- Open source libraries and packages — often pulled from npm, PyPI, or language-specific registries — for networking, cryptography, parsing, and other functions
- RTOS components — FreeRTOS, Zephyr, ThreadX, and similar real-time operating systems that are themselves assembled from components with their own supply chains
- Vendor SDKs — software development kits provided by chipset manufacturers that include pre-built drivers, networking stacks, and cloud connectivity libraries
- Third-party middleware — security libraries, compression libraries, protocol implementations
- CI/CD tooling — the build systems, test frameworks, and deployment pipelines that assemble all of the above
Each component in this stack is a potential supply chain attack vector. And unlike enterprise software — where compromised code typically runs in an environment with monitoring, EDR tools, and security operations visibility — compromised IoT firmware runs in devices that have essentially no endpoint security capability.
A backdoored library in a consumer router’s firmware cannot be detected by an antivirus scanner. A compromised SDK in an industrial gateway’s firmware will not generate EDR telemetry. A malicious update delivered to a smart meter will be trusted by the meter regardless of its actual origin if firmware signing controls are insufficient.
How the Axios Attack Was Caught — and Why That’s Alarming
Elastic Security Labs detected the axios compromise through automated supply chain monitoring — specifically, tooling that tracks changes to package manifests, publish events on package registries, and behavioral anomalies in package contents.
That’s a sophisticated capability. Most organizations don’t have it.
The 39-minute window between publication and detection was short enough that automated CI/CD pipelines running on a typical hourly or daily schedule would have pulled the malicious versions. Projects with npm install in their automated build processes — which is essentially all of them — were at risk for the duration of the window.
Detection required:
- Continuous monitoring of the npm registry for suspicious publish events
- Automated behavioral analysis of package contents
- The specific tooling that Elastic had built for this purpose
Most organizations — including most IoT device manufacturers and embedded device developers — do not have this capability. They rely on the assumption that packages from trusted maintainers of established projects are safe. The axios attack demonstrates that this assumption has been weaponized.
The average organization would not have known it was affected. Without the monitoring that Elastic had in place, the axios compromise might have gone undetected for days, weeks, or months — giving attackers persistent access to every development environment, CI/CD pipeline, and cloud system that ran the infected builds.
What Specifically Happened: The Technical Detail
The attack chain, as documented by Elastic Security Labs:
-
Account compromise. The attacker gained control of the npm account belonging to
jasonsaayman— one of axios’s primary maintainers — through credential theft or phishing. -
Backdoored package publication. Using the compromised account, the attacker published two malicious versions of axios within a 39-minute window. The malicious versions appeared identical to the legitimate package except for the addition of a
postinstallscript. -
RAT delivery via postinstall hook. npm’s
postinstallfeature allows package maintainers to run arbitrary code after a package is installed. The malicious script used this mechanism to download and execute WAVESHAPER.V2 — an updated version of a North Korea-linked RAT — on the victim machine. -
Cross-platform payload. WAVESHAPER.V2 is designed to run on macOS, Windows, and Linux, maximizing the range of developer environments it can infect.
-
Persistence and C2 establishment. Once installed, the RAT establishes command-and-control communication, giving attackers persistent access to the development environment.
-
Detection and remediation. Elastic’s automated monitoring detected the anomalous publish event. npm removed the malicious versions. Elastic published its analysis on March 30, 2026.
What IoT and Embedded Device Teams Should Do
1. Implement a Software Bill of Materials (SBOM) for your firmware. A firmware SBOM is a comprehensive list of every software component in your device — open source libraries, RTOS components, vendor SDKs, and tooling dependencies. Without it, you cannot quickly assess your exposure when an incident like the axios compromise occurs. FDA has been pushing medical device SBOMs specifically; industrial and consumer IoT should adopt the same practice.
2. Pin your dependencies.
Rather than specifying version ranges (e.g., axios: ^1.x) in your package manifests, pin to specific, verified versions (e.g., axios: 1.7.4). Pinning prevents automatic updates to new versions — including malicious ones — without explicit review.
3. Verify package integrity with checksums.
Both npm and most other package registries support cryptographic checksums (integrity hashes) for published packages. Lock files (package-lock.json, yarn.lock) include these hashes. Verify that your CI/CD pipelines enforce integrity checks and fail the build if checksums don’t match.
4. Monitor the packages you depend on. Subscribe to security advisories for your direct dependencies. For high-impact packages in your firmware supply chain, consider monitoring npm/registry publish events. Tools like Socket.dev, Snyk, and Sonatype Nexus provide automated monitoring for supply chain attacks.
5. Implement firmware signing. All firmware distributed to deployed devices should be cryptographically signed, and devices should verify signatures before installing updates. This does not prevent a compromised build pipeline from producing a signed malicious firmware — but it does prevent unauthorized third parties from distributing firmware at all.
6. Treat your build pipeline as part of your attack surface. Your CI/CD system is as security-sensitive as your production environment. It has access to your source code, your signing keys, your deployment credentials, and ultimately your customers’ devices. Implement MFA on all developer accounts, enforce least-privilege access, and audit your build pipeline dependencies separately from your firmware dependencies.
7. Rotate credentials after supply chain incidents. If you used axios (or any affected package) in builds that ran during the exposure window (approximately March 30, 2026), assume that the credentials available in that build environment may be compromised. Rotate API keys, cloud credentials, and developer tokens that were accessible during the affected builds.
The Bigger Picture: Supply Chain Attacks Are the New Normal
The axios compromise is the latest in a pattern that has been accelerating for years. The SolarWinds attack in 2020. XZ Utils in 2024. The Polyfill.io compromise. The Trivy security tool supply chain attack earlier this month.
The pattern is consistent: attackers find the trusted intermediaries in the software supply chain and compromise them to reach targets that would be difficult to breach directly. As direct attacks become harder — as organizations improve their perimeter security, deploy MFA, and implement EDR — supply chain compromise becomes more attractive.
For IoT and embedded device manufacturers, this trend has a specific implication: the security of your devices in the field depends not just on the security of your own code and your own infrastructure, but on the security of every package, SDK, library, and tool that touched your firmware during the build process.
That is a large and poorly understood attack surface. The axios incident is a reminder that it is also being actively exploited.
Technical details in this article are drawn from Elastic Security Labs’ analysis of the axios npm supply chain compromise (published March 30, 2026) and Google Threat Intelligence Group’s attribution to UNC1069. The postinstall hook mechanism and WAVESHAPER.V2 payload are described as documented in the public Elastic research.
