BotnetPublished 1 Jun 2026

@redhat-cloud-services npm scope backdoored with valid signed SLSA provenance; recovered the GitHub commit-search dead-drop C2 markers

Source Reddit BlueTeam

Discussion

On June 1, 2026, multiple npm packages within the @redhat-cloud-services scope were republished with a malicious install-time payload that re-armed repeatedly despite registry purges. The attacker exploited GitHub Actions workflows to produce valid signed SLSA provenance and npm audit signatures, bypassing typical trust mechanisms. The malware uses a GitHub commit-search based command-and-control (C2) dead-drop, avoiding hardcoded hosts. It activates only in CI environments and quickly attempts to steal credentials such as AWS, SSH, Git, and Docker config files. Detection is possible by monitoring package integrity and behavioral checks at publish time. No official patch or remediation guidance is provided in the source data.

r/blueteamsec (opens in a new tab)u/quantumsicarius0 points0 comments

On 1 Jun 2026, 31 packages across the redhat-cloud-services npm scope were republished with an install-time malware payload, and it kept re-arming: at least 4 bursts in one afternoon as the registry purged each batch, version numbers climbing each time. What makes it notable for defenders:

Valid, signed provenance

Every malicious version carries valid SLSA provenance and passes npm audit signatures. npm trusted publishing authorizes on (repository + workflow file path), so the attacker pushed a throwaway branch carrying a workflow named release.yml set to run on any push with id-token: write. GitHub Actions ran it in the repo's context, npm minted a real publish token AND a real attestation, then the branch was deleted. main was never touched. The scope publishes from more than one RedHatInsights repo (clients from javascript-clients, the MCP servers from platform-frontend-ai-toolkit), so more than one CI pipeline was abused. Provenance proves where a build came from, not what it does.

IOCs (from a sandbox detonation)

C2 is a GitHub commit-search dead-drop, no hardcoded host. The implant queries api.github.com/search/commits for marker strings to locate its drop point: - thebeautifulmarchoftime - IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner - User-Agent: python-requests/2.31.0

Searchable in GitHub commit search / audit logs, and the drop-point commits can be purged. (Not in the public writeups yet; contributed to the issue below.)

Behavior: - Env-gated: only fires when CI / GITHUB_ACTIONS are set (dormant in a bare sandbox), which is why a lot of dynamic analysis misses it. - Credential reads within ms of install: ~/.aws/credentials, ~/.ssh/id_rsa, ~/.git-credentials, ~/.docker/config.json. - All egress DNS-resolved, no hardcoded-IP C2, no cloud metadata probe in our run.

Detection

Pin to integrity (lockfile) and expect re-arming: latest was malicious far more often than not across the afternoon.
A kernel agent that returns -EPERM on credential-file reads kills the job before the C2 fires.
Behavioral checks at publish time catch this regardless of how clean the provenance looks.

Sources

StepSecurity, original report + writeup: https://github.com/RedHatInsights/platform-frontend-ai-toolkit/issues/57 and https://www.stepsecurity.io/blog/multiple-redhat-cloud-services-npm-packages-compromised
SafeDep, the OIDC/SLSA provenance-abuse technique (AntV wave): https://safedep.io/mini-shai-hulud-strikes-again-314-npm-packages-compromised/
Recovered C2 markers contributed to the RedHatInsights issue: https://github.com/RedHatInsights/platform-frontend-ai-toolkit/issues/57#issuecomment-4594221102
Full first-hand method (detonation, provenance anatomy, checksums): https://leitwacht.eu/blog/valid-provenance-malicious-package

Disclosure: I founded Leitwacht; the agent referenced is our open-source CE binary.

Links cited in the discussion

Impact

The impact includes potential credential theft from compromised CI environments, enabling attackers to access AWS, SSH, Git, and Docker credentials. The use of valid signed provenance and npm audit signatures undermines trust in package authenticity, complicating detection and response. The malware’s ability to re-arm after purges increases persistence risk. However, the attack is limited to environments where the malicious packages are installed and CI environment variables are present. There is no evidence of widespread exploitation beyond the republished packages. No known exploits in the wild have been reported.

Defensive guidance

Defenders should pin dependencies using lockfiles to prevent automatic upgrades to malicious versions and monitor for repeated re-arming behavior. Behavioral checks at publish time can detect malicious packages despite valid provenance. Employ kernel-level protections that block unauthorized credential file reads to prevent the malware from exfiltrating sensitive data. Purge malicious commits used as C2 dead-drops from GitHub commit search to disrupt attacker communication. Since the attack leverages CI environment variables, restrict and monitor CI workflows and tokens to reduce risk.

Summary

This threat involves a supply chain compromise where 31 npm packages under the @redhat-cloud-services scope were maliciously republished with install-time malware payloads. The attacker abused GitHub Actions workflows by pushing throwaway branches with release workflows that generated valid SLSA provenance and npm publish tokens, allowing the malicious packages to appear legitimate and pass npm audit signatures. The malware uses a novel C2 mechanism via GitHub commit search dead-drop markers, avoiding static IPs or hardcoded hosts. It activates only in CI environments and rapidly attempts to exfiltrate sensitive credentials from the host environment. Detection strategies include pinning package integrity via lockfiles and behavioral analysis at publish time. Multiple RedHatInsights repositories and CI pipelines were abused, but the main branches were not directly modified.

References

Community reviews

Loading reviews…