A recent analysis by SlowMist has uncovered a supply chain poisoning incident involving 32 npm packages and 96 versions published under the Red Hat Cloud Services organization. This incident is characterized by the presence of malicious code embedded within legitimate package versions, which poses serious risks to developers and CI/CD environments.
What Happened
The investigation revealed that the malicious packages contained a multi-layer obfuscated loader that activates during the installation phase. This loader is capable of executing various harmful actions, including credential harvesting and GitHub API exfiltration. The core payloads of the malicious samples were confirmed to have functionalities such as memory reading from GitHub Actions Runners and the ability to propagate through npm.
The preinstall script is what makes this pattern dangerous in automated builds. Code placed there runs the moment the package is installed, before anyone reviews or executes the project itself, so a routine dependency install can give the loader the same access the build job already has. That matches the behaviour reported in the samples: reading memory from GitHub Actions Runners, harvesting credentials, and moving data out through the GitHub API, all without a developer typing a single command.
On-Chain and Web Evidence
The analysis focused on three specific npm packages: @redhat-cloud-services/frontend-components-config (version 6.11.3), @redhat-cloud-services/types (version 3.6.1), and @redhat-cloud-services/rule-components (version 4.7.2). Each package contained a package.json file with a preinstall script that executed a malicious index.js file, triggering the attack without user intervention.
The malicious payload was protected by multiple layers of obfuscation, including ROT/Caesar letter substitution and AES encryption. The core malicious components shared identical hashes across the samples, indicating a consistent attack methodology despite variations in outer-layer packaging.
Why It Matters
This incident underscores the vulnerabilities inherent in the software supply chain, particularly within the npm ecosystem. Developers and organizations relying on third-party packages must exercise caution and implement robust security measures to mitigate risks associated with dependency management.
To protect against similar threats, it is recommended that organizations conduct thorough audits of their dependencies, monitor installation logs for suspicious activity, and isolate any potentially compromised environments before rotating credentials. Additionally, reviewing GitHub repository activities for unauthorized changes is crucial.
- Audit the dependency tree and compare the package versions your builds actually resolved against the versions named in the analysis.
- Read installation logs from recent builds and look for scripts that ran before the build step itself began.
- Isolate any environment you believe was affected first, then rotate the credentials that environment held.
- Review GitHub repository activity for changes nobody on the team made.
- Treat build runners as credential stores, because the reported payload read memory from GitHub Actions Runners.
- Remember that the core components shared identical hashes across samples, so outer packaging can differ while the same payload sits underneath.
What CI/CD Teams Should Check
- Package supply-chain poisoning
- The insertion of malicious code into a software dependency or release path so downstream installations execute attacker-controlled behavior.
Readers can separately inspect a destination with TrustSniffer’s website-risk checker; that result should be evaluated independently from the incident claims summarized here.
For broader context, the TrustSniffer Risk Index separates aggregate platform coverage from conclusions about any single domain or package.
