Context

Recently, the MistEye security monitoring system detected intelligence regarding anomalous versions of multiple npm packages under the Red Hat Cloud Services organization. This incident involved 32 npm packages and 96 versions within the organization. This article conducts an in-depth offline analysis of three local samples: these packages are not impersonated namespaces or typosquatting packages, but legitimate packages using the @redhat-cloud-services scope; analysis of the sample source code confirms that their tarballs contain a multi-layered obfuscated malicious loader designed to automatically trigger during installation.

After full reconstruction, it can be confirmed that the core payload of these three samples possesses source code capabilities including: memory extraction from GitHub Actions Runner, collection of credentials from multiple clouds and local environments, exfiltration and dead-drop via GitHub API, injection into GitHub workflows, self-propagation via npm, persistence via Claude Code / VS Code / systemd / LaunchAgent, evasion of Harden-Runner / StepSecurity defenses, and detection of EDR and security products. In terms of capability scope, potential targets include developer workstations, CI/CD runners, build containers, GitHub repositories, GitHub Actions workflows, npm publishing pipelines, and cloud environment credentials; the actual impact scope must be further confirmed by analyzing installation logs, repository audits, and platform telemetry.

Based on its code structure, propagation pathways, and capability composition, this malware is a variant of the Shai-Hulud malware.

MistEye response

MistEye is a proprietary Web3 threat intelligence and dynamic security monitoring system developed by SlowMist, integrating security monitoring and intelligence aggregation to provide users with real-time risk alerts and asset protection.

After capturing the recent Red Hat Cloud Services npm package supply chain poisoning incident and its associated malicious samples, the MistEye system triggered a high-risk alert and conducted a systematic analysis of the attack chain’s obfuscation structure, payload decryption, capability reconstruction, and IOCs.

(https://enterprise.misteye.io/threat-intelligence/SM-2026-378450)

Attack Chain Overview

The technical analysis in this article is based solely on local offline static analysis, involving unpacking, decoding, and deobfuscation verification of three npm tgz samples.

The samples covered in this verification are as follows:

@redhat-cloud-services/frontend-components-config

Version: 6.11.3

tgz SHA-256: 0c9c67ec40d5f23efa1ec3470d0ac88b4993ccc0e92be913fc29a337dfc4f060

@redhat-cloud-services/types

Version: 3.6.1

tgz SHA-256: d543bb3cdf1569c2b3d38c8a4081ed746cfe78bf3236c2302704d79ab7fa9558

@redhat-cloud-services/rule-components

Version: 4.7.2

tgz SHA-256: aaf00d06baa3c679b82452c50014e9824b8874e9ca2d150f19095f8de19ba90f

The attack entry point is identical across all three samples: each package.json contains scripts.preinstall = "node index.js". This means that whenever the developer's host or CI/CD environment installs these versions, the root directory's index.js will be automatically executed during the installation phase, without requiring the user to explicitly import or run any business code.

Three samples share the same core malicious payload but differ in their outer packaging parameters. Specifically, the three samples use different ROT/Caesar shift values and AES-GCM keys/IVs/tags, making it difficult to directly reuse static signatures based on outer packaging hashes, fixed keys, or fixed shifts across samples. However, the decrypted Bun runtime bootloader and the core malicious payload have identical hashes: one is a startup auxiliary module used to prepare the Bun runtime environment, and the other is the actual core payload containing malicious functionality. This paper refers to them respectively as the "Bun Runtime Bootloader" (source code variable name _b) and the "Core Malicious Payload" (source code variable name _p).

The restored attack chain is as follows:

Technical Analysis

All three samples trigger the attack chain via the preinstall lifecycle hook in package.json:

"scripts": {

"preinstall": "node index.js"

}

preinstall runs automatically during the npm installation phase. For ordinary frontend components, type definitions, or rule-based package bundles, there is typically no need to execute a large JavaScript file in the root directory during installation; this is the most direct red flag.

The sample-level evidence is as follows:

@redhat-cloud-services/frontend-components-config@6.11.3

• main: lib/index.js
• files field: ["/lib", "/bin"]
• Root directory index.js SHA-256: 545a1838c66e1771f58d84a17b3e1841e5eeab91a73f4ccc59c9492450a6d9c0

@redhat-cloud-services/types@3.6.1

• main: index.d.ts
• files field: not set
• Root directory index.js SHA-256: b86c5ae9e95bd841a595440faa3eb6317441e746f241ae8fd641ab59ed1d1966

@redhat-cloud-services/rule-components@4.7.2

• main: index.js
• files field: not set
• Root directory index.js SHA-256: 1a30a9abe20bab121aaa75ed040565af14e6cdfb745609ee0e7b94a2d814fb9c

Among these, the files field in frontend-components-config@6.11.3 declares only "/lib" and "/bin", yet an additional index.js exists in the tarball's root directory and is invoked by preinstall. This anomaly applies only to this sample; types@3.6.1 and rule-components@4.7.2 do not set the files field, so this anomaly should not be generalized to all samples.

The root index.js files for all three samples are large, single-line JavaScript files with identical structures, consisting primarily of a try { eval(...) } catch (...) wrapper:

The wrapper first reconstructs the large array of numbers into a string using String.fromCharCode, then applies a ROT/Caesar shift to the alphabetic characters in the string, and finally passes the decoded result to eval for execution. Error handling only outputs the "wrapper:" prefix, minimizing conspicuous error exposure during installation failures.

The outer displacement values and Stage 2 hash for the three samples are as follows:

frontend-components-config@6.11.3

index.js size: 4,294,798 bytes

ROT/Caesar shift: 10

Stage 2 SHA-256: b19c2fd48535c8c40aeb3e627ce92775f33ef9292611767bb1236c238e6f90cc

types@3.6.1

index.js size: 4,135,588 bytes

ROT/Caesar shift: 4

Stage 2 SHA-256: 9c0425aa6e6d7792ac38d24f3e7245f42fcaa553ddfeb6bd97677017f10c3b75

rule-components@4.7.2

index.js size: 4,294,336 bytes

ROT/Caesar shift: 11

Stage 2 SHA-256: d590bd375d95e4ac072b7ebc1fc4489bcaf5f20a939e92486267aa398bcf1e5d

The Stage 2 code, after ROT/Caesar decoding, performs AES-128-GCM (Advanced Encryption Standard - Galois/Counter Mode) decryption using Node.js crypto.createDecipheriv, with the authentication tag set via setAuthTag. The decryption targets two subsequent components: the Bun runtime bootstrap and the core malicious payload.

Among these, the Bun runtime launcher is responsible for detecting, locating, or preparing the Bun runtime environment to enable subsequent code to execute via Bun; the core malicious payload constitutes the main component of the attack chain, containing primary malicious capabilities such as credential harvesting, GitHub/npm propagation, persistence, defense evasion, and decryption of embedded resources.

Each of the three samples used different AES-128-GCM keys, initialization vectors, and authentication tags to encrypt the two components, but after decryption, the SHA-256 hashes of all three Bun runtime bootstrappers were ac2a2208e1726e008be6c73dc0872d9bba163319259dff1b62055ac933ca46b6, and the SHA-256 hashes of all three core malicious payloads were 0dc06ecdaa63fe24859cfd955053c23245c536e4733480239d14bebf12688e35. This indicates that the attackers changed the outer packaging parameters across different npm packages but reused the same core malicious components.

After decryption, Stage 2 writes the core malicious payload to /tmp, executes it via Bun, and then deletes the temporary file. The actual logic reconstructed from the three samples is as follows:

Therefore, the verifiable temporary file patterns in the three samples are:

/tmp/p.js

The Bun runtime bootloader is 898 bytes in size, and the three sample hashes are identical:

ac2a2208e1726e008be6c73dc0872d9bba163319259dff1b62055ac933ca46b6

The Bun runtime bootstrap includes logic such as child_process.execSync, fs.existsSync, fs.mkdtempSync, fs.chmodSync, os.platform(), os.arch(), and getBunPath() to locate or prepare the Bun runtime environment. In other words, Stage 2 does not simply assume that Bun is installed globally; outside the Bun runtime path, it first loads the Bun runtime bootstrap and then invokes Bun via getBunPath() to execute the core malicious payload.

The decrypted core payload is not readable plaintext JavaScript but is further obfuscated using an obfuscator.io-style string table obfuscation. This layer consolidates numerous strings into an array and reconstructs them at runtime using indexing and rotation logic, preventing analysts from directly identifying critical APIs, paths, and configuration names until the string table has been fully reconstructed.

After reconstructing the obfuscator.io string table, an additional layer of B5 custom string encryption remains within the core malicious payload. The following parameters have been confirmed:

• KDF: PBKDF2 (Password-Based Key Derivation Function 2)
• Hash function: SHA-256
• Number of iterations: 200,000
• Key length: 32 bytes
• Number of decryption rounds: 3
• password: ba2c6ddb3672bdd6a611e6850b4f700b52aed3dab2f1b3d5f8c839d4a157a709
• salt: 5b26508dc0f1075a7c0b4d8aa464487e

The decrypted result is as follows:

Among them, B5 decryption reveals multiple types of critical plaintext strings. Note that some strings originally resided in the obfuscator.io string table and are only directly grepable after both "string table replacement" and "B5 decryption" have been completed:

The core malicious payload also contains embedded resources encrypted with AES-256-GCM and compressed with gzip. The decompression logic uses:

The resolved key embedded resources are categorized into three types by function:

Cross-platform memory reading:

These resources are used to read the memory of running processes. While keys and tokens in ordinary files can be discovered by inspecting the files, CI/CD runners or development tools temporarily store sensitive values in memory during execution. Attackers have embedded memory reading scripts for Linux, Windows, and macOS platforms with the goal of capturing these transient secrets from process memory across different systems.

Persistent Configuration:

These resources are used to "leave backdoor triggers." That is, even after the initial npm installation is complete, attackers still want the malicious code to execute again when developers subsequently open the project, launch their editor, enter a Claude Code session, or log back into the system. Therefore, these resources target both project-level configurations and user-level auto-start mechanisms: project-level configurations are more隐蔽 (hidden), while system-level services are better suited for long-term persistence.

C2 and propagation:

These embedded resources are used for subsequent control links and secret exfiltration. After decryption, YZ is a GitHub commit search monitor that periodically searches for commit messages in the format firedalazer ., verifies the signature, then downloads and executes remote Python content; zZ, after decryption, is a GitHub Actions workflow template named "Run Copilot" that writes ${{ toJSON(secrets) }} to format-results.txt and uploads it as an artifact. The former provides the chain for acquiring and executing subsequent tasks, while the latter provides a template for exfiltrating repository secrets via GitHub Actions artifacts; the actual workflow injection, execution waiting, and artifact download are handled by accompanying GitHub API logic within the main payload.

Core malicious payload capability analysis

After completing multi-layer deobfuscation, the sample ultimately releases and executes its core malicious payload. All subsequent analysis focuses on the core malicious payload module, broken down into five stages: data collection, exfiltration, propagation, persistence, and evasion.

The sample includes memory reading scripts for Linux, Windows, and macOS, enabling cross-platform dump capabilities. On Linux, memory extraction is achieved by reading the target process’s /proc//maps and /proc//mem files:

The active trigger logic for the core malicious payload targets GitHub Actions Linux runners: when GITHUB_ACTIONS === "true" and RUNNER_OS === "Linux", the code locates the Runner.Worker process, dumps its memory, and extracts masked secrets in the format "":{"value":"","isSecret":true}. While the confirmed active collection paths in all three samples focus on Linux runners, scripts for all three platforms have been embedded.

The core malicious payload includes a systematic credential harvesting module that targets cloud providers, CI environments, developer local configurations, GitHub CLI, password managers, and wallet files.

The cloud provider credential collection targets are as follows:

The AWS module also includes logic related to ECS, IMDS (Instance Metadata Service), and STS WebIdentity.

Developer local credential collection covers the following targets:

The password manager logic is implemented in the source code as an array of runCommand(command, args), rather than through shell string concatenation.

The credential collection module covers a wide range of targets from cloud platforms to developers' local environments; the collected sensitive data is exfiltrated through the following mechanisms.

The core malicious payload uses the GitHub API as its primary data exfiltration channel. It disguises its User-Agent as python-requests/2.31.0 and, after validating the token’s x-oauth-scopes (which must include repo, public_repo, or workflow), performs exfiltration by creating a repository (with a fixed description: Miasma: The Spreading Blight) and writing the stolen data, base64-encoded, via PUT /repos///contents/results/.

Additionally, the payload implements a dead-drop mechanism based on GitHub commit searches, retrieving C2 instructions by searching for the marker "thebeautifulmarchoftime" (or "thebeautifulsnadsoftime"):

let result = await X9("thebeautifulmarchoftime ", xZ);

The embedded resource YZ.bin is an independent GitHub commit monitor that polls every 3600 seconds for commit messages in the format firedalazer . After successful signature verification, it downloads and executes remote Python content. This constitutes a separate command-and-control channel independent of the primary exfiltration channel.

The source code also includes an HTTP POST sender configuration targeting the endpoints api.anthropic.com and v1/api. The noop field in this configuration is set to true, meaning that without external modification, this sender will not initiate actual network requests. Therefore, static analysis can only confirm the existence of this code structure, but cannot prove active data exfiltration to the Anthropic API.

The core malicious payload can manipulate git objects in repositories via GitHub's REST/GraphQL API:

A malicious workflow, disguised as a release, requests the id-token: write permission and uses the OIDC (OpenID Connect) pathway to obtain an npm publishing token. The environment variables and endpoint for the OIDC pathway are ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL, with the audience set to npm:registry.npmjs.org. At the source code level, the payload is confirmed to have the capability to inject workflows into GitHub repositories and leverage OIDC/npm trusted publishing to gain publishing permissions.

In addition to the aforementioned method of injecting the workflow via git refs, the payload also includes a more covert secrets exfiltration mechanism: a disguised GitHub Actions workflow impersonating Run Copilot writes ${{ toJSON(secrets) }} to format-results.txt and uploads it as an artifact. Compared to directly writing secrets into repository content, this approach focuses on exfiltrating data through workflow artifacts, making it less likely for conventional code diff reviews to directly detect the exported secrets.

The embedded resource zZ.bin is a GitHub Actions workflow disguised as Copilot, which writes ${{ toJSON(secrets) }} to format-results.txt and uploads it as an artifact.

The accompanying GitHub API behavior includes: creating/updating a temporary branch → writing the workflow blob → waiting for the workflow run → downloading the artifact ZIP → reading format-results.txt → deleting the workflow run and temporary branch. Relevant hunting keywords include: Run Copilot, VARIABLE_STORE, format-results, chore/add-codeql-static-analysis, .github/workflows/codeql.yml.

The core malicious payload has two independent npm publishing/distribution pathways.

npm token path: The payload enumerates the current user's npm tokens via GET /-/npm/v1/tokens, filters for tokens with bypass_2fa === true and package write permissions, and uses these tokens to enable automated publishing. bypass_2fa is a token metadata field, not a publish body parameter.

GitHub Actions OIDC path: Read the ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL environment variables, request an OIDC token with audience npm:registry.npmjs.org, and exchange it for publishing permissions via the npm OIDC token exchange endpoint.

The process for contaminating a target tarball is: unpack → write malicious index.js → modify package.json:

Here, two types of entry points are distinguished: For the three local uploaded samples themselves, use preinstall: "node index.js"—in this case, the installation environment does not require Bun to be preinstalled, making Node.js a more discreet initial entry point. When propagating and contaminating other packages, write preinstall: "bun run index.js" and add a bun dependency—because the subsequent logic of the core payload relies on APIs provided by the Bun runtime (such as Bun.gunzipSync and Bun.file), and in propagation scenarios, it is essential to ensure that the target environment has Bun installed.

The core malicious payload includes four persistence methods, covering both the project directory and system-level auto-start.

Claude Code SessionStart hook: Embed the resource S8.bin to write the SessionStart hook into .claude/settings.json, automatically executing node .claude/setup.mjs each time a Claude Code session starts. The malicious payload is also written to both .claude/setup.mjs and .claude/index.js (the path is constructed as ".claude/" + M0, where M0 = "index.js").

VS Code folderOpen task: Embed the resource EZ.bin to write the folderOpen task into .vscode/tasks.json, automatically executing the same script when opening the compromised project folder. Also write to .vscode/setup.mjs.

kitty-monitor (systemd / LaunchAgent): Embeds the resource RZ.bin to install a persistent service, with files distributed across /.local/share/kitty/cat.py, /.config/systemd/user/kitty-monitor.service (Linux), and ~/Library/LaunchAgents/com.user.kitty-monitor.plist (macOS). The malicious payload creates the /tmp/kitty- directory, writes YZ.bin (GitHub commit monitor) to cat.py, and installs it via RZ.bin.

gh-token-monitor (systemd / LaunchAgent): Embeds the resource jZ.bin to install the GitHub token monitoring service, with files distributed across the directories /.local/bin/gh-token-monitor.sh and /.config/gh-token-monitor/, along with the corresponding systemd / LaunchAgent paths. The monitor checks whether the GitHub token returns a 40x status code and whether the metadata of the npm package @cap-js/openapi@1.4.1 is abnormal; upon detection, it triggers the handler:

This means that when the monitor detects a 40x status code returned by the GitHub API—such as when a token is revoked, expired, or has abnormal permissions—the malicious script executes the provided handler. The handler recovered from the three samples in this article is: rm -rf ~/; rm -rf ~/Documents. When responding, do not revoke the token directly on a host that may still be running the payload—first isolate the host, remove persistence mechanisms and running processes, then rotate credentials from a clean environment.

The core malicious payload contains built-in detection and destruction logic targeting StepSecurity Harden-Runner, bypassing CI/CD protections through the following steps:

1. Check if the Docker socket /var/run/docker.sock is available;
2. List Docker containers matching the keywords "harden-runner" or "stepsecurity" in the name or image;
3. Terminate the matching container via POST /containers//kill;
4. Create a privileged Alpine container and modify the sudoers file to runner ALL=(ALL) NOPASSWD:ALL;
5. Write invalid DNS entries for StepSecurity-related domains to /etc/hosts;
6. Override /etc/resolv.conf with 8.8.8.8 and 1.1.1.1.

This adversarial logic indicates that the sample has been specifically adapted for CI/CD environments protected by StepSecurity.

The core malicious payload detects process names and installation paths of multiple EDR (Endpoint Detection and Response) / security products:

The payload also includes region avoidance logic: detect the LC_ALL, LC_MESSAGES, LANGUAGE, and LANG environment variables; if, after converting to lowercase, they start with "ru", skip execution. CI environment detection supports GitHub Actions, GitLab CI, Travis CI, CircleCI, Jenkins, AWS CodeBuild, Buildkite, AppVeyor, Bitbucket, Drone, TeamCity, and Cirrus CI. Runtime state flags include tmp.0987654321.lock, __IS_DAEMON (marks a detached daemon subprocess), SKIP_DOMAIN (skips the domain sender path), /tmp/kitty-*, cat.py, and /var/tmp/.gh_update_state.

Impact analysis

From a source code perspective, the impact of these three samples extends beyond a one-time execution during the npm installation phase. Their actual risks can be divided into four layers:

At the developer host level, the sample collects environment variables, .npmrc, .pypirc, SSH keys, Docker configurations, .env files, GitHub CLI tokens, password manager data, and wallet files, and maintains subsequent trigger capabilities via Claude Code, VS Code, systemd user service, or macOS LaunchAgent.

At the CI/CD Runner level, the sample identifies GitHub Actions Linux runners, reads the memory of the Runner.Worker process to extract masked secrets, and incorporates countermeasures against StepSecurity Harden-Runner, attempting to disrupt or bypass CI/CD protection components.

At the GitHub organization and repository level. The sample can use the GitHub API to create repositories, write to contents/results/, manipulate git refs/blobs/trees/commits, inject malicious workflows, and exfiltrate secrets via Run Copilot workflow + artifact.

On the npm ecosystem propagation level: Samples can be selected using npm tokens with package write permissions and bypass_2fa === true, or by leveraging the GitHub Actions OIDC / npm trusted publishing pathway to obtain publishing rights. Subsequently, download the target tarball, inject a malicious loader, modify the preinstall script, add a Bun dependency, increment the patch version, and publish—thereby establishing an self-propagating chain within npm.

Summary

Source code evidence from three samples shows that this malicious package is not a simple credential-stealing script during installation, but rather a multi-stage loader combined with a full implant: the outer layer is randomized per package, while the Bun runtime bootloader and core malicious payload remain consistent; the main implant encompasses credential harvesting, CI secret extraction, GitHub/npm propagation, persistence, and anti-detection measures.

Highly concealed entry point design. Attackers do not embed malicious logic within the business code, but instead attach an obfuscated loader to npm lifecycle scripts. This loader primarily handles decrypting and executing the embedded payload, making it difficult to detect the true capabilities through source code review alone.

A multi-layered deobfuscation chain. The malicious payload is wrapped in five layers: a numeric array + ROT letter substitution, AES-128-GCM encryption, obfuscator.io obfuscation, B5 proprietary string encryption, and an embedded layer of AES-256-GCM with gzip. The keys or parameters for each layer can vary independently across different packages, making bulk detection based on static signatures significantly more difficult.

Comprehensive organizational-level attack capabilities. This implant possesses the ability to read memory from GitHub Actions Runners, collect credentials across multiple clouds and on-premises environments, exfiltrate data via GitHub API and dead-drop mechanisms, infect GitHub repositories and workflows, self-propagate via npm, maintain persistence, and evade defenses. Based on its source code structure, it is equipped with pathways to trigger further propagation from a single point of installation to repositories, CI/CD pipelines, and npm publishing chains. The actual scope of propagation must be confirmed by analyzing installation logs, repository audits, and platform telemetry.

The source code evidence confirms that all three samples automatically trigger via preinstall and decrypt and execute the same main implant. However, the initial access method in the actual incident cannot be proven solely based on these three tgz samples.

Recommended action

1. Identify and remove malicious versions from project dependencies, lockfiles, private registry caches, and build caches.
2. Check the installation logs for the presence of preinstall, node index.js, bun run, /tmp/p*.js, or tmp.0987654321.lock.
3. Do not directly revoke tokens on a compromised host that may still be executing payloads. Instead, isolate the compromised host first, then clean running processes and persistence mechanisms, and rotate tokens related to GitHub, npm, cloud credentials, Kubernetes, Vault, SSH, Docker registry, and password managers from a clean environment.
4. Check the GitHub repository for recent branches, commits, workflows, artifacts, and newly created repositories, with a focus on keywords such as Run Copilot, format-results, chore/add-codeql-static-analysis, .github/workflows/codeql.yml, and OIDC_PACKAGES.
5. Check if the project directory has been newly added or modified: .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, .vscode/setup.mjs.
6. Check user-level persistence: /.local/share/kitty/cat.py, /.config/systemd/user/kitty-monitor.service, ~/Library/LaunchAgents/com.user.kitty-monitor.plist, gh-token-monitor-related files.
7. Review the npm publish history to confirm whether any unauthorized patch versions were published; additionally, audit npm token metadata with emphasis on tokens that can bypass two-factor authentication (2FA) and have package write permissions.
8. Conduct an integrity audit of downstream products built in a contaminated environment.

IOC

Malicious file

filename: redhat-cloud-services-frontend-components-config-6.11.3.tgz MD5: 633ad8849a59e2bfb7a0fe589e816a07 SHA1: 675294612f455fe6a9acb195f0cbe3687d8e2e34 SHA256: 0c9c67ec40d5f23efa1ec3470d0ac88b4993ccc0e92be913fc29a337dfc4f060

filename: redhat-cloud-services-types-3.6.1.tgz MD5: 9e6c5af01438b52c9a411686c1f1b8ff SHA1: 88d098c8d96e9ae17550e9798c3b62c420464b8c SHA256: d543bb3cdf1569c2b3d38c8a4081ed746cfe78bf3236c2302704d79ab7fa9558

filename: redhat-cloud-services-rule-components-4.7.2.tgz MD5: f1ffdbf5e639899f26a6ebab2eec408d SHA1: f3c5c21274045ae02fef11e931de6dcf8462a067 SHA256: aaf00d06baa3c679b82452c50014e9824b8874e9ca2d150f19095f8de19ba90f

SHA256

ac2a2208e1726e008be6c73dc0872d9bba163319259dff1b62055ac933ca46b6

0dc06ecdaa63fe24859cfd955053c23245c536e4733480239d14bebf12688e35

Malicious dependency

npm:@redhat-cloud-services/topological-inventory-client@3.0.10

npm:@redhat-cloud-services/topological-inventory-client@3.0.11

npm:@redhat-cloud-services/topological-inventory-client@3.0.13

npm:@redhat-cloud-services/compliance-client@4.0.3

npm:@redhat-cloud-services/compliance-client@4.0.4

npm:@redhat-cloud-services/compliance-client@4.0.6

npm:@redhat-cloud-services/rbac-client@9.0.3

npm:@redhat-cloud-services/rbac-client@9.0.4

npm:@redhat-cloud-services/rbac-client@9.0.6

npm:@redhat-cloud-services/insights-client@4.0.4

npm:@redhat-cloud-services/insights-client@4.0.5

npm:@redhat-cloud-services/insights-client@4.0.7

npm:@redhat-cloud-services/frontend-components@7.7.2

npm:@redhat-cloud-services/frontend-components@7.7.3

npm:@redhat-cloud-services/frontend-components@7.7.5

npm:@redhat-cloud-services/frontend-components-utilities@7.4.1

npm:@redhat-cloud-services/frontend-components-utilities@7.4.2

npm:@redhat-cloud-services/frontend-components-utilities@7.4.4

npm:@redhat-cloud-services/remediations-client@4.0.4

npm:@redhat-cloud-services/remediations-client@4.0.5

npm:@redhat-cloud-services/remediations-client@4.0.7

npm:@redhat-cloud-services/frontend-components-notifications@6.9.2

npm:@redhat-cloud-services/frontend-components-notifications@6.9.3

npm:@redhat-cloud-services/frontend-components-notifications@6.9.5

npm:@redhat-cloud-services/patch-client@4.0.4

npm:@redhat-cloud-services/patch-client@4.0.5

npm:@redhat-cloud-services/patch-client@4.0.7

npm:@redhat-cloud-services/host-inventory-client@5.0.3

npm:@redhat-cloud-services/host-inventory-client@5.0.4

npm:@redhat-cloud-services/host-inventory-client@5.0.6

npm:@redhat-cloud-services/rule-components@4.7.2

npm:@redhat-cloud-services/rule-components@4.7.3

npm:@redhat-cloud-services/rule-components@4.7.5

npm:@redhat-cloud-services/frontend-components-advisor-components@3.8.2

npm:@redhat-cloud-services/frontend-components-advisor-components@3.8.4

npm:@redhat-cloud-services/frontend-components-advisor-components@3.8.6

npm:@redhat-cloud-services/notifications-client@6.1.4

npm:@redhat-cloud-services/notifications-client@6.1.5

npm:@redhat-cloud-services/notifications-client@6.1.7

npm:@redhat-cloud-services/sources-client@3.0.10

npm:@redhat-cloud-services/sources-client@3.0.11

npm:@redhat-cloud-services/sources-client@3.0.13

npm:@redhat-cloud-services/integrations-client@6.0.4

npm:@redhat-cloud-services/integrations-client@6.0.5

npm:@redhat-cloud-services/integrations-client@6.0.7

npm:@redhat-cloud-services/frontend-components-config@6.11.3

npm:@redhat-cloud-services/frontend-components-config@6.11.4

npm:@redhat-cloud-services/frontend-components-config@6.11.6

npm:@redhat-cloud-services/frontend-components-config-utilities@4.11.2

npm:@redhat-cloud-services/frontend-components-config-utilities@4.11.3

npm:@redhat-cloud-services/frontend-components-config-utilities@4.11.5

npm:@redhat-cloud-services/hcc-pf-mcp@0.6.1

npm:@redhat-cloud-services/hcc-pf-mcp@0.6.2

npm:@redhat-cloud-services/hcc-pf-mcp@0.6.4

npm:@redhat-cloud-services/frontend-components-remediations@4.9.2

npm:@redhat-cloud-services/frontend-components-remediations@4.9.3

npm:@redhat-cloud-services/frontend-components-remediations@4.9.5

npm:@redhat-cloud-services/eslint-config-redhat-cloud-services@3.2.1

npm:@redhat-cloud-services/eslint-config-redhat-cloud-services@3.2.2

npm:@redhat-cloud-services/eslint-config-redhat-cloud-services@3.2.4

npm:@redhat-cloud-services/javascript-clients-shared@2.0.8

npm:@redhat-cloud-services/javascript-clients-shared@2.0.9

npm:@redhat-cloud-services/javascript-clients-shared@2.0.11

npm:@redhat-cloud-services/quickstarts-client@4.0.11

npm:@redhat-cloud-services/quickstarts-client@4.0.12

npm:@redhat-cloud-services/quickstarts-client@4.0.14

npm:@redhat-cloud-services/config-manager-client@5.0.4

npm:@redhat-cloud-services/config-manager-client@5.0.5

npm:@redhat-cloud-services/config-manager-client@5.0.7

npm:@redhat-cloud-services/hcc-feo-mcp@0.3.1

npm:@redhat-cloud-services/hcc-feo-mcp@0.3.2

npm:@redhat-cloud-services/hcc-feo-mcp@0.3.4

npm:@redhat-cloud-services/entitlements-client@4.0.11

npm:@redhat-cloud-services/entitlements-client@4.0.12

npm:@redhat-cloud-services/entitlements-client@4.0.14

npm:@redhat-cloud-services/tsc-transform-imports@1.2.2

npm:@redhat-cloud-services/tsc-transform-imports@1.2.4

npm:@redhat-cloud-services/tsc-transform-imports@1.2.6

npm:@redhat-cloud-services/hcc-kessel-mcp@0.3.1

npm:@redhat-cloud-services/hcc-kessel-mcp@0.3.2

npm:@redhat-cloud-services/hcc-kessel-mcp@0.3.4

npm:@redhat-cloud-services/frontend-components-testing@1.2.1

npm:@redhat-cloud-services/frontend-components-testing@1.2.2

npm:@redhat-cloud-services/frontend-components-testing@1.2.4

npm:@redhat-cloud-services/types@3.6.1

npm:@redhat-cloud-services/types@3.6.2

npm:@redhat-cloud-services/types@3.6.4

npm:@redhat-cloud-services/chrome@2.3.1

npm:@redhat-cloud-services/chrome@2.3.2

npm:@redhat-cloud-services/chrome@2.3.4

npm:@redhat-cloud-services/frontend-components-translations@4.4.1

npm:@redhat-cloud-services/frontend-components-translations@4.4.2

npm:@redhat-cloud-services/frontend-components-translations@4.4.4

npm:@redhat-cloud-services/vulnerabilities-client@2.1.8

npm:@redhat-cloud-services/vulnerabilities-client@2.1.9

npm:@redhat-cloud-services/vulnerabilities-client@2.1.11