On June 1, an attacker with access to a single compromised GitHub account published 32 malicious packages under the @redhat-cloud-services npm namespace in a 72-second window. Those packages carried approximately 116,000 weekly downloads between them. The organizational namespace belonging to one of enterprise software’s most recognized vendors was the delivery mechanism, not a disguise around it. No one had to spoof a domain. No one had to intercept traffic. The name redhat-cloud-services did all the work.

That same week, the TeamPCP Mini Shai-Hulud campaign ran its eleventh consecutive week of developer trust infrastructure attacks across npm and PyPI. A third, separate actor conducted an OpenAI Codex token theft campaign targeting developer API credentials via the same registry. Three actors. Three different threat profiles (nation-state-affiliated, financially motivated worm, credentials thief). Three different objectives. One delivery infrastructure. In the same seven days.

This convergence is not coincidence. It is adversarial consensus.

What the Convergence Tells You

When three independent actors with no known coordination land on the same attack surface in the same week, the analytical question is not what they were doing. It is why all three independently reached the same conclusion about where to operate.

The answer is visible in how the Miasma worm was constructed. The @redhat-cloud-services namespace is not a random choice. It exploits a specific heuristic that developers use to evaluate package legitimacy: organizational namespace recognition. A Red Hat namespace implies a Red Hat package. The download count is high because the packages are real and widely used. The organizational identity signal is exact. Each of these indicators, individually, is the kind of signal developers are correctly taught to treat as a trust anchor. Together, they become the exploit surface, because all three signals can be reproduced with access to one compromised GitHub account and five minutes of work.

The Miasma payload then self-propagates by backdooring every npm package the victim account has publish rights to. The initial compromise cascades into secondary exposure across unrelated projects. Red Hat’s production deployment pipeline strips install-time scripts, which limited the direct blast radius for Red Hat’s own systems. Developer environments and CI/CD systems that pulled the packages between May 31 and June 2 before isolation are a different story.

Eleven Weeks of Documentation

The Red Hat incident is new this week. The TeamPCP Mini Shai-Hulud campaign is not. It has now run for eleven consecutive weeks, and it is worth looking at what eleven weeks of uninterrupted operation on npm and PyPI actually produced: ten distinct delivery vectors documented, poisoned packages published in the TanStack, Mistral AI, UiPath, and OpenSearch JavaScript client namespaces, 449 GB exfiltrated in a single six-hour operation, and reported access to two OpenAI employee devices. The June 12 OpenAI macOS code-signing certificate rotation deadline passed this week. Whether that rotation severed persistent access from earlier TeamPCP operations is not yet confirmed.

Eleven weeks means eleven consecutive weeks in which the underlying attack surface (namespace-based trust, no mandatory package signing, no verified publisher identity at install time) remained unchanged. The campaign continued not because it was undetected but because the structural conditions enabling it were not addressed. Individual malicious packages were removed. The trust model that made the packages plausible was not.

The third actor this week, targeting OpenAI Codex API credentials via npm, is the logical extension of the same assessment. If npm is an efficient delivery mechanism for malware, it is also an efficient mechanism for credential exfiltration. The credentials accessible during npm package execution in a typical CI/CD build context include cloud provider API keys, repository tokens, deployment credentials, and in environments where AI tooling is integrated, model API keys. The attack surface is not the registry itself. It is everything a package can reach during the build process.

The Trust Model Is the Vulnerability

None of this requires a CVE. The Miasma worm does not exploit a software vulnerability in npm. It exploits a cognitive heuristic: the assumption that namespace ownership implies content legitimacy. The collective adversarial intelligence that identified this surface predates this week. What this week confirms is that it is now a multi-actor operational standard, not a sophisticated nation-state technique.

Namespace verification in npm is not cryptographic. When the @redhat-cloud-services namespace is compromised, npm’s trust signals (organization name, package history, download count) all continue pointing toward legitimacy. There is no technical mechanism at install time that verifies the content of a versioned release against anything Red Hat cryptographically signed. The developer sees a familiar name with expected download numbers. The heuristic fires. The package installs.

This is not a problem unique to npm. PyPI’s organizational namespace model has the same structural property. The TeamPCP campaign has operated on both ecosystems simultaneously, specifically because both offer the same leverage: one compromised credential, organizational namespace access, ecosystem-wide trust.

Where This Goes

The medium-term fix is package signing. Sigstore and its associated tooling (cosign, the npm provenance attestation framework announced in 2023) provide cryptographic attestation that a package version was built and published by a specific identity in a verifiable build environment. When signing is enforced and verified at install time, namespace ownership alone is no longer sufficient to establish trust. The content has to be attested.

The problem is that npm’s signing infrastructure remains optional and adoption is uneven. Organizations can pin dependencies with hash verification today, which addresses the versioned-release substitution problem without waiting for ecosystem-wide signing adoption. They can audit their CI/CD pipeline secret exposure scope, specifically identifying which credentials are accessible to npm package execution context and whether that access is necessary. They can treat namespace identity as a starting point for scrutiny rather than a terminal trust signal.

None of that addresses the structural incentive problem. Mandatory package signing requires coordination across the npm ecosystem, the publisher community, and the tooling that integrates with the registry. The cost of adopting signing falls on package publishers, most of whom are not financially compensated for the security work. The cost of not adopting it falls on the organizations and developers who consume packages downstream. The adversarial consensus about npm as a high-yield surface will remain stable as long as that asymmetry holds.

Three actors operating simultaneously on the same registry in the same week is the most diagnostic data point from a week that included a record 206-CVE Patch Tuesday and a Qilin ransomware group exploiting a VPN zero-day for six weeks before public disclosure. The Patch Tuesday volume is about AI-accelerated discovery. The Qilin pre-disclosure window is about adversarial capability. The npm convergence is about something different: adversaries collectively finding a target that defenders have collectively underinvested in securing. That kind of assessment, once formed, does not reverse until the structural conditions change.

The namespace was the credential this week. Next week, it will be whatever npm alternative is equally undefended.

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