On June 1, an attacker compromised a Red Hat employee’s GitHub account and used it to publish the Miasma worm across 32 packages in the @redhat-cloud-services npm scope. Nothing about the publish was technically anomalous. The account had legitimate maintainer rights. GitHub OIDC trusted-publishing generated short-lived signing tokens through the normal workflow. The packages landed in the npm registry carrying valid SLSA provenance attestations. Consumers running automated dependency updates pulled the worm alongside legitimate packages. The attestations verified successfully.

That last sentence is the thing worth understanding. SLSA provenance attestations were designed to verify that a package was built from a specific source repository by a specific signing identity. They verified exactly that. The signing identity was the legitimate maintainer’s GitHub account. The source repository was the real Red Hat repository, where the attacker had briefly pushed malicious code before the push was caught. Every link in the provenance chain was technically correct. None of it detected the compromise.

The same week, a separate unattributed actor published codexui-android to npm, a package name chosen to surface in searches for OpenAI Codex Android development tooling. Developers who installed it had their Codex authentication tokens exfiltrated. A third independent operation, the Mini Shai-Hulud worm maintained by a Chinese-speaking threat actor tracked as TeamPCP across ten consecutive weeks of activity, confirmed propagation into 170-plus npm and PyPI packages this week, reaching TanStack, Mistral AI SDK, UiPath, and the OpenSearch JavaScript client. Two OpenAI employee devices were confirmed compromised, and the worm achieved access to internal source code repositories.

Three actors, three techniques, one target, one week. They did not coordinate. The convergence is the point.

What OIDC Trusted-Publishing Actually Changed

GitHub introduced OIDC trusted-publishing for npm in 2023 as a genuine security improvement. The problem it addressed was real: CI pipelines storing long-lived npm publish tokens as repository secrets that could be exfiltrated in a supply chain attack. OIDC replaced long-lived tokens with short-lived ones minted on demand by GitHub’s identity provider during a workflow run. The compromise of a CI environment no longer yielded a credential that worked next week. The security community received it as progress.

The risk transfer that came with it received less attention. Long-lived stored credentials can be detected: they sit in secret management systems, show up in access logs, and can be rotated or revoked on discovery. OIDC tokens are ephemeral by design. They expire after the workflow run. There is no credential to detect and no history to audit after the fact. The security improvement that eliminated the long-lived token problem simultaneously eliminated the forensic artifact.

More importantly, OIDC trusted-publishing shifted the security boundary from credential integrity to account integrity. A stolen npm token used to be the threat. A compromised GitHub account that can mint its own tokens is now the equivalent threat, and it is a harder one to defend. GitHub accounts are compromised via phishing and credential stuffing at scale. The account compromise that produced Miasma left no token in a secrets vault. The attacker authenticated normally, triggered the OIDC workflow, received a legitimate ephemeral token, and published. From the npm registry’s perspective, this was a valid, signed, attested publish from an authorized account. The registry trusted the token because the token was trustworthy. The account behind it was not.

SLSA provenance attestation did not help here, and understanding why matters. SLSA level 2 and higher attest that a build was produced in a specific environment by a specific identity. When that identity is a compromised GitHub account, SLSA correctly attests that the malicious build was produced in the attacker-controlled workflow by the attacker’s OIDC-authenticated identity. The chain of custody is accurate. The artifact is malicious. These two facts are compatible, and SLSA has no mechanism to resolve the contradiction because it does not evaluate intent, only identity and provenance.

A Surface Under Sustained Adversarial Pressure

The Miasma and Codex token attacks would be notable standalone incidents. Against the backdrop of TeamPCP’s Mini Shai-Hulud campaign, which has run for ten consecutive weeks across this tracking cycle, they become something more structurally significant. Three independent actors with different objectives and different techniques converged on npm in the same calendar week not because they were coordinating but because they were individually making the same rational calculation: npm is a high-value, high-return attack surface with weak enough defenses to justify sustained investment.

TeamPCP’s ten-week campaign is the most operationally instructive data point. The group, assessed as a Chinese-speaking nation-state actor, has propagated through the npm and PyPI dependency graphs systematically since at least W15. The propagation technique exploits the fact that the npm dependency graph connects packages transitively, so a compromise of a widely-used utility or SDK reaches every downstream consumer without requiring a separate attack on each one. TanStack is a dependency in thousands of frontend projects. OpenSearch JS client is embedded in enterprise search infrastructure. Mistral AI SDK is being pulled into AI pipeline tooling at significant scale. Each confirmed infection in Mini Shai-Hulud’s propagation path is less a new attack than a multiplier applied to a single upstream compromise.

The concurrent compromise of two OpenAI employee devices and the subsequent internal source code repository access illustrates how far that multiplier extends. The initial infection vector was an npm package in a developer’s toolchain. The endpoint is internal source code. The path between them did not require a second attack or a separate vulnerability. The developer installed a package, the package ran code, the code had access to everything the developer had access to. That chain is how Mini Shai-Hulud has operated for ten weeks, and nothing in the npm security model currently breaks it at the point where it matters: at installation time, before execution.

Where This Goes

npm’s GitHub OIDC integration is not a mistake to be reverted. Long-lived stored credentials were worse. But the security model that treats a valid OIDC-minted token as sufficient authorization for a publish has a gap that three independent actors found this week. That gap is account-level security, and it sits outside npm’s visibility.

GitHub needs to treat account compromise signals as publish-time risk signals. Anomalous account behavior in the hours before a publish, a first-time publish from a newly configured workflow, a maintainer account with no recent activity that suddenly triggers a publishing workflow: these are the behavioral fingerprints of the Miasma attack, and none of them are currently checked at publish time. The short-lived token is valid. The question is whether the account issuing the request to generate that token is behaving normally.

At the consumer side, SLSA provenance attestation should be understood for what it currently is: a guarantee about build provenance, not a guarantee about account integrity. The two are not the same, and the difference matters more in the current threat environment than it did when SLSA was designed. Attestation that shows a package was built from a specific repository by a specific account tells you nothing about whether that account was compromised at the time. It provides auditability, not assurance.

The supply chain security community spent three years converging on SLSA and OIDC trusted-publishing as the recommended controls for npm security. Three independent actors in one week tested those controls against the threat they were not designed for. The controls held for the problem they were designed to solve. The attack surface moved to the account layer, and that layer has no equivalent solution deployed at scale. Yet.

Security Unlocked publishes weekly threat intelligence and strategic analysis. This post is based on intelligence collected June 1 - June 8, 2026.