31 Red Hat npm packages backdoored in 72 seconds

RL researchers have uncovered a large-scale, coordinated supply chain attack targeting the @redhat-cloud-services npm scope. On June 1, 2026, an attacker published malicious versions of 31 packages in a 72-second window, injecting obfuscated preinstall malware into every one.

The affected packages collectively represent approximately 9.8 million total downloads and cover the full breadth of Red Hat's Hybrid Cloud Console JavaScript ecosystem — UI components, API clients, build tooling, configuration utilities, and MCP servers.

Scale of the attack

Total: 31 packages, ~9.8 million downloads

The 72-second window

The malicious versions span from 10:54:09 to 10:55:21 UTC — 72 seconds from first to last publish. This is not a human typing at a terminal; it is automated scripted publishing. The attacker prepared all 31 poisoned archives in advance and executed a single batch push.

The packages span two different GitHub source repositories — RedHatInsights/frontend-components and RedHatInsights/javascript-clients — confirming that the attacker had access to the @redhat-cloud-services npm scope credentials directly, not to any individual repository. This is a scope-level account compromise.

What changed in every package

The modification is identical across all 31 packages: exactly two files changed compared to the prior clean version.

package.json — a preinstall script entry is added, pointing execution at index.js:

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

index.js — the package's main entry point is completely replaced with a malicious payload. In the clean referential versions, index.js contains the package's normal JavaScript exports. In the malicious versions, it is a single-line obfuscated dropper.

No other files are touched. The surgical precision — two files, same modification pattern, 31 packages — is another indicator of automated tooling.

The obfuscation technique: ROT-N + AES-128-GCM + obfuscator.io

Each malicious index.js follows the same outer structure — but what it conceals is a three-layer attack pipeline.

Outer wrapper:

javascript
try{eval(function(s,n){
  return s.replace(/[a-zA-Z]/g, function(c) {
    var b = c <= "Z" ? 65 : 97;
    return String.fromCharCode((c.charCodeAt(0) - b + n) % 26 + b)
  })
}([/* ~500,000 integer char codes */].map(function(c){return String.fromCharCode(c)}).join(""), /* N */))
}catch(e){console.log("wrapper:",e.message||e)}

Layer 1 — ROT-N caesar cipher. The outer call encodes ~4 MB of character codes. String.fromCharCode reconstructs a string, then the function(s,n) applies a ROT-N rotation to all alphabetic characters. The rotation value N differs per package — making each blob visually distinct while using the same decode engine. For the chrome package, N = 3.

Layer 2 — AES-128-GCM decryption (two blobs). The ROT-decoded string is an async IIFE that decrypts two encrypted blobs using Node.js's crypto.createDecipheriv("aes-128-gcm", ...):

javascript
(async()=>{try{
const _c = await import("node:crypto");
const _d = (k, i, a, c) => {
  const d = _c.createDecipheriv("aes-128-gcm", Buffer.from(k,"hex"), Buffer.from(i,"hex"), {authTagLength:16});
  d.setAuthTag(Buffer.from(a,"hex"));
  return Buffer.concat([d.update(Buffer.from(c,"hex")), d.final()])
};
const _b = _d(key_b, iv_b, tag_b, ciphertext_b);  // bun downloader
const _p = _d(key_p, iv_p, tag_p, ciphertext_p);  // main payload

GCM (Galois/Counter Mode) provides authenticated encryption: any tampering with the ciphertext causes decryption to fail, protecting the payload from modification. Keys, IVs, and auth tags are unique per package.

_b — bun runtime downloader. The first blob decrypts to JavaScript that downloads the bun runtime (v1.3.13) from github.com/oven-sh/bun/releases into a temp directory, makes it executable, and stores the path as globalThis.getBunPath. This is a legitimate binary from a legitimate source — a deliberate choice to avoid suspicious network traffic.

Layer 3 — Obfuscator.io payload (_p, 634 KB). The second blob — the actual payload — is written to a temp file and executed with bun. If bun is already present in the environment, it is used directly. Otherwise _b is eval'd first. After execution the temp file is deleted. The 634 KB payload is heavily obfuscated using the obfuscator.io toolchain (string array encoding, control flow flattening, identifier mangling).

The try/catch at every layer ensures silent execution: if any stage fails for any reason, no error surfaces in the build log.

Critically, every one of the 31 index.js files carries a unique SHA-256 hash. The attacker generated individually tailored payloads — rotation values, AES keys, IVs, auth tags, and ciphertexts all differ across packages. This defeats hash-based deduplication and means each package must be analyzed independently.

What the chrome payload does

Full decryption of the chrome package payload reveals a cloud credential stealer with worm propagation capabilities. The _p blob is a 634 KB bundled JavaScript program that performs several distinct functions when run with the bun runtime.

Credential harvesting. The payload reads and exfiltrates credentials from the developer's build environment via multiple collectors. Confirmed targets include:

CI/CD targeting. The payload checks GITHUB_REPOSITORY and GITHUB_WORKFLOW_REF to detect GitHub Actions environments. If the workflow reference matches an expected pattern, it triggers a separate, targeted exfiltration path before exiting. This allows quiet operation inside automated pipelines without leaving an unusual process running.

GitHub API exfiltration. Stolen credentials are formatted into structured reports and exfiltrated via the GitHub API. The payload contains a dedicated GitHub API client (githubFetch, githubJson) with Authorization header support. The command-and-control (C2) endpoint URL is stored encrypted under an additional layer (f4abccab2 decryptor) on top of the obfuscator.io string table, preventing static extraction.

Worm propagation. The payload contains a bQ() ROT-N function and pQ() payload generator identical in structure to the obfuscation used to encode the index.js files. This strongly suggests the payload is capable of generating new malicious package versions — using any npm credentials it steals to publish poisoned packages to additional scopes.

All 31 packages contain both _b and _p blobs — they are not specific to chrome. Decrypting _b across multiple packages confirms it carries identical bun downloader code in every case; only the AES-GCM key, IV, and authentication tag differ, making the binary blob unique while the decrypted function is the same. The _p payloads are all unique-keyed and have not been decrypted for the other 30 packages.

A structural split is visible from file sizes alone: four packages (chrome, frontend-components, frontend-components-advisor-components, sources-client) produce index.js files of ~4.05 MB, while the remaining 27 produce files of ~4.29 MB — approximately 238 KB more ciphertext in _p.

Detection: Behavioral indicators

ReversingLabs Spectra Assure's behavior analysis detects the injection through a cluster of indicators that are uniformly absent in the referential versions and uniformly present in the malicious ones:

Two additional indicators appear only in the chrome package payload:

The presence of HTTP connectivity and a repeating timer in the chrome payload indicates a more capable stage — one that establishes periodic callbacks, consistent with a persistent info-stealer or C2 beacon executing from the developer's environment. The chrome package, used in the Red Hat Hybrid Cloud Console shell, runs in browser-facing build environments with access to Red Hat infrastructure credentials.

Clean versions already published

By the time of analysis, legitimate maintainers had already pushed clean follow-up versions for all 31 packages (N+1 patch versions). The malicious versions have since been removed from npm. Any project that pinned to these exact versions or ran npm install in the window between publish and removal is affected.

Recommendations

• If you ran npm install on June 1, 2026 between ~10:54 and ~10:56 UTC and any of these packages are in your dependency tree — direct or transitive — treat the build environment as compromised. Rotate all credentials, tokens, SSH keys, and secrets accessible from that environment.
• Audit your lock files. Check package-lock.json or yarn.lock for exact version pins matching the malicious list above.
• Block the malicious hashes in Artifactory, Nexus, or any other artifact proxy. See the indicators of compromise (IoC) table below.
• Check transitive dependencies. Several of these packages are widely used as indirect dependencies; the total exposure is likely larger than direct installs suggest.
• Monitor for anomalous outbound connections from build agents, particularly HTTP traffic initiated by Node.js processes during npm install.

Indicators of Compromise (IOC)

All 31 malicious index.js hashes are unique (individually crafted payloads):

This attack illustrates the leverage a single scope-level credential compromise can provide: 31 packages, 9.8 million downloads, and a payload capable of self-propagation — all published in under two minutes. The individually crafted payloads across every package, the per-package AES-GCM key material, and the ROT-N variance are deliberate choices to defeat both hash-based detection and bulk analysis. That each package requires independent decryption to fully characterize is itself a structural defense the attacker built in.

ReversingLabs is continuing to monitor the @redhat-cloud-services scope and will update this post if additional affected versions or payload variants are identified. Full IoC coverage for all 31 packages is available in Spectra Assure. Teams using Spectra Assure to monitor open-source dependencies will have detected this attack via the BH13852 and BH13525 behavior indicators present across all affected versions.

Join RL's free Spectra Assure Community, which helps secure open-source development.