North Korean Hackers Poison Mastra AI in npm Attack North Korean threat actor Sapphire Sleet compromised the Mastra AI open-source framework on June 17, 2026, by hijacking a maintainer's npm credentials and poisoning 141 packages within 88 minutes. The attack exploited the disconnect between CI/CD provenance and registry permissions, using a malicious dependency with a postinstall hook to deploy a second-stage payload. This incident highlights critical supply-chain risks in the JavaScript ecosystem, where stale maintainer access and automatic dependency resolution can be weaponized against AI development tools. Security https://www.devclubhouse.com/c/security Article North Korean Hackers Poison Mastra AI in npm Attack The compromise of the Mastra AI framework exposes critical gaps between CI/CD provenance and registry-level publish permissions. Emeka Okafor https://www.devclubhouse.com/u/emeka okafor AI frameworks have quickly become the crown jewels of modern developer environments. Because they orchestrate LLM integrations, they routinely handle highly sensitive API keys, cloud credentials, and database connection strings. This concentration of secrets has made them prime targets for sophisticated state-sponsored actors. On June 17, 2026, Sapphire Sleet also known as BlueNoroff , a North Korean threat actor targeting the financial and cryptocurrency sectors, executed a swift supply-chain attack against Mastra AI https://mastra.ai , a popular open-source JavaScript and TypeScript framework for building AI applications. By hijacking a single maintainer account, the attackers poisoned over 140 packages in the @mastra scope on npm https://www.npmjs.com within an 88-minute window. This attack is not just another credential-theft story. It is a masterclass in exploiting the structural seams of the modern JavaScript ecosystem: the disconnect between source-code provenance and registry publishing, the persistence of stale maintainer access, and the dangerous default behavior of package installation hooks. The Anatomy of the 88-Minute Blitz The compromise began not with a zero-day exploit in Mastra's code, but with classic social engineering. A threat actor posing as a contact on LinkedIn targeted "ehindero," an active Mastra employee and maintainer. During a call, the maintainer clicked a suspicious link, leading to a workstation compromise and the theft of their npm credentials. The "ehindero" account possessed publishing rights across the entire @mastra scope. Although the account had been dormant for 16 months prior to the attack, npm's lack of credential expiration meant this access remained a live, unmonitored backdoor. With access secured, Sapphire Sleet staged the attack using a clever "clean-then-armed" dependency injection technique: The Decoy : On June 16, 2026, an anonymous account named "sergey2016" published easy-day-js@1.11.21 . This was a clean, fully functional clone of the legitimate, highly popular dayjs date library. The Weaponization : On June 17, 2026, at 1:01 AM UTC, the attacker published version 1.11.22 of easy-day-js . This version contained a malicious postinstall hook. The Mass Poisoning : Starting at 1:15 AM UTC, the compromised "ehindero" account mass-published updated versions of 141 packages across the @mastra scope. None of these packages contained malicious code directly. Instead, the attacker modified their package.json files to include easy-day-js@^1.11.21 as a new dependency. Because Mastra packages used caret-range dependency resolution ^1.11.21 , any developer or CI/CD pipeline running npm install or npm update was automatically served the weaponized 1.11.22 version. Inside the Postinstall Payload The payload execution relied on npm's default execution of lifecycle scripts. When a poisoned Mastra package was installed, the transitive dependency easy-day-js triggered a postinstall hook running node setup.cjs --no-warnings . The execution chain proceeded in two distinct stages: First-Stage Dropper : The setup.cjs script was a 4,572-byte obfuscated file. To evade network-level security controls, the script disabled Transport Layer Security TLS certificate verification. It then dropped local tracking markers ~/.pkg history and ~/.pkg logs , contacted an attacker-controlled command-and-control C2 server at 23.254.164 . 92:8000 , and downloaded a second-stage payload named protocal.cjs . The dropper then executed this payload as a detached, window-hidden Node.js process and deleted itself to minimize forensic footprints. Second-Stage Implant : The downloaded implant was a highly sophisticated, cross-platform information stealer designed to target Windows, macOS, and Linux. It performed extensive host reconnaissance—collecting hostnames, system architectures, running processes, and installed applications. Crucially, it targeted developer assets: Browser History : It extracted history and credentials from Chrome, Edge, and Brave by directly querying local SQLite databases via node:sqlite . Cryptocurrency Wallets : It specifically scanned for the presence of 166 cryptocurrency wallet browser extensions, including MetaMask, Phantom, Coinbase Wallet, Binance Wallet, and TronLink. Persistence : To survive reboots, the malware established platform-specific persistence mechanisms: Windows : A registry Run key named NvmProtocal that launched a hidden PowerShell process. macOS : A LaunchAgent plist named com.nvm.protocal.plist . Linux : A systemd user service named nvmconf.service . All exfiltrated data was sent to a secondary C2 server at 23.254.164 . 123:443 using a spoofed User-Agent Mozilla/4.0 compatible; MSIE 8.0 over a custom ICAP-style protocol. The Developer Angle: Fixing the Provenance and Token Gap For developers, this incident exposes a glaring security gap in how we publish and consume open-source packages. Shadow GPS — know where it is, always Real-time GPS tracking for vehicles, gear and loved ones. No monthly contracts. https://www.devclubhouse.com/go/ad/12 Mastra's maintainers had implemented modern security best practices: they shipped official releases from CI/CD pipelines using npm's trusted publisher flow, which generated Sigstore-signed SLSA Software Artifacts for Source Aligned provenance attestations. However, npm does not enforce provenance by default. While Mastra's legitimate releases carried attestations, the registry still accepted the attacker's publications because they were signed with a standard personal access token. The attacker simply bypassed the CI/CD pipeline entirely, published the poisoned packages directly from the hijacked account, and dropped the provenance attestations. Because npm's client does not reject un-attested packages by default, downstream developers were none the wiser. To defend against this class of attack, developers must implement a multi-layered defense-in-depth strategy. 1. Enforce Signature and Provenance Verification Do not rely on the registry to block un-attested updates. You can configure your package manager or CI/CD pipelines to require valid signatures and provenance attestations. For example, you can use tools like npm audit signatures or integrate policy engines that reject any package in a known scope like @mastra that lacks a valid SLSA attestation linking it back to the official GitHub repository. 2. Neutralize Postinstall Hooks The entire execution chain of this attack relied on the postinstall hook of a transitive dependency. If your application does not strictly require install-time scripts, disable them globally or per-project. You can disable scripts globally via your shell: npm config set ignore-scripts true Alternatively, add this to your project's local .npmrc file to ensure all team members and CI runners inherit the setting: ignore-scripts=true If certain dependencies require scripts to build native bindings, use selective tools like allow-scripts to whitelist only trusted packages. 3. Audit and Remediate If you ran npm install or npm update on a project containing Mastra dependencies on June 17, 2026, your environment must be treated as compromised. Search for Indicators of Compromise IoCs : Check for the presence of the tracking files ~/.pkg history and ~/.pkg logs on your system. Check Persistence Artifacts :- On macOS, inspect /Users/