Decoding the world of cybersecurity

Red Hat packages hit npm supply chain

A reported Red Hat npm package compromise puts trusted namespaces, CI/CD publishing, cloud credentials, and developer secrets under fresh software supply-chain scrutiny.

Red Hat packages hit npm supply chain
Summary
  • Aikido says 96 versions across 32 official Red Hat cloud-services npm packages were compromised.
  • The reported payload targeted credentials and appears to have been published through GitHub Actions OIDC rather than a stolen npm token.
  • CI/CD environments often hold cloud, SSH, npm, and deployment secrets, making package compromise a wider infrastructure exposure.

Packages published under Red Hat’s cloud-services npm scope were compromised with a credential-stealing worm, according to technical analysis by Aikido, adding another trusted-namespace incident to a worsening software supply-chain cycle.

Aikido said it detected the compromise on 1 June 2026 and identified 96 affected versions across 32 packages. The company said the compromised packages had combined weekly downloads of 116,991 and that the malware resembled Mini Shai-Hulud tooling, a credential-stealing supply-chain worm associated with recent package incidents.

The reported publishing route is the most consequential technical detail. Aikido said the packages were published through GitHub Actions OIDC, indicating that the CI/CD pipeline was compromised rather than a simple stolen npm token. If a build and publishing path is compromised, the response cannot stop at removing affected package versions. The pipeline, its permissions, and its federated identity model all need review.

Aikido advised anyone who installed affected package versions from 1 June onwards to treat CI secrets, cloud credentials, SSH keys, and npm tokens as compromised and rotate them immediately. That posture reflects the value of developer environments and automation pipelines, which may hold credentials that unlock production or near-production systems.

The incident is adjacent to, but distinct from, recent dependency-confusion and typosquatting campaigns. Those attacks often rely on lookalike names, namespace confusion, or assumptions in package resolution. In this case, the reported issue involves official packages under a recognised vendor scope. Trusted namespace controls alone cannot address a compromised publishing process.

Open-source package governance often focuses on package popularity, maintainer reputation, and whether a dependency name looks legitimate. Those checks do not answer what happens when a legitimate publishing workflow is abused. A signed or official package can still become malicious if the process that produced it has been compromised.

The enterprise exposure is concentrated in build systems, developer laptops, CI runners, container build pipelines, and internal package mirrors. Organisations that proxy npm packages internally may need to determine whether compromised versions were cached, whether build logs show installation, and whether downstream artefacts incorporated affected packages. Where the payload targeted secrets, remediation should include credential rotation and review of subsequent access, not only package removal.

Software bill of materials programmes are useful only when they can be queried quickly against compromised versions and tied to deployed artefacts. The same applies to CI/CD logs, artefact registries, and cloud access trails. The response depends on evidence that may be distributed across development, platform engineering, security, and cloud teams.

Supplier accountability also comes into focus. Official package namespaces carry implied trust. Customers and downstream developers expect vendors to control publishing paths, monitor anomalous releases, and communicate clearly when compromise is suspected. Where OIDC-based publishing is involved, scrutiny extends to workload identity, repository permissions, branch protections, release approvals, and separation between build and publish roles.

The incident reinforces the treatment of software delivery pipelines as privileged infrastructure. Package registries, CI workflows, identity federation, secrets management, and dependency ingestion now form part of the enterprise control plane. When official packages are compromised, the failure can reach procurement, engineering governance, cloud access, and incident response at once.

×