The Mastra AI Compromise: How Sapphire Sleet Poisoned the Well
Supply chain attacks aren't theoretical anymore. They are happening in real time, targeting the very tools we build AI applications with. Recently, Microsoft attributed a devastating attack against the Mastra AI framework to Sapphire Sleet, a notorious North Korean hacking group also operating as BlueNoroff. It wasn't a subtle compromise of a few files. More than 140 npm packages belonging to the Mastra AI ecosystem were systematically poisoned. From where I sit—having spent years designing hardware at Graphcore and researching neuromorphic chips—this software ecosystem feels like a house of cards. In hardware, you isolate circuits on silicon. You don't let unverified components touch critical paths. But in the web dev world, we run npm install and hope for the best.
Think about how modern developers work. We trust the package manager to do the heavy lifting, pulling downstream dependencies safely. But Sapphire Sleet exploited this blind trust. They did not hack Mastra's core servers or break their cryptography. Instead, they went after the human element—specifically, a developer account with publishing rights. The moment that single account fell, the entire chain crumbled. It’s a sobering reminder that our AI systems, no matter how advanced their underlying neural networks, are only as secure as the weakest npm credentials in their pipeline.
The Entry Point: Hijacking the 'ehindero' npm Maintainer Account
How did this happen? It began with the compromise of a single npm maintainer account named 'ehindero'. This account held publishing privileges across the @mastra scope. Once inside, the attackers did not waste time. They uploaded malicious updates to over 140 packages. These updates injected a dependency called easy-day-js.
The name itself is a trap. It's a typosquat of dayjs, a highly popular utility library developers use every day. If you glance at a package lock file, you won't even spot the difference. That's the brilliance of typosquatting. It hides in plain sight. When a developer pulled the poisoned Mastra packages, npm retrieval systems went to work and pulled easy-day-js. The installation process automatically triggered a post-install hook. In the JavaScript ecosystem, these hooks are silent execution engines. Before your application code even runs, the post-install script is already setting up shop on your machine. This wasn't an accident. It was a calculated exploit of npm's default behavior, designed to turn a routine project install into an active breach.
Under the Hood: The Obfuscated Stealer Targeting Crypto Wallets
Once the installation hook executed, the payload got to work. First, the script disabled Transport Layer Security (TLS) certificate verification. This is a classic trick to bypass network monitoring tools that flag invalid or self-signed certificates. Then it reached out to Sapphire Sleet's command-and-control (C2) infrastructure. It downloaded a second-stage, cross-platform dropper and ran it as a detached, hidden process.
This second-stage implant was a stealthy information stealer. It didn't care if you were running Windows, Linux, or macOS—it had versions for all of them. The malware scanned the host system for browser histories, system configurations, and running processes. But its primary payload targeted cryptocurrency. The malware specifically checked for the presence of 166 different cryptocurrency wallet browser extensions. We are talking about MetaMask, Phantom, Coinbase Wallet, Binance Wallet, and TronLink. If you had keys stored in your browser, they were gone. The attackers didn't just want access to the AI models; they wanted cold, hard liquidity. It's a classic BlueNoroff playbook—using high-tech supply chain attacks to fund state operations.
North Korean Tradecraft: Persistent Shells and Backdoors
Once the malware established a foothold, Sapphire Sleet deployed its deeper toolkit. Microsoft's incident responders observed follow-on activity using tactics that are classic signatures of the group. They deployed a custom PowerShell backdoor that the group has used in previous operations. They also modified system settings to add Microsoft Defender exclusions. This meant their malicious files could sit on the disk without triggering local antivirus alarms.
To make things worse, they created a malicious Windows service designed to run with SYSTEM privileges. Once you have SYSTEM-level execution, you own the machine. They also set up different persistence methods depending on the target OS: Windows Registry Run keys, macOS LaunchAgents, and Linux systemd services. They wanted to make sure that even if the developer rebooted their system or updated their packages, the backdoor remained open. Seeing this level of operating-system-specific engineering tells us that this wasn't a script-kiddie operation. It was a well-funded, highly structured campaign targeting developers who hold the keys to valuable enterprise environments.
Fixing the npm Pipeline: GitHub's Direct Responses to Supply Chain Risks
This attack highlights a massive flaw in how package managers operate. By default, npm install runs whatever scripts a package containing installation hooks wants. But this is about to change. GitHub, which owns npm, has announced security changes for npm version 12 to address this exact threat.
Starting in version 12, npm will no longer run pre-install, install, or post-install scripts by default. Developers must explicitly approve them. It will also block automatic dependency resolution from Git repositories or raw external URLs unless you explicitly opt in. This would have completely broken Sapphire Sleet's attack path. If you are a developer, don't wait for version 12. Upgrading to npm 11.16.0 or later will show warnings about script execution, helping you clean up your workflows today. We must stop treating external dependencies as trusted black boxes. If we don't, nation-state actors will continue to turn our dev tools against us.