Security researchers tracking the npm ecosystem disclosed in the early hours of June 2 that more than thirty packages published under the @redhat-cloud-services namespace had been replaced with malicious versions carrying a new self propagating malware family, tracked as Miasma. The worm is clearly derived from the Shai-Hulud strain that rocked the JavaScript registry in late 2025, but it carries additional evasion logic, a broader credential harvesting scope, and a more aggressive lateral movement routine that tries to publish itself from any developer or CI account it can hijack.
The initial infection vector appears to be a compromised maintainer account, possibly via session token theft or a phishing campaign targeting Red Hat staff. Once the attacker controlled the publish key, they pushed minor version bumps of legitimate utility libraries used inside OpenShift, Ansible, and a variety of cloud automation tools. Because semantic version ranges in package.json files routinely allow patch level upgrades, any organization that ran a fresh npm install or that rebuilt a container image during the exposure window automatically pulled the trojanized code.
What Miasma does once installed is the most worrying part. The malware enumerates the local filesystem for tokens belonging to GitHub, npm, AWS, GCP, Azure, and a growing list of other cloud and developer services. It then exfiltrates those tokens to attacker controlled GitHub repositories disguised as innocuous gists. In parallel, the malware uses any discovered npm tokens to publish itself into other packages owned by the victim, propagating the infection through the dependency graph. Researchers describe the propagation behavior as functionally identical to a classic worm, but operating at the speed of modern continuous integration.
Red Hat acknowledged the incident within hours, revoking the compromised credentials, removing the malicious versions from the npm registry, and issuing fresh signed releases. The company is coordinating with GitHub Security to identify and shut down the dead drop repositories used for exfiltration. Even so, the operational damage is considerable. Any developer workstation or CI runner that executed the malicious install scripts must be treated as compromised, with all locally cached credentials rotated immediately. Container images built during the window should be rebuilt from clean base layers and rescanned.
For us, the lesson is now familiar but no less urgent. Software supply chain attacks have become the dominant route into engineering organizations because they bypass perimeter controls entirely and execute with full developer privileges. The defensive playbook is well understood: pin exact versions in lock files, mirror critical dependencies into an internal proxy with allowlists, require signed provenance under SLSA or similar frameworks, and enforce hardware backed credentials for any account with publish rights. The challenge is operational discipline, not technology choice. Most engineering organizations still rely on long lived cloud tokens stored on disk because rotation friction has not been engineered away.
Retail technology teams should pay particular attention. Organizations like Ahold Delhaize and Carrefour run extensive Kubernetes estates with continuous deployment pipelines that pull from public registries. A single tainted dependency can ship into a production cluster before a human reviewer ever sees the diff. We recommend three immediate actions. First, scan build logs from the last twenty four hours for any installation of @redhat-cloud-services packages and quarantine the corresponding runners. Second, rotate every cloud and source control token that touched those pipelines, prioritizing AWS and GCP keys that grant write access to production. Third, review egress traffic from CI infrastructure to GitHub and to known anonymous tunneling services, since Miasma uses both channels.
The incident also reignites the debate about default permissions in package managers. npm install scripts continue to execute arbitrary code by default, a design decision that the ecosystem has discussed reforming for years without action. Several large enterprises now run npm with the --ignore-scripts flag and reintroduce lifecycle hooks selectively. That pattern is defensible and we expect it to become the standard recommendation from cloud security teams over the next quarter.
Finally, regulators will take note. GDPR breach notification thresholds are triggered when personal data is at material risk, and exfiltrated cloud credentials clearly meet that bar for many controllers. DORA, which is now in full force for European financial entities, imposes specific obligations to manage ICT third party risk, including software dependencies. We expect supervisory authorities to ask pointed questions about how member firms detected and contained Miasma, and what continuous monitoring they have in place for their open source dependency graphs. Boards that have not yet asked their CISO for a software bill of materials view of critical applications now have a concrete reason to do so.
A final observation on incident response sequencing. When a supply chain worm of this kind lands, the temptation is to focus first on the obvious damage: revoking tokens, rebuilding container images, and patching package versions. That work matters, but it is not enough on its own. Mature response teams will also reconstruct the timeline of every npm install that touched the affected namespace during the window, correlate those events with outbound traffic logs, and look for evidence of secondary publication attempts under developer accounts the worm may have hijacked. Skipping that secondary sweep is how organizations end up rediscovering Miasma three weeks later inside a forgotten staging cluster. We recommend a formal forty eight hour after action review involving security operations, platform engineering, and application owners, with explicit sign off that all affected credentials have been rotated and all suspect pipelines reviewed.
