Executive summary
Research published on 1 June 2026 by Wiz and JFrog describes malicious packages in the legitimate @redhat-cloud-services npm namespace, with code executing during installation. Wiz traces the publishing activity to a compromised employee GitHub account and reports that malicious releases carried valid provenance attestations. Red Hat's initial bulletin says it removed compromised versions and was still examining product builds, with no customer action required on its findings at that point. We assess it is likely (B2) that organisations which executed an affected installation need an identity and build-environment investigation as well as dependency replacement, because the analysed payload collects secrets, modifies publishing workflows and establishes persistence.
Context: a familiar namespace carrying unfamiliar code
The issue concerns compromised legitimate packages, rather than similarly named imitations. JFrog's analysis identifies 96 hijacked package versions and examines @redhat-cloud-services/types version 3.6.1. The package presented itself as a TypeScript declarations library while including a JavaScript installation hook. Its apparent purpose therefore gave consumers little reason to expect executable setup behaviour.
Wiz's initial investigation identified at least 32 package releases with unauthorised modifications that differed from their corresponding repositories. These are researchers' package observations, not counts of compromised organisations. Neither figure establishes how many consumers executed the malicious code or how many credentials were subsequently used.
Red Hat's initial bulletin describes frontend libraries that enter some container-image build processes. It says compromised npm versions were removed and dependency analysis was continuing to establish whether any product builds contained them. Its statement that customers needed no action was explicitly based on findings then available. That product assessment should not replace an independent investigation by an organisation that installed a listed public npm version in its own development environment.
Technical analysis
The installation is the execution boundary
JFrog found a preinstall hook invoking an obfuscated index.js. The loader reconstructs and transforms JavaScript, decrypts staged content and runs the main payload using Bun. If Bun is absent, a bootstrap component can download it. Application code does not have to import the package before the installation hook runs.
This distinction changes the investigation question. A team should establish whether a dependency was installed, where that happened, and which permissions were available to that process. Searching only the production application's imports would address a different boundary. A discarded test build or an unsuccessful application deployment can still deserve examination if the installation stage ran with valuable secrets available.
JFrog describes transient payload files and deletion after execution. The resulting process sequence can include npm, Node.js, download utilities and Bun. These are legitimate tools in many build systems, so our recommended detection is a relationship: an unexpected lifecycle script, newly introduced runtime and temporary payload execution associated with an affected package version. A standalone alert on Bun would be much less informative.
Trusted publishing can faithfully describe a compromised workflow
Wiz reports that the compromised GitHub account pushed malicious orphan commits to Red Hat repositories, bypassing code review. A small workflow requested an OpenID Connect (OIDC) identity token and ran the publishing payload. The resulting packages carried valid Supply-chain Levels for Software Artifacts (SLSA) provenance attestations.
The operational lesson is specific. Provenance can connect a release to a workflow identity without establishing that the workflow, account or requested action was authorised. We recommend examining the repository commit, workflow permissions and trigger conditions alongside the attestation. A successful provenance check is useful evidence about the path taken; it should not close a malicious-package alert when that path itself is under investigation.
Secrets extend beyond local files
JFrog's sample collects environment variables, developer credentials and tokens, and includes provider-specific collection for Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Vault and password managers. Where the executing identity has permission, the payload can query cloud secret services. It also targets secrets in continuous integration (CI) runner context and process memory.
For scoping, therefore, inventory both secrets physically present on the machine and resources accessible through its identity. A short-lived runner may hold little durable data while possessing meaningful access to repositories or cloud services. This is a recommendation derived from the reported collectors, not a claim that every installation successfully read every supported secret store.
Impact and limits of attribution
The practical exposure includes developer workstations, CI runners and publishing accounts that executed an affected package. Wiz identifies newly added cloud-identity collectors, while JFrog describes propagation through npm publishing permissions and writable GitHub repositories. The chain can therefore create investigation work beyond the first host, but the public analyses do not provide a verified downstream victim total.
Wiz says the payload resembles publicly released Mini Shai-Hulud tooling associated with TeamPCP, while explicitly allowing for copycats. We retain that limitation: shared code and tradecraft do not establish that TeamPCP operated this intrusion. JFrog's family description and the campaign name Miasma are useful technical references; neither is an independent attribution of the operator.
Our recommended exposure record should distinguish four states: a listed dependency in source control, an affected version downloaded, installation-time execution, and evidence of subsequent credential use or propagation. These states call for different follow-up. Treating them as equivalent would obscure both the affected population and the strength of the incident finding.
Indicators and detection opportunities
JFrog and Wiz identify the repository description Miasma: The Spreading Blight as a campaign marker. JFrog also documents local persistence artefacts and output paths. The following examples support hunting; the researchers' full package tables remain the authoritative starting point for version matching.
| Evidence to examine | Investigative purpose | Qualification |
|---|---|---|
| Exact package name and version in lockfiles, caches and installation logs | Establish whether a listed release reached a specific machine | A dependency declaration alone does not establish execution |
Unexpected preinstall entry and obfuscated index.js |
Identify the reported delivery pattern | Compare with a verified clean package and approved lifecycle behaviour |
Public repository description Miasma: The Spreading Blight and files under results/ |
Investigate the reported GitHub exfiltration mechanism | Record owner, creation time and related token activity |
kitty-monitor.service, com.user.kitty-monitor.plist, or gh-token-monitor artefacts |
Examine persistence described by JFrog | Preserve contents and execution evidence before removal |
Developer-tool settings and .vscode/tasks.json changes |
Find hooks or folder-open persistence | These paths also contain legitimate configuration |
JFrog describes a configured exfiltration destination resembling an Anthropic API route, while stating that the sample does not prove compromise of Anthropic infrastructure. We recommend inspecting process and request context rather than treating a legitimate provider's entire domain as hostile. The same care applies to GitHub: platform use can be part of malicious activity without making every repository or request malicious.
Immediate response
First, preserve lockfiles, package caches, CI logs, process telemetry, relevant disk evidence and GitHub audit history. Determine which affected installations actually ran and which identities were present. We recommend pausing the implicated publishing workflow while investigators establish whether its commits and token requests were authorised.
Second, isolate affected workstations and runners and address persistence. JFrog warns that its analysed payload includes a token monitor capable of destructive action when a stolen GitHub token becomes invalid. Its response guidance places isolation, evidence preservation and persistence removal before token revocation from a clean system. This warning is about the analysed payload's capability, not proof that every installation deployed or triggered that mechanism.
Third, rotate exposed credentials from a clean environment once that containment sequence is secured. Include repository and npm tokens, CI secrets, cloud identities and other credentials available to affected execution contexts. Review their subsequent activity and reachable repositories; replacing a package does not invalidate a secret already collected. Rebuild affected systems where trust cannot be established.
ATT&CK context
Our mapping to MITRE ATT&CK is deliberately limited. The compromised npm delivery fits Compromise Software Dependencies and Development Tools, T1195.001. The documented search for developer secrets in local configuration fits Credentials In Files, T1552.001. The second mapping addresses that collection mechanism, not every cloud-API operation described by the researchers.
Use those mappings to assign coverage checks: package acquisition and lifecycle execution for the first, and sensitive-file access under the build identity for the second. Neither technique label identifies an actor or proves that a particular environment experienced the full chain.
Mitigation beyond the immediate incident
JFrog recommends temporarily suppressing lifecycle scripts where builds do not need them, reviewing newly published dependencies and rebuilding lockfiles from trusted metadata. We recommend testing such controls against legitimate build requirements before broad rollout. The useful outcome is an explicit decision about which packages may execute during installation and under which identity.
For publishing, review workflow changes, branch triggers, writable repository scope and OIDC token permissions. For runners, separate publishing access from routine dependency installation where feasible. For cloud access, reduce the permissions and secret visibility attached to build identities. These are defensive design recommendations responding to the observed trust path, rather than assertions that one setting would have prevented every part of the incident.
History and outlook
The initial reports published on 1 June 2026 connect this payload technically to earlier Shai-Hulud variants while preserving uncertainty about who operated it. The important continuity is credential collection and propagation through developer infrastructure; the distinguishing features described here include the installation loader, publishing workflow and Miasma repository marker.
Our likely (B2) judgement is that package removal alone will leave unresolved exposure where the malicious installer executed with useful credentials. The strongest reason is the combination of secret collection, publishing access and persistence in the analysed sample. The outstanding questions are environmental: what ran, what it could access, what it actually collected and whether those identities were reused. Those questions should determine closure, alongside Red Hat's continuing product investigation.
