145 Mastra npm Packages Compromised via Hijacked Contributor Account

Another contributor-account compromise hits the JavaScript ecosystem — defenders using Mastra packages have inventory and rotation work this week.

SAN FRANCISCO, CALIFORNIA — Researchers on June 17, 2026 disclosed that roughly 145 npm packages tied to the Mastra ecosystem — an open-source JavaScript and TypeScript framework for building AI agent applications — were compromised in a software supply chain attack that traced back to a single hijacked contributor account. According to the reporting, the attackers gained control of a former Mastra contributor's npm account whose access to the package scope had never been revoked, then used it to republish packages across the namespace within a short window. The packages were not modified to carry malicious code directly; instead each was republished with a new dependency that, researchers say, pulled down a malicious payload when developers installed it.

For defenders the story is familiar in shape. It is the latest in a run of incidents in which trust in a single maintainer or contributor account became the soft point that let an attacker reach a wide population of downstream projects — the same pattern seen in recent npm worm and clone campaigns. The practical question this week is not who did it but whether your own builds touched an affected version, and what credentials sat within reach of the process that installed it.

What Was Disclosed

Researchers reported on June 17, 2026 that approximately 145 npm packages associated with the Mastra ecosystem were compromised in a coordinated supply chain campaign. Mastra is an open-source framework, written in JavaScript and TypeScript, used to build AI agent applications; its packages are distributed through the npm registry under a shared scope, which is what gave a single account control over a wide set of packages at once. The Hacker News reported the disclosure, with several security vendors publishing parallel analyses of the same campaign.

The root cause, as described in the reporting, was an account-trust failure rather than a code vulnerability in Mastra itself. Attackers are said to have taken control of an npm account belonging to a former contributor to the project — an account that still held publish access to the package scope despite the contributor no longer being active. With that access, the attackers republished packages across the namespace in an automated burst, adding a malicious dependency to each rather than altering the package source directly. Reporting described the publishing run as compressed into a window on the order of an hour to ninety minutes.

The malicious component was a dependency that researchers identified as a clone of dayjs, a widely used date-handling library, published under a confusingly similar name. According to the analyses, that dependency was responsible for fetching and executing a second-stage payload during package installation. Because the harm was delivered through a dependency added at publish time rather than visible changes to the Mastra packages themselves, a casual reading of an individual package would not necessarily reveal the problem — which is part of why supply chain campaigns of this kind are difficult to spot by eye.

Defender Posture for Organizations Using Mastra Packages

The defender takeaway does not depend on the precise package count or on the attribution that followed. What matters operationally is straightforward: if your organization builds on the Mastra framework, or pulls in any package from the affected scope as a transitive dependency, you need to determine whether any of your build environments installed an affected version during the exposure window. Because the malicious behavior, as reported, executed at install time, the relevant blast radius is every developer workstation, continuous-integration runner, and build host that ran an install against the registry while the poisoned versions were live.

This is the recurring lesson of npm-scope compromises: removing or upgrading the package after the fact does not, on its own, undo what an install-time payload may already have done. The same logic applied in earlier incidents such as the node-ipc developer-secret stealer and Microsoft's discovery of malicious dependency-confusion packages, where the install step itself was the moment of exposure. A host that ran the install should be treated as potentially affected until proven otherwise, not assumed clean because the offending version has since been pulled.

It is worth being precise about what is and is not established. The 145 figure is the count cited in the disclosure reporting; some early write-ups put the number slightly lower, around 144, as the exact set was being enumerated. The CyberSignal is not asserting specific affected package names, exact download totals, or the existence of a formal npm advisory beyond what the reporting describes, because those details varied across early sources. None of that uncertainty changes the defender action: the conservative posture is to assume exposure for any pipeline that touched the scope during the window and to verify rather than presume.

Inventory, Version Verification, and CI/CD Credential Rotation

The first task is inventory. Teams need a clear answer to a simple question — where, across the estate, does Mastra appear, whether as a direct dependency or buried several levels down in a dependency tree. Lockfiles are the authoritative record here: package-lock.json, yarn.lock, or pnpm-lock.yaml files pin the exact versions a build resolved, and they are where a transitive pull of an affected package will actually show up even when nothing in the top-level manifest mentions Mastra by name. A software bill of materials, where one exists, makes the same audit faster, but the lockfiles are the ground truth.

The second task is version verification. Once usage is mapped, each resolved version should be checked against the versions reporting flagged as malicious and against known-good builds. Where a build environment resolved an affected version, the remediation is to pin back to a verified-clean version and rebuild from that point, rather than simply running an update and assuming the latest is safe. Reproducible, pinned builds make this materially easier; environments that float to the newest version on every install are exactly the ones that got caught.

The third task — and the one most likely to be skipped under time pressure — is CI/CD credential rotation. CI/CD, short for Continuous Integration / Continuous Deployment, is the automated pipeline that builds, tests, and ships software, and it is also where the most valuable secrets tend to live: registry tokens, cloud deployment keys, signing credentials, and environment variables holding API keys. An install-time payload running inside that pipeline has those secrets within reach. So any pipeline that installed an affected Mastra version should have its credentials treated as potentially exposed and rotated — registry and publish tokens first, then cloud and deployment keys, then any long-lived secrets the build job could read. This is the same discipline that the broader push toward gated npm publishing and tighter default install behavior is trying to bake in by design, a direction reflected in npm's recent change to disable install scripts by default.

Continuation Context — Microsoft's June 22 Sapphire Sleet Attribution

The initial disclosure was about the mechanics of the compromise and the urgent defender response. Attribution came afterward. In a Microsoft Security Blog analysis, Microsoft subsequently tied the campaign to a North Korea-linked threat cluster it tracks as Sapphire Sleet, a financially motivated group, framing the Mastra incident as part of a wider pattern of state-aligned actors targeting the open-source software supply chain. The CyberSignal covers that attribution in a separate analysis of Microsoft's Sapphire Sleet attribution, which examines the actor, the tradecraft, and what the naming implies for defenders watching for follow-on activity.

For the purposes of immediate response, though, attribution is downstream of the work. Knowing which group is behind a campaign sharpens threat-intelligence and helps anticipate what the actor does with stolen secrets, but it does not change the inventory, verification, and rotation steps a defender takes this week. Those steps are the same whether the operator is a nation-state crew or an opportunistic criminal — which is exactly why the defender guidance in this article stands on its own, ahead of and independent from the attribution piece.

The pairing is deliberate. Readers who need to act should start with the posture work described above; readers who want to understand the adversary and the strategic picture should follow through to the attribution coverage. Treating the two as a continuum — incident response first, threat intelligence second — mirrors how a well-run security team actually sequences its own response to a disclosure like this one.

Open Questions

Several details remained in flux at the time of disclosure, and defenders are better served by holding them as open than by treating early figures as settled. The exact count of affected packages was reported as roughly 145, with some sources citing 144 as enumeration continued; the precise list of package names and the full set of malicious version strings were still being compiled and corroborated across vendor write-ups. The CyberSignal is not asserting a definitive package list, exact aggregate download numbers, or a formal registry advisory beyond what the reporting supports — those are exactly the kinds of specifics that shift in the first days of a supply chain incident.

Two questions matter most for downstream teams. First, how long the poisoned versions were live and reachable before removal, since that window defines who was actually exposed; reporting indicated a tight publishing burst, but the interval between publication and takedown determines the real blast radius. Second, what the second-stage payload did once it executed — credential theft, persistence, or both — which shapes how aggressively a team that installed an affected version needs to rotate secrets and rebuild hosts rather than simply uninstalling the package.

What is not in question is enough to act on. A trusted package scope was republished at scale through a single hijacked account whose access had outlived its owner's involvement, and the malicious behavior ran at install time inside developer and build environments. That is sufficient to justify the conservative response: inventory Mastra usage, verify versions against known-good builds, rotate CI/CD credentials, and treat any host that ran an affected install as suspect until checked. Attribution and final figures can be refined later; the defensive window is now.

The CyberSignal Analysis

The reported facts above come from the disclosure and vendor write-ups; what follows is The CyberSignal's editorial reading of what defenders should take from them. None of the judgments below are new reported facts.

Signal 01 — The Contributor Account Is the Supply Chain's Soft Point

The most durable lesson here is not that Mastra shipped bad code but that it never had to. The compromise reached 145 packages because a single former-contributor account still held publish access to the entire scope long after the contributor stopped being active. That is an access-governance failure, not a coding one, and it is the pattern that keeps recurring across the JavaScript ecosystem: trust granted to a person outlives that person's involvement, and an attacker who takes over the dormant account inherits everything the account could still touch.

Our reading is that maintainers should treat scope-level publish access as a standing liability to be actively pruned, not a convenience to leave in place. The defensive question for any project with multiple contributors is simple and uncomfortable — who can still publish, and would anyone notice if one of those accounts started behaving like an attacker. The controls that bound this class of incident are least-privilege token scoping, mandatory revocation when contributors leave, and phishing-resistant multi-factor authentication on every account that can push to a registry.

Signal 02 — Install-Time Execution Is Where the Damage Actually Lands

The individual Mastra packages were not modified to carry malicious code; each was simply republished with a dependency that fetched and ran a second-stage payload at install time. That distinction is the whole point. A defender scanning package source for suspicious code would find nothing, because the harm lived in the install step, not in the artifact. This is why supply chain campaigns of this shape are so hard to catch by eye and why the blast radius is every workstation, CI runner, and build host that ran an install while the poisoned versions were live.

The actionable interpretation is to assume that an install is code execution and to instrument accordingly. Environments that disable install scripts by default, run installs in ephemeral sandboxes, and pin to reproducible builds are the ones that bound this incident; environments that float to the newest version on every install are exactly the ones that got caught. Removing the offending version after the fact does not undo what an install-time payload may already have done.

Signal 03 — Inventory and Rotation Are the Durable Control, Not Attribution

The most consequential defender work this week has nothing to do with who ran the campaign. It is the unglamorous sequence of inventorying where Mastra appears across the estate — including transitive pulls buried in lockfiles — verifying resolved versions against known-good builds, and rotating any credential that sat within reach of an affected build pipeline. Attribution to a named cluster sharpens threat intelligence, but it does not change a single one of those steps.

Our assessment is that the durable control is treating CI/CD credentials as compromised by default whenever a poisoned install ran inside the pipeline. Registry and publish tokens go first, then cloud and deployment keys, then any long-lived secret the build job could read. Teams that rehearse this rotation as a routine response — rather than improvising it under time pressure — are the ones for whom a scope compromise is an afternoon of work instead of a breach.

Sources