On June 17, 2026, a North Korean state actor needed just 88 minutes to poison more than 140 software packages that thousands of developers — and their AI coding assistants — pull automatically every day. There was no breach of a corporate network, no exploited vulnerability, and no CVE. The attackers simply walked in through the front door of the open-source software supply chain, and for a brief window, anyone who installed a popular AI framework may have handed over their cloud credentials, LLM API keys, and crypto wallets without ever knowing it.

For security leaders, the Mastra AI compromise is not just another incident to log. It is a preview of where adversaries are heading: away from your perimeter and into the building blocks your teams assemble software from. Here is what happened, why it matters, and what it exposes about how most organizations actually manage software risk.

What is an npm supply chain attack?

To understand the threat, start with how modern software gets built. Almost nobody writes an application entirely from scratch anymore. Instead, developers assemble applications from thousands of pre-built components — small, reusable pieces of code published to public registries. For the JavaScript and TypeScript world, that registry is npm, the largest open-source code repository on the planet.

When your team installs one package, that package quietly pulls in its own dependencies, which pull in theirs, and so on. A single line in a project file can fan out into hundreds of components written by strangers you will never meet. This web of indirect, “transitive” dependencies is the hidden iceberg beneath every modern application.

A supply chain attack exploits this trust. Rather than attacking your organization directly, the adversary poisons a component upstream — one that you, your vendors, and thousands of others already depend on. The malicious code then flows downstream into everyone who installs it. You inherit the compromise simply by building software the way everyone builds software.

What makes npm especially dangerous is a feature called install scripts. These let a package run code automatically the moment it is installed — before you have written a single line that uses it, and often before anyone has reviewed it. The trust model is implicit and absolute: you are trusting the maintainer’s account, the registry’s integrity, and every dependency-of-a-dependency in the chain. Break any link, and the poison spreads.

Inside the Mastra AI compromise — in plain language

Mastra is a widely used open-source framework for building AI agents, workflows, and retrieval pipelines. Its packages are pulled roughly eight million times a week. That popularity is exactly what made it a target. Here is what unfolded, stripped of jargon:

The break-in. The attackers gained control of a maintainer account that held standing rights to publish across the entire Mastra package family. Initial access traced back to social engineering — a contact on LinkedIn, a call, and a single malicious link clicked on the maintainer’s machine. The deeper structural flaw is that publishing rights on npm do not expire on their own. Access granted long ago lingers indefinitely unless a human manually revokes it.

The mass poisoning. Using that account, an automated script republished more than 140 Mastra packages in roughly 88 minutes. Into each one, the attackers slipped a new hidden dependency called easy-day-js — a deliberate look-alike of dayjs, a legitimate and extremely common date-handling library. Every poisoned version was tagged as the newest “latest” release.

The silent spread. Because the packages were marked latest, any developer or automated build pipeline that ran a routine install or update during that window automatically pulled in the malicious dependency. No one had to be careless. The default, correct behavior was enough.

The payload. The moment the package installed, its install script quietly ran a small dropper program. That dropper switched off the security checks that normally verify who a server is, phoned home to attacker-controlled infrastructure, downloaded a second stage, and launched it as a hidden background process. The result was a cross-platform information stealer — running on Windows, macOS, and Linux — that hunted for cloud credentials, developer secrets, LLM API keys, and more than 160 cryptocurrency wallet browser extensions. On compromised machines, the attackers went further: a PowerShell backdoor, security-tool exclusions, and a system service running with the highest privileges, ensuring they could stay.

The attribution. Two days later, on June 19, Microsoft attributed the campaign with high confidence to Sapphire Sleet (also tracked as BlueNoroff), a financially motivated North Korean state group with a long history of stealing cryptocurrency to fund the regime. The same group was tied to a near-identical attack on Axios — another hugely popular JavaScript library — just weeks earlier. This is not an isolated event. It is a repeatable playbook.

The most uncomfortable detail for defenders: nothing was technically “broken.” There was no software vulnerability and no CVE. Mastra’s own source code was never touched. Cryptographic signing existed but was not enforced, so a standard token could still publish unsigned packages. The attackers did not defeat the system’s security — they abused the way the system is designed to work.

Why this keeps CISOs awake — the real pain points

For security leaders, incidents like Mastra surface a set of structural problems that no single tool or policy has fully solved:

You cannot defend what you cannot see. Most organizations have no authoritative, current inventory of every software component actually running across their estate — least of all the transitive dependencies buried four or five layers deep. When the news broke, the urgent question — are we running the compromised versions? — took many teams hours or days to answer.

The AI blind spot is widening. Traditional asset inventories were never built to track AI frameworks, models, datasets, and agent components. As enterprises rush to adopt AI, an entirely new category of supply chain — the AI and ML stack — is being pulled in faster than governance can keep up. Mastra is an AI framework. That was not a coincidence; attackers are deliberately targeting AI developer tooling because that is where the most valuable credentials now live.

Speed is asymmetric. The compromise took 88 minutes. Detection and response routinely take days. When attackers automate at machine speed and defenders investigate at human speed, the gap is the breach.

You inherit risk you cannot inspect. A large share of the software running in your environment was built by third parties. You did not write it, you often cannot see inside it, and yet their exposure becomes your exposure.

Trust is not the same as safety. Every poisoned Mastra package was popular, reputable, and from a maintainer with a track record. Reputation, popularity, and even signing infrastructure did not prevent the compromise.

Regulators are no longer asking politely. Across the GCC, India, and global financial-services frameworks, supply chain assurance and software bills of materials are shifting from best practice to expectation. “We trust our vendors” is no longer a defensible answer.

Every one of these pain points traces back to the same root cause: a visibility gap. You cannot govern, prioritize, or respond to what you have never inventoried.

From blind spots to a living inventory

This is the discipline the next decade of software risk will be built on, and it is where an approach like Prism Discover becomes the natural starting point.

The core idea is simple but demanding: maintain a continuous, governed inventory of everything your software is actually made of — not a stale spreadsheet refreshed once a year, but a living register. Prism Discover does this across three complementary layers. A Software Bill of Materials (SBOM) maps every component and dependency in your applications, including the transitive ones most teams never see — so when the next Mastra hits, “are we exposed, and where?” becomes a query you run in minutes rather than a fire drill that consumes your week. An AI BOM and ML BOM extend that same rigor to the AI estate — the frameworks, agents, models, and datasets that conventional tooling simply does not track — closing the blind spot that the Mastra attackers chose to exploit.

Crucially, the problem is not only the software you build; it is the software you buy. Prism Discover lets you upload the CycloneDX files that your third-party applications and vendors already generate, ingesting them into one consolidated view alongside your own. The result is a single, queryable picture spanning what you wrote and what you inherited — the difference between answering a regulator or a board with evidence versus answering with hope.

None of this is a silver bullet, and it would be dishonest to suggest otherwise. Signing, least-privilege publishing, install-script controls, and rapid credential rotation all remain essential. But every one of those controls depends on a prerequisite that most organizations still lack: knowing, at any moment, exactly what they are running and where it came from.

The Mastra compromise is not an anomaly to be patched and forgotten. It is the new normal, and Sapphire Sleet has already shown it intends to repeat the pattern. The organizations that will turn the next 88-minute attack into a non-event are the ones that can answer a single question without hesitation: what are we actually running — including our AI stack — and where did it come from?

Visibility is no longer a hygiene task. It is the foundation everything else is built on.

‍