critical

CVE

Not assigned

CWE

CWE-506, CWE-200, CWE-522, CWE-829

Affected Surface

@redhat-cloud-services npm namespace, RedHatInsights/frontend-components, RedHatInsights/javascript-clients, RedHatInsights/platform-frontend-ai-toolkit, GitHub Actions trusted publishing workflows, developer workstations and CI runners that installed affected @redhat-cloud-services versions

Red Hat published RHSB-2026-006 after multiple packages under the legitimate @redhat-cloud-services npm scope were compromised on 1 June 2026. Aikido, Wiz, Socket, and OX Security separately traced the malicious packages to a Miasma variant derived from the Mini Shai-Hulud npm worm tooling.

This is not a classic npm password theft story. The more important control-plane failure was GitHub access. A compromised Red Hat GitHub account pushed unauthorized orphan commits into RedHatInsights repositories, added GitHub Actions release workflows, requested GitHub OIDC identity tokens, and used npm trusted publishing to publish backdoored packages with provenance-looking metadata. Red Hat says engineering removed the compromised package versions and is checking whether any product builds included them.

Affected projects

The affected npm packages are frontend and client libraries in the @redhat-cloud-services namespace. Public writeups were updated during revocation, so teams should block and investigate the following package/version pairs rather than relying on only the first-published tables:

PackageAffected versions
@redhat-cloud-services/chrome2.3.1, 2.3.2, 2.3.4
@redhat-cloud-services/compliance-client4.0.3, 4.0.4, 4.0.6
@redhat-cloud-services/config-manager-client5.0.4, 5.0.5, 5.0.7
@redhat-cloud-services/entitlements-client4.0.11, 4.0.12, 4.0.14
@redhat-cloud-services/eslint-config-redhat-cloud-services3.2.1, 3.2.2, 3.2.4
@redhat-cloud-services/frontend-components7.7.2, 7.7.3, 7.7.5
@redhat-cloud-services/frontend-components-advisor-components3.8.2, 3.8.4, 3.8.5, 3.8.6
@redhat-cloud-services/frontend-components-config6.11.3, 6.11.4, 6.11.6
@redhat-cloud-services/frontend-components-config-utilities4.11.2, 4.11.3, 4.11.5
@redhat-cloud-services/frontend-components-notifications6.9.2, 6.9.3, 6.9.5
@redhat-cloud-services/frontend-components-remediations4.9.2, 4.9.3, 4.9.5
@redhat-cloud-services/frontend-components-testing1.2.1, 1.2.2, 1.2.4
@redhat-cloud-services/frontend-components-translations4.4.1, 4.4.2, 4.4.4
@redhat-cloud-services/frontend-components-utilities7.4.1, 7.4.2, 7.4.4
@redhat-cloud-services/hcc-feo-mcp0.3.1, 0.3.2, 0.3.4
@redhat-cloud-services/hcc-kessel-mcp0.3.1, 0.3.2, 0.3.4
@redhat-cloud-services/hcc-pf-mcp0.6.1, 0.6.2, 0.6.4
@redhat-cloud-services/host-inventory-client5.0.3, 5.0.4, 5.0.6
@redhat-cloud-services/insights-client4.0.4, 4.0.5, 4.0.7
@redhat-cloud-services/integrations-client6.0.4, 6.0.5, 6.0.7
@redhat-cloud-services/javascript-clients-shared2.0.8, 2.0.9, 2.0.11
@redhat-cloud-services/notifications-client6.1.4, 6.1.5, 6.1.7
@redhat-cloud-services/patch-client4.0.4, 4.0.5, 4.0.6, 4.0.7
@redhat-cloud-services/quickstarts-client4.0.11, 4.0.12, 4.0.14
@redhat-cloud-services/rbac-client9.0.3, 9.0.4, 9.0.6
@redhat-cloud-services/remediations-client4.0.4, 4.0.5, 4.0.7
@redhat-cloud-services/rule-components4.7.2, 4.7.3, 4.7.5
@redhat-cloud-services/sources-client3.0.10, 3.0.11, 3.0.13
@redhat-cloud-services/topological-inventory-client3.0.10, 3.0.11, 3.0.13
@redhat-cloud-services/tsc-transform-imports1.2.2, 1.2.4, 1.2.5, 1.2.6
@redhat-cloud-services/types3.6.1, 3.6.2, 3.6.4
@redhat-cloud-services/vulnerabilities-client2.1.8, 2.1.9, 2.1.11

The upstream repositories reported in public analysis include:

RedHatInsights/frontend-components
RedHatInsights/javascript-clients
RedHatInsights/platform-frontend-ai-toolkit

Trusted publishing became the delivery path

The malicious commits added a release workflow shaped like this:

name: release
on:
  push:
    branches: ["*"]
jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
      - uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6
      - name: prepare
        run: bun run _index.js
        env:
          OIDC_PACKAGES: "@redhat-cloud-services/frontend-components,..."

The critical line is id-token: write. In a trusted-publishing setup, GitHub Actions can mint a short-lived OIDC token that npm accepts for publication. That removes the long-lived npm token from CI, which is good, but it does not protect the package if an attacker can run a malicious workflow inside a trusted repository context.

In this incident, the unauthorized workflow did three things defenders should model explicitly:

  1. Triggered on attacker-controlled branch pushes.
  2. Requested the OIDC token from GitHub Actions.
  3. Executed an obfuscated Bun script that published modified package tarballs.

That means valid-looking provenance is not equivalent to reviewed source. Provenance answers “which workflow produced this artifact”; it does not prove the workflow or commit was legitimate.

Install-time execution

The published npm packages added a preinstall hook:

{
  "scripts": {
    "preinstall": "node index.js"
  }
}

preinstall runs before the dependent application imports the package. A compromised transitive frontend package can therefore execute on:

developer laptops
CI runners
container image builds
release automation
internal package smoke tests
dependency update bots

Researchers reported unusually large, heavily obfuscated index.js payloads using eval() and ROT-style decoding. OX Security also described deeper-stage payloads involving Bun installers, memory-dump behavior on Windows, Linux, and macOS, Claude Code configuration infection, GitHub Actions data leakage, and further Python/JavaScript download stages.

Credential targets

Miasma keeps the broad Mini Shai-Hulud credential sweep and adds stronger cloud-identity collection. The target set includes:

GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN
npm and PyPI publish credentials
AWS access keys, profiles, ECS and EC2 metadata credentials
GCP application-default credentials and service-account material
Azure service-principal, managed-identity, and Key Vault material
HashiCorp Vault tokens
Kubernetes service-account tokens and kubeconfig files
SSH private keys
Docker registry credentials
GPG keys
.env files and filesystem secret patterns
Claude Code and VS Code configuration

Several reports observed exfiltration through attacker-created public GitHub repositories whose description was Miasma: The Spreading Blight. Wiz also reported a GCP collection user agent of google-api-nodejs-client/7.0.0 gl-node/20.11.0 gccl/7.0.0.

Detection

Search source trees, lockfiles, and CI artifacts for the affected package names and versions. For npm projects:

rg -n \
  "@redhat-cloud-services/(chrome|frontend-components|rbac-client|types|vulnerabilities-client|hcc-.*-mcp)" \
  package.json package-lock.json npm-shrinkwrap.json pnpm-lock.yaml yarn.lock

Then inspect installed package contents and build logs for install-time execution:

rg -n \
  "\"preinstall\"\\s*:\\s*\"node index\\.js\"|Miasma: The Spreading Blight|api\\.anthropic\\.com|IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner" \
  node_modules .github ~/.config ~/.claude .vscode

For GitHub organizations, look for unexpected repositories, unexpected public repositories containing secret dumps, and workflow runs that requested OIDC tokens from unusual branches:

gh run list --all --json databaseId,displayTitle,event,headBranch,status,createdAt

Review repository history for orphan-looking release branches such as oidc-*, unauthorized .github/workflows/codeql.yml files, and unexpected setup scripts such as .github/setup.js or _index.js.

Response guidance

Treat installation of an affected version as code execution, not as a harmless dependency resolution event.

  1. Isolate affected developer machines, CI runners, and build containers before rotating secrets from a clean system.
  2. Preserve package-lock files, build logs, shell history, workflow logs, and suspicious GitHub repositories for scoping.
  3. Remove affected package versions and reinstall with lifecycle scripts disabled while investigating:
npm ci --ignore-scripts
  1. Rotate GitHub, npm, cloud, Vault, Kubernetes, Docker, PyPI, SSH, and GPG credentials that were reachable from affected hosts.
  2. Invalidate release artifacts built during the exposure window unless the build environment is proven clean.
  3. Audit trusted-publishing repositories for workflows that can request id-token: write on unprotected branches.

The hard lesson is that tokenless publishing is still a privileged release path. It should be protected with branch restrictions, required reviews for workflow changes, CODEOWNERS on .github/workflows, environment approvals, short runner lifetimes, and downstream malware scanning of artifacts before publication.

References