On May 29, June 1, June 17, and June 24, 2026, the same story kept repeating with different package names. Microsoft documented 33 malicious npm packages abusing dependency confusion. Red Hat disclosed a compromise of the @redhat-cloud-services namespace through a compromised GitHub account. Microsoft then reported a takeover of the ehindero maintainer account that poisoned more than 140 mastra and @mastra packages. Two days later, StepSecurity described 20 Leo Platform packages published in less than three seconds with a payload designed to steal secrets from GitHub Actions runners, cloud credential stores, package registries, and password managers.

The operational lesson is blunt: the attacker does not need to own the public registry if they can own the maintainer, the repo, or the workflow that publishes to it. For founders and operators, that turns supply-chain security from a developer hygiene problem into a release-risk problem. If your build and publish path can be abused, then a routine dependency update can become a company-wide incident.

What June 2026 actually proved

The attacks in late May and June did not rely on one neat trick. They spanned dependency confusion, maintainer compromise, pipeline abuse, and install-time execution. In Microsoft’s May 29 report, the malicious packages were registered under organizational scopes that mirrored internal namespaces, a classic dependency confusion pattern. On June 1, Red Hat’s disclosure showed the blast radius when a compromised GitHub account can inject malicious code into packages maintained in an organization repo. On June 17, Microsoft’s Mastra write-up showed how a dormant contributor account can be used to republish an entire package scope. On June 24, the Leo Platform incident showed that a fast, coordinated publish burst can carry a CI/CD attack toolkit, not just a simple backdoor.

That matters because each of those paths reaches a different control owner. Dependency confusion is usually a package manager problem. Maintainer compromise is an identity and access problem. CI/CD abuse is a workflow and runner problem. Install-time payloads are a developer workstation and secret-handling problem. If you only buy one class of scanner, you will miss the other three.

There is also a second-order risk: credential theft turns one compromise into many. If malware steals npm tokens, GitHub tokens, or cloud credentials, the first package can become the launch point for a broader campaign. Microsoft’s Red Hat analysis called out exactly that cascading effect: stolen npm tokens enable further package poisoning, stolen GitHub tokens enable repo manipulation, and stolen cloud credentials enable wider access. That is why a package incident should be treated like a control-plane incident, not just a bad artifact.

Why trusted publishing helps, but only if you use it correctly

npm’s current guidance is strong: trusted publishing uses OpenID Connect instead of long-lived npm tokens, and provenance attestations are generated automatically when you publish that way. npm also says that trusted publisher configurations created before May 20, 2026 were grandfathered into older behavior, while newer configurations require explicit allowed actions. That date matters because it shows the ecosystem is tightening the release path, but the security win only exists if the workflow, runner, and repo identity are actually trustworthy.

This is where SLSA becomes useful. The SLSA threat model says the right move is to compare provenance against what you expect from the package. In plain English: do not just ask whether an artifact has a signature or attestation. Ask whether the source commit, build system, workflow identity, and artifact hash all line up with the release you intended to ship. npm’s own docs now support that workflow by letting you verify registry signatures and provenance attestations during audit. Missing or invalid records should be treated as an error, not a warning you click past.

My read is that provenance is only valuable when it is tied to a known source repo, a protected release workflow, and a build environment that attackers cannot quietly reuse. If a maintainer account is compromised, or a GitHub Actions workflow is weaponized, a malicious package can still look legitimate at the registry boundary. Trusted publishing reduces token theft. It does not magically verify intent.

A control stack a small team can actually run

Most SMBs do not need a grand supply-chain platform on day one. They need a few hard controls that force attackers to work much harder.

  • Use trusted publishing for releases and remove long-lived npm publish tokens wherever possible.
  • Keep release workflows separate from normal CI, and restrict id-token: write and publish permissions to the smallest possible job.
  • Protect the source repo with branch protection, code review, and explicit checks on workflow files, because workflow edits are often the real publishing surface.
  • Require provenance and registry signature checks before promotion, and fail closed when they are missing.
  • Generate an SBOM for each release, then diff it against the previous release to spot new top-level dependencies, new install scripts, or unexpected transitive changes.
  • Review maintainers, repo ownership, and publish history before you trust an update, especially for packages that can run code during install.
  • Separate build privileges from signing privileges, and isolate runners so stolen secrets do not expose the whole account.

That last point matters more than it sounds. A lot of small teams let the same workflow build, test, sign, and publish. That is convenient, but it means one compromise gets you everything. A better model is to treat build, signing, and release approval as separate trust steps, even if they live in the same CI system.

For vendor and open source review, the question should not be “Is this package popular?” It should be “What can this package do when installed, who can publish it, and what evidence do we have that this artifact came from the source we think it did?” If the answer depends on a maintainer account, a GitHub Action, and a maybe-signed tarball, that is not enough.

Do the boring work before the next burst

The June 2026 incidents are a reminder that package ecosystems fail fast when identity and automation are too broad. The fix is not to stop using npm, GitHub Actions, or open source. The fix is to make every release prove where it came from, what it contains, and which workflow was allowed to publish it. If your current process cannot answer those questions quickly, the next dependency update is already a security event.

For teams that want a practical starting point, the right first move is a release-path review: map who can publish, which runners can mint credentials, where signatures and provenance are checked, and how SBOM changes are reviewed. That is the kind of control GGEZ helps teams design, because supply-chain security only gets real when the release lane is harder to abuse than the app itself.

Why this matters

GGEZ can help teams harden the release lane: dependency and CI/CD controls, trusted publishing setup, SBOM and provenance workflow design, and vendor/open-source risk review that treats every package release as a security event.

Sources

Need help applying this?

If supply chain risk is becoming a board, buyer, or audit concern, GGEZ can help turn it into a practical hardening plan. See the related service area.