Red Hat npm Compromise Exposes Provenance Gaps

Red Hat published RHSB-2026-006 on June 1, 2026 and updated it on June 3 after a supply-chain compromise affected packages under the @redhat-cloud-services npm namespace. Red Hat says a compromised GitHub account was used to push unauthorized commits into repositories in the RedHatInsights organization, and that compromised versions were removed from npm after disclosure.

The important security point is not simply that an npm package was backdoored. Snyk and Microsoft both reported that the malicious releases abused a legitimate publishing path, including OpenID Connect based publishing and provenance signals, while using install-time scripts to steal developer, CI, cloud, npm, GitHub, Vault, and Kubernetes credentials. Provenance can tell teams where a package came from. It does not, by itself, prove that the code was supposed to be there.

Red Hat's bulletin says multiple packages published under the @redhat-cloud-services npm namespace were affected by a supply-chain compromise disclosed on June 1, 2026. Its initial investigation points to a compromised GitHub account that pushed unauthorized commits into repositories in the RedHatInsights GitHub organization. Red Hat says engineering removed compromised versions from npm after disclosure and is still conducting build-system and dependency-tracking analysis.

Red Hat also drew a boundary around product impact. The affected packages are frontend JavaScript libraries used in the Hybrid Cloud Console interface, and Red Hat says no release of the Hybrid Cloud Console was published during the compromise window. Red Hat further says its publication process includes protections that strip installation-time scripts from packages before deployment to console.redhat.com. Based on current findings, Red Hat says no customer action is required. That is a vendor claim about its own product pipeline, not a statement that every downstream npm consumer was safe.

Snyk reported that malicious code appeared in at least 32 package releases under the @redhat-cloud-services namespace and that the affected packages averaged roughly 80,000 weekly downloads combined. Snyk's writeup describes a preinstall hook that runs when a package is installed, before application code has to import anything. That detail changes the risk calculation: a development machine or CI runner can execute the payload just by resolving a bad version.

Microsoft's analysis identified 32 maliciously modified packages across more than 90 versions and said the upstream CI/CD pipeline allowed attackers to publish trojanized packages through the legitimate GitHub Actions OIDC publishing workflow. Microsoft says those packages carried authentic provenance signatures while embedding the Miasma campaign marker. The reported payload harvested credentials across GitHub, npm, AWS, Azure, GCP, HashiCorp Vault, Kubernetes, and developer systems, then supported worm-like propagation.

Trusted publishing and provenance are still good controls. npm's trusted publishing model uses an identity token from a supported CI/CD provider so packages can be published without long-lived npm access tokens in the workflow. GitHub's OpenID Connect model lets a workflow request short-lived identity tokens and avoid static cloud secrets. Those controls reduce one old failure mode: stolen durable publishing tokens sitting in configuration files.

The Red Hat npm compromise shows the next failure mode. If an attacker can push to a path that is allowed to run the trusted publishing workflow, the package may look correctly published while still being malicious. Provenance answers a narrow question: did this artifact come from this repository and workflow path? Security teams still need branch, environment, tag, actor, review, and workflow-change controls that decide whether the workflow should have run at all.

npm lifecycle scripts are powerful because many packages need build steps. They are also dangerous because install-time code runs in the context of the machine installing the package. Snyk and Microsoft both emphasize the preinstall path because it gives a malicious dependency access to developer environment variables, local configuration, CI tokens, npm credentials, SSH material, cloud metadata, build logs, and package-manager state before normal application safeguards apply.

For Protocol Report readers, the practical risk is broader than one frontend package. Chat, community, crypto, AI-agent, and SaaS teams often run automated dependency updates on CI runners that hold registry credentials, cloud roles, signing keys, release tokens, Slack or Discord webhooks, and production deploy permissions. A malicious install script on the wrong runner can turn a package incident into a cloud identity incident.

Start with dependency evidence. Search package-lock.json, pnpm-lock.yaml, yarn.lock, SBOMs, build logs, and dependency-cache metadata for @redhat-cloud-services packages installed after the first malicious publication on June 1, 2026. Compare resolved versions against Red Hat's bulletin and the Snyk and Microsoft affected-version lists. Do not assume direct dependencies are the only problem; transitive installs and cached CI layers can matter.

Then scope credentials by execution environment. If a developer workstation, ephemeral runner, self-hosted runner, container image build, preview environment, or release workflow installed an affected package, identify every secret and identity that environment could reach. Rotate npm tokens, GitHub tokens, deploy keys, cloud credentials, API keys, webhook secrets, package-registry tokens, and Vault or Kubernetes material where exposure is plausible. Review public or unexpected repositories created by developer accounts during the exposure window, a hunting signal Microsoft called out for this campaign.

Publishing workflows should be constrained more tightly than repository membership. Require protected branches or signed tags for releases, pin OIDC trust policies to expected branches and workflow files where the registry or cloud provider supports it, require review for workflow changes, and minimize GITHUB_TOKEN permissions by default. Separate build, test, provenance generation, and publishing permissions so one pushed branch cannot quietly become a release authority.

On the consumption side, use lockfile review, dependency update staging, script-disabled installs for analysis, short-lived CI identities, isolated runners, outbound egress controls, and secrets that are scoped to the job rather than the repository. None of those controls removes supply-chain risk. Together they make the next malicious package less able to become a full developer-environment compromise.

The public record still leaves important gaps. Red Hat has not published a full final root-cause narrative, the exact original account-compromise path is not settled in the vendor bulletin, and downstream exposure will vary by who installed which package version on which machine. Third-party researchers have provided strong technical analysis of the payload, but they cannot know every customer build path or credential reachable from every affected install.

That uncertainty argues for a measured but serious response. Red Hat customers should follow Red Hat's bulletin for product-impact updates. Teams that installed affected npm packages should not wait for a perfect external inventory before revoking high-value tokens and reviewing CI runners. The boundary is local: if the malicious package executed in an environment that could touch secrets, that environment deserves incident handling.