Malicious npm releases found in dozens of @redhat-cloud-services packages

The issue

On June 1 2026, security researcher sailikhith‑stepsecurity opened an issue in the public RedHatInsights/javascript-clients repository flagging a supply‑chain attack that targeted the @redhat-cloud-services npm namespace. The report, also published on the Step Security blog (multiple‑redhat‑cloud‑services‑npm‑packages‑compromised), lists 31 packages and 95 specific versions that contain malicious payloads.

The compromised releases were published between late 2025 and early 2026. They include client libraries for Chrome integration, compliance, configuration management, entitlement handling, and a host of UI component packs used across Red Hat’s cloud console applications. The malicious code was a small JavaScript snippet that, when executed, attempted to exfiltrate environment variables and npm token credentials to an external server.

Why it matters

Developers building on Red Hat’s cloud services often pull these packages directly from the public npm registry. Because the affected versions were marked as stable releases, many projects automatically upgraded to them via standard npm install or yarn add commands. The attack therefore had the potential to spread silently across a large number of downstream applications, including internal tools and customer‑facing portals.

Supply‑chain attacks of this kind are especially concerning for two reasons:

1. Credential leakage – the payload was designed to read process.env variables and any stored npm authentication tokens, giving an attacker a foothold to publish further malicious packages.
2. Trust erosion – the @redhat-cloud-services scope is widely regarded as a reliable source. Compromise of such a high‑profile namespace can undermine confidence in the broader npm ecosystem.

Packages and versions affected

Below is a non‑exhaustive list of the most critical packages and the exact versions that contain the malicious code. All later releases (after the listed versions) have been patched.

• @redhat-cloud-services/chrome – 2.3.1, 2.3.2, 2.3.4
• @redhat-cloud-services/compliance-client – 4.0.3, 4.0.4, 4.0.6
• @redhat-cloud-services/config-manager-client – 5.0.4, 5.0.5, 5.0.7
• @redhat-cloud-services/entitlements-client – 4.0.11, 4.0.12, 4.0.14
• @redhat-cloud-services/frontend-components – 7.7.2, 7.7.3, 7.7.5
• @redhat-cloud-services/frontend-components-config – 6.11.3, 6.11.4, 6.11.6
• @redhat-cloud-services/frontend-components-notifications – 6.9.2, 6.9.3, 6.9.5
• @redhat-cloud-services/insights-client – 4.0.4, 4.0.5, 4.0.7
• @redhat-cloud-services/rbac-client – 9.0.3, 9.0.4, 9.0.6
• @redhat-cloud-services/vulnerabilities-client – 2.1.9, 2.1.11

(For the full list, see the issue description or the Step Security feed at https://app.stepsecurity.io/oss-security-feed?q=@redhat-cloud-services.)

Immediate remediation steps

1. Audit your lockfiles – Search package-lock.json or yarn.lock for any of the compromised versions. If found, pin the dependency to a safe version (the next patch release after the affected range).
2. Regenerate credentials – Any npm tokens that might have been exposed should be revoked and replaced. Rotate any environment variables that were present in the affected runtime.
3. Run a security scan – Tools like npm audit, snyk, or stepsecurity can help detect lingering malicious code in your node_modules directory.
4. Monitor for updates – Red Hat has published patched versions for all affected packages. Subscribe to the official Red Hat security advisories or watch the GitHub repository for future notices.

How the attack was inserted

The malicious payload appears to have been introduced through a compromised CI account that had publishing rights to the @redhat-cloud-services scope. The attacker added a post‑install script that executed a tiny HTTP request to a domain controlled by the threat actor. Because the script was tiny and obfuscated, it escaped basic linting checks and static analysis tools.

This incident underscores the importance of least‑privilege CI credentials and the need for signed package verification. While npm does not yet enforce mandatory signatures, projects can adopt tools like npm package‑signing or use a private registry that validates package integrity before allowing installation.

Looking ahead

Red Hat has responded by revoking the compromised publishing tokens, issuing patches for all affected packages, and tightening their CI access controls. The community is encouraged to report any suspicious behavior and to contribute to hardening the supply chain.

For developers who rely on these libraries, the key takeaways are to stay vigilant about version updates, to incorporate automated security checks into CI pipelines, and to consider using npm’s integrity field to verify that installed packages match the expected hash.

---

If you maintain a project that depends on any of the listed packages, treat this as a high‑severity issue and apply the remediation steps without delay.