Miasma npm Attack: Swiss CI/CD Hardening Guide 2026

On 1 June 2026, attackers compromised at least 32 packages published under the @redhat-cloud-services npm namespace, packages with a combined weekly download volume around 80,000. The payload, named Miasma, did not slip in through a typo-squat or an abandoned dependency. The attacker used a hijacked Red Hat employee GitHub account to push malicious orphan commits to RedHatInsights repositories, then triggered the legitimate GitHub Actions workflows to request OpenID Connect tokens and publish the Trojanised packages — complete with valid SLSA provenance. The malware itself was derived from "Mini Shai-Hulud," a self-propagating credential-stealer that had been open-sourced weeks earlier, and it swept for secrets across cloud providers, CI/CD systems, and developer tooling: GitHub Actions secrets, AWS access keys, GCP credentials, Azure service principals, HashiCorp Vault tokens, Kubernetes service accounts, and npm and PyPI publish tokens. Two weeks later, a similar campaign pushed a malicious easy-day-js package into the dependency tree of an entire npm organisation. The pattern is now unmistakable, and it breaks an assumption many Swiss development teams have quietly relied on.

Why Provenance Did Not Save Anyone

The defensive narrative of the last two years told developers to demand provenance: prefer packages built in transparent, attested pipelines, verify SLSA metadata, and trust artefacts whose origin can be cryptographically traced to a known source. Miasma satisfied that test. Because the malicious packages were built and published by the genuine GitHub Actions workflows — using OIDC tokens those workflows are designed to request — the resulting artefacts carried authentic provenance pointing at the real repository. The provenance was not forged; it was correct. It attested truthfully that malware had been built by the legitimate pipeline, because the attacker had subverted the pipeline rather than bypassing it.

This is the structural lesson. Provenance answers "was this artefact built by the expected process?" It does not answer "was the expected process trustworthy at build time?" Once an attacker controls a commit into the source repository or the credentials the pipeline uses, every downstream attestation becomes a high-integrity statement about a compromised input. SLSA, signed builds, and OIDC-based publishing are genuine improvements, but they relocate trust to the source repository and the CI/CD identity layer — and that is exactly where Miasma struck.

The Real Attack Surface Is the Pipeline Identity

The mechanics deserve attention because they generalise to almost any organisation using cloud-native CI/CD. GitHub Actions OIDC lets a workflow exchange a short-lived identity token for credentials to a cloud account or a package registry, eliminating long-lived secrets — a genuinely good practice. But the trust is only as tight as the conditions placed on that token. If a registry or cloud role accepts any workflow from a repository, then an attacker who can push a commit — through a stolen maintainer account, a malicious pull request that runs in a privileged context, or a poisoned dependency in the build itself — can make the pipeline mint a valid token and publish on the project's behalf.

Miasma's credential sweep then compounds the damage. The payload's purpose was to harvest exactly the secrets that CI/CD environments accumulate: cloud keys, Vault tokens, Kubernetes service accounts, registry publish tokens. Each stolen credential is a seed for the next hop, which is why this class of malware self-propagates — a publish token captured from one project becomes the means to Trojanise the next. For a Swiss software vendor, fintech, or any organisation shipping code, the exposure is not limited to the packages it consumes; it includes the packages it produces and the cloud estate its pipelines can reach.

What This Means for Swiss Teams Under the CRA

The regulatory backdrop sharpens the urgency. The EU Cyber Resilience Act imposes secure-development and vulnerability-handling obligations on manufacturers placing products with digital elements on the EU market, and a Swiss software exporter is squarely in scope. A build pipeline that can be coerced into publishing malware with authentic provenance is not a secure development environment in any meaningful sense, and an incident in which a Swiss-published package is Trojanised would engage both CRA vulnerability-reporting duties and, depending on data impact, breach-notification obligations under the revised Data Protection Act. Supply-chain security has moved from an engineering preference to a compliance requirement, and the controls that satisfy auditors are the same ones that would have blunted Miasma.

The encouraging part is that the hardening is concrete and largely free of new tooling. It is a matter of tightening trust conditions that are too often left at their permissive defaults: scoping OIDC trust narrowly, isolating builds, constraining what a pipeline identity can publish, and assuming that any single credential can be stolen. None of this is exotic; it is the disciplined application of capabilities most teams already have and have not fully configured.

• Scope OIDC trust to specific branches, tags, and environments — never the whole repository. Configure cloud roles and registry trust to accept only protected-branch or release workflows, so a token from an arbitrary commit or pull-request context cannot publish or reach production credentials.
• Require protected branches and reviewed releases for anything that publishes. Gate package publication behind branch protection, mandatory review, and release approval, so a single hijacked maintainer account cannot push a release commit unchecked.
• Isolate the build from the publish step. Run dependency installation and build in an environment that has no access to publish tokens or production cloud credentials; grant publishing rights only to a separate, minimal, audited job.
• Pin and verify dependencies with lockfiles and integrity hashes. Enforce npm ci against committed lockfiles, enable integrity checking, and review lockfile diffs so an unexpected new transitive dependency surfaces in code review rather than at runtime.
• Make every pipeline secret short-lived and single-purpose. Prefer OIDC-issued ephemeral credentials over stored long-lived keys, scope each to one task, and ensure stolen tokens expire before they can be widely reused.
• Monitor your own publish events and registry activity. Alert on any package publication, version bump, or token use that does not correspond to an authorised release, and treat an unexplained publish as an incident, not a curiosity.
• Rehearse the maintainer-account-compromise scenario. Run a tabletop in which a developer's GitHub credentials are stolen: confirm you can revoke tokens, force re-authentication, yank a malicious package version, and notify downstream consumers within hours.

The supply-chain attacks of 2026 have converged on a single insight: it is far more efficient to compromise the place where trusted software is built than to defeat the controls that verify it afterwards. Miasma is the clearest expression of that shift because it weaponised the trust infrastructure itself, turning provenance into a truthful endorsement of malware. Swiss teams cannot opt out of open-source dependencies or cloud-native pipelines, and they should not try. What they can do is stop treating the build system as a trusted interior and start treating it as an exposed perimeter — one with its own identities, its own credentials, and its own attack surface that deserves the same scrutiny as a public-facing application. The pipeline is production. Securing it is now the work.