On June 1, 2026, researchers reported that malicious versions of multiple npm packages under Red Hat’s
That is the real story. Miasma is less a freak accident than a preview of what supply-chain compromise looks like when attackers stop treating package registries as dumping grounds for obvious fakes and start treating them as privileged deployment channels. The package name was not the trick. The trust was.
The compromised packages were not random typosquats with misspelled names and disposable maintainers. They sat inside the
Researchers have identified malicious releases across a broad set of packages in that family, including clients and components tied to vulnerabilities, remediations, RBAC, sources, topology, and shared frontend tooling. Some reporting counted at least 32 malicious package releases; JFrog’s later analysis described a wider set of hijacked versions. The exact number matters for incident response, but the broader point is simpler: this was not a one-package problem.
The payload was triggered during installation through npm lifecycle scripting, notably a
That makes Miasma particularly relevant to WindowsForum readers who manage mixed fleets. A developer on Windows, a Linux CI runner, and a macOS laptop may all be part of the same credential fabric. The operating system boundary matters less than the identity boundary, and the identity boundary is increasingly GitHub, npm, Azure, Google Cloud, Kubernetes, Vault, and whatever secrets happen to live in shell history or
That adaptation matters. The malware used heavy JavaScript obfuscation, staged payloads, encryption, and transient execution paths to make simple scanning less useful. JFrog’s analysis described a loader that unwraps further stages, uses encrypted blobs, and can run payload logic through Bun, even downloading the runtime if needed. That turns a mundane npm install into a chain of Node, temporary files, runtime bootstrapping, and credential collection.
Wiz reported another important evolution: Miasma added collectors focused on cloud identities, including Google Cloud Platform and Microsoft Azure. Earlier Shai-Hulud-style activity was already dangerous because it hunted for secrets. Mapping identities goes a step further, because identity is how modern attackers pivot from “I stole a token” to “I understand the shape of your environment.”
This is where old mental models fail. If a malicious package steals one npm token, the immediate fear is package republishing. If it steals cloud credentials, GitHub tokens, SSH keys, Kubernetes context, Vault material, and CI/CD secrets, the compromise becomes an infrastructure incident. Miasma is the kind of package attack that forces security teams to ask not only “who installed it?” but “what could that machine or runner reach?”
The reports on Miasma consistently point to malicious install-time execution. In some packages, metadata that should have looked harmless — even type declarations or generated clients — was paired with a hidden execution path. A type-only package does not normally need to run a large obfuscated installer before it can be used. That mismatch is precisely the kind of weak signal defenders need to start treating as high value.
The problem is that npm’s ecosystem has normalized a lot of strange behavior. Packages download binaries, generate files, invoke shell commands, and patch environments as part of installation. In that culture, “this dependency runs code during install” is not always enough to stop a build. Miasma exploited that ambiguity.
The security response, then, cannot simply be “never allow lifecycle scripts,” though some high-security environments may move closer to that position. The more realistic enterprise answer is policy: block scripts by default in CI where possible, approve exceptions, pin versions, use lockfiles, inspect deltas between releases, and treat unexpected
Wiz reported evidence that a Red Hat employee GitHub account was compromised and used to push malicious commits into RedHatInsights repositories, bypassing normal review paths through orphan commits and temporary branches. WhiteIntel separately reported that Red Hat-associated GitHub credentials and session cookies had appeared in infostealer logs in April and May 2026, while carefully stopping short of proving that those credentials were the root cause of Miasma. That distinction matters.
There is a temptation after every supply-chain incident to collapse the story into one compromised account, one missing control, or one negligent maintainer. That is emotionally satisfying and operationally misleading. If credentials stolen from an endpoint can be converted into repository access, workflow execution, trusted publishing, and package distribution, the issue is not merely the first stolen password. It is the chain of assumptions that let the password become a release.
This is why the “trusted publisher” era needs sharper scrutiny. OIDC-based publishing can reduce the damage of long-lived npm tokens, and in many cases it is a real improvement. But if a malicious workflow can run in the right repository context and obtain the right publishing identity, provenance can tell you that a package came from a trusted pipeline while failing to tell you that the pipeline was abused.
A signed malicious package is still malicious. A package published through a legitimate workflow can still be attacker-controlled. A provenance trail can prove that the front door was used while saying little about whether the person entering had stolen the keys. The security industry sometimes talks about software provenance as though it settles the trust question; in reality, it narrows the question.
That distinction is crucial for enterprise administrators. Provenance can help answer whether an artifact came from a particular repository and workflow. It cannot, by itself, answer whether the commit was reviewed properly, whether the workflow file was temporarily altered, whether the publishing branch was legitimate, or whether the account initiating the process was operating under attacker control.
The lesson is not to abandon provenance. It is to demote it from magic shield to one signal among many. Strong artifact identity should be paired with branch protections, CODEOWNERS enforcement, workflow pinning, environment approvals, anomaly detection around publishing, and tight scoping of what CI jobs can do. If your release process can mint a production package from any pushed branch, you do not have a release process; you have a remote code execution service with better branding.
That is a strategic shift. In cloud-native environments, identity is infrastructure. A service account with broad permissions may be more valuable than a database password. A developer’s GitHub token may lead to workflows, workflows may lead to cloud deployments, and cloud deployment identities may lead to production resources.
For Microsoft-heavy shops, Azure is not just another target in the list. Many organizations have connected Entra ID, GitHub, Azure DevOps, Kubernetes, and secret stores in ways that are efficient but brittle under compromise. A developer workstation or CI runner with access to multiple tenants, subscriptions, repositories, and package registries can become a pivot point across the business.
That makes incident response harder. Rotating npm tokens is necessary but not enough. A serious response needs to include GitHub personal access tokens, GitHub Actions secrets, npm credentials, SSH keys, cloud access keys, Azure federated credentials, GCP service account material, Kubernetes contexts, Vault tokens, Docker credentials, and any secrets exposed through local configuration or CI logs. In the world Miasma represents, “dependency compromise” is only the first line of the incident ticket.
A modern developer endpoint may hold access to private repositories, production-like test environments, internal packages, cloud consoles, SSH bastions, container registries, AI coding tools, and deployment pipelines. It may also run arbitrary code from package managers dozens of times a day. That combination makes it one of the most valuable targets in the enterprise.
The same applies to CI runners. A GitHub Actions runner, Azure Pipelines agent, or self-hosted build box often has access that no human user should hold persistently. It checks out code, installs dependencies, signs artifacts, builds containers, publishes packages, deploys infrastructure, and reads secrets along the way. If dependency installation becomes attacker execution, the runner becomes a credential vending machine.
Miasma also reportedly looked for signs of endpoint detection and response products such as CrowdStrike, SentinelOne, and Carbon Black. That does not make it unstoppable, but it does show the attacker’s expectation: developer and CI environments are defended, monitored, and worth evading. The days when supply-chain malware could be treated as noisy package spam are over.
Miasma follows a sequence of recent npm and open-source ecosystem attacks involving Shai-Hulud variants, popular package compromises, AI-adjacent developer tooling, and CI/CD abuse. The common thread is not npm alone. It is the industrialization of dependency trust.
Every organization wants fast builds, reusable components, automated publishing, and low-friction developer experience. Every attacker wants exactly the same thing, because low friction for legitimate software often means low friction for malicious updates once trust is compromised. The more invisible the dependency layer becomes, the more dangerous a poisoned dependency can be.
This is why “just audit your dependencies” is both true and insufficient. Large organizations do not have a dependency graph; they have a dependency weather system. Packages appear through direct imports, transitive dependencies, build plugins, generated clients, test frameworks, scaffolding tools, and internal templates. If security teams cannot answer where a package exists, when it was installed, which version was used, and what credentials were present at install time, they are already behind.
A Windows developer using VS Code and npm can trigger the same install-time scripts as anyone else. A Windows-hosted build agent can hold Azure credentials, GitHub tokens, npm authentication, and SSH keys. WSL can blur boundaries further by putting Linux-style developer secrets alongside Windows identity and tooling. The endpoint operating system changes the artifacts, not the premise.
The reported persistence behavior around developer tools, including Visual Studio Code and Claude Code configurations, also deserves attention. Attackers understand that the developer environment is now an operating layer of its own. Editors, AI assistants, CLIs, package managers, and cloud SDKs are all places where trust can be harvested or quietly modified.
For Windows administrators, the defensive implication is practical: software restriction, EDR, and patching are only one part of the story. Organizations need visibility into package-manager execution, suspicious child processes from
The second response is rotation, but rotation needs discipline. Rotating obvious npm tokens while leaving GitHub PATs, cloud credentials, Kubernetes configs, Vault tokens, and SSH keys untouched is security theater. If a machine installed a malicious package that broadly searched for secrets, responders should assume all accessible credentials may have been exposed until logs and telemetry prove otherwise.
The third response is containment of publishing paths. Review GitHub workflows, especially those able to request OIDC tokens or publish packages. Look for temporary branches, unexpected workflow files, orphan commits, unusual release timing, and changes to package metadata. Verify that only protected branches can trigger publishing and that release jobs require the approvals your organization thinks they require.
Finally, treat package revocation as the beginning, not the end. Malicious versions disappearing from npm does not remove credentials already stolen, repositories already touched, workflows already modified, or persistence already placed on developer systems. The registry is only the distribution point. The incident lives wherever the payload executed.
Security vendors will, correctly, ship detections for known indicators. Registries will revoke malicious packages. Researchers will publish hashes, package lists, domains, repository markers, and YARA-like logic. Those steps are necessary, but they are reactive by design.
The strategic fix is to make the development pipeline less trusting by default. A package install should not be allowed to become an unobserved credential sweep. A CI workflow should not publish because a branch with a plausible name appeared. A developer token should not reach every repository forever. A cloud identity available to a build should not be able to enumerate half the company.
That is the hard cultural shift. Developers have been asked to move faster for two decades. Miasma is another invoice for that speed.
@redhat-cloud-services namespace had been published with install-time code designed to steal developer, cloud, and CI/CD credentials. The campaign, now being tracked as Miasma, is not frightening because it invented a new class of malware. It is frightening because it used the normal machinery of modern software delivery — trusted namespaces, package installs, GitHub workflows, cloud identities, and developer tooling — as the blast radius.That is the real story. Miasma is less a freak accident than a preview of what supply-chain compromise looks like when attackers stop treating package registries as dumping grounds for obvious fakes and start treating them as privileged deployment channels. The package name was not the trick. The trust was.
The Attack Worked Because the Packages Looked Boring
The compromised packages were not random typosquats with misspelled names and disposable maintainers. They sat inside the @redhat-cloud-services npm scope, a namespace associated with frontend components, API clients, and tooling around Red Hat’s cloud services ecosystem. That is exactly the sort of dependency that developers and automated build systems learn to stop questioning.Researchers have identified malicious releases across a broad set of packages in that family, including clients and components tied to vulnerabilities, remediations, RBAC, sources, topology, and shared frontend tooling. Some reporting counted at least 32 malicious package releases; JFrog’s later analysis described a wider set of hijacked versions. The exact number matters for incident response, but the broader point is simpler: this was not a one-package problem.
The payload was triggered during installation through npm lifecycle scripting, notably a
preinstall hook that invoked a malicious JavaScript file before the consuming application ever imported the package. That detail is easy to miss and hard to overstate. In npm, installation is execution; if lifecycle scripts are permitted, a dependency can run code simply by being resolved and installed.That makes Miasma particularly relevant to WindowsForum readers who manage mixed fleets. A developer on Windows, a Linux CI runner, and a macOS laptop may all be part of the same credential fabric. The operating system boundary matters less than the identity boundary, and the identity boundary is increasingly GitHub, npm, Azure, Google Cloud, Kubernetes, Vault, and whatever secrets happen to live in shell history or
.env files.Miasma Is Shai-Hulud With a Better Passport
The campaign appears to be derived from the Mini Shai-Hulud malware lineage, a family already associated with npm compromise, credential theft, GitHub abuse, and self-propagation. Miasma keeps much of that tradecraft while changing the delivery shape and campaign marker. In practical terms, defenders are not dealing with a brand-new species so much as an adapted strain.That adaptation matters. The malware used heavy JavaScript obfuscation, staged payloads, encryption, and transient execution paths to make simple scanning less useful. JFrog’s analysis described a loader that unwraps further stages, uses encrypted blobs, and can run payload logic through Bun, even downloading the runtime if needed. That turns a mundane npm install into a chain of Node, temporary files, runtime bootstrapping, and credential collection.
Wiz reported another important evolution: Miasma added collectors focused on cloud identities, including Google Cloud Platform and Microsoft Azure. Earlier Shai-Hulud-style activity was already dangerous because it hunted for secrets. Mapping identities goes a step further, because identity is how modern attackers pivot from “I stole a token” to “I understand the shape of your environment.”
This is where old mental models fail. If a malicious package steals one npm token, the immediate fear is package republishing. If it steals cloud credentials, GitHub tokens, SSH keys, Kubernetes context, Vault material, and CI/CD secrets, the compromise becomes an infrastructure incident. Miasma is the kind of package attack that forces security teams to ask not only “who installed it?” but “what could that machine or runner reach?”
The Preinstall Hook Was the Front Door
The most important technical feature of Miasma is also one of the oldest npm security headaches: lifecycle scripts. A package can define scripts that run automatically at install time, and developers have long relied on that behavior for compilation, setup, binary fetching, and other convenience functions. Attackers love convenience functions because they are trusted execution paths with good ergonomics.The reports on Miasma consistently point to malicious install-time execution. In some packages, metadata that should have looked harmless — even type declarations or generated clients — was paired with a hidden execution path. A type-only package does not normally need to run a large obfuscated installer before it can be used. That mismatch is precisely the kind of weak signal defenders need to start treating as high value.
The problem is that npm’s ecosystem has normalized a lot of strange behavior. Packages download binaries, generate files, invoke shell commands, and patch environments as part of installation. In that culture, “this dependency runs code during install” is not always enough to stop a build. Miasma exploited that ambiguity.
The security response, then, cannot simply be “never allow lifecycle scripts,” though some high-security environments may move closer to that position. The more realistic enterprise answer is policy: block scripts by default in CI where possible, approve exceptions, pin versions, use lockfiles, inspect deltas between releases, and treat unexpected
preinstall, postinstall, or runtime bootstrap behavior as a release-blocking event.The Red Hat Angle Is About Trust, Not Just Red Hat
Red Hat’s name gives this incident weight, but it should not be read as a narrow Red Hat story. The compromised namespace carried the reputation of a major open-source and enterprise software vendor, and that reputation made the packages useful as delivery vehicles. The attacker did not need to impersonate trust from the outside; the attack appears to have ridden through channels that already had it.Wiz reported evidence that a Red Hat employee GitHub account was compromised and used to push malicious commits into RedHatInsights repositories, bypassing normal review paths through orphan commits and temporary branches. WhiteIntel separately reported that Red Hat-associated GitHub credentials and session cookies had appeared in infostealer logs in April and May 2026, while carefully stopping short of proving that those credentials were the root cause of Miasma. That distinction matters.
There is a temptation after every supply-chain incident to collapse the story into one compromised account, one missing control, or one negligent maintainer. That is emotionally satisfying and operationally misleading. If credentials stolen from an endpoint can be converted into repository access, workflow execution, trusted publishing, and package distribution, the issue is not merely the first stolen password. It is the chain of assumptions that let the password become a release.
This is why the “trusted publisher” era needs sharper scrutiny. OIDC-based publishing can reduce the damage of long-lived npm tokens, and in many cases it is a real improvement. But if a malicious workflow can run in the right repository context and obtain the right publishing identity, provenance can tell you that a package came from a trusted pipeline while failing to tell you that the pipeline was abused.
Provenance Is Not the Same Thing as Intent
For years, the software industry has been moving toward signed artifacts, provenance attestations, SBOMs, and stronger registry authentication. That movement is necessary. Miasma shows why it is not sufficient.A signed malicious package is still malicious. A package published through a legitimate workflow can still be attacker-controlled. A provenance trail can prove that the front door was used while saying little about whether the person entering had stolen the keys. The security industry sometimes talks about software provenance as though it settles the trust question; in reality, it narrows the question.
That distinction is crucial for enterprise administrators. Provenance can help answer whether an artifact came from a particular repository and workflow. It cannot, by itself, answer whether the commit was reviewed properly, whether the workflow file was temporarily altered, whether the publishing branch was legitimate, or whether the account initiating the process was operating under attacker control.
The lesson is not to abandon provenance. It is to demote it from magic shield to one signal among many. Strong artifact identity should be paired with branch protections, CODEOWNERS enforcement, workflow pinning, environment approvals, anomaly detection around publishing, and tight scoping of what CI jobs can do. If your release process can mint a production package from any pushed branch, you do not have a release process; you have a remote code execution service with better branding.
The Cloud Identity Pivot Raises the Stakes
The most consequential evolution in Miasma may be its interest in cloud identities. Traditional credential stealers looked for obvious secrets: tokens, passwords, private keys, config files, and browser stores. Miasma reportedly goes further by collecting identity context from GCP and Azure environments, suggesting attackers want to understand not only what secrets exist but what they can do.That is a strategic shift. In cloud-native environments, identity is infrastructure. A service account with broad permissions may be more valuable than a database password. A developer’s GitHub token may lead to workflows, workflows may lead to cloud deployments, and cloud deployment identities may lead to production resources.
For Microsoft-heavy shops, Azure is not just another target in the list. Many organizations have connected Entra ID, GitHub, Azure DevOps, Kubernetes, and secret stores in ways that are efficient but brittle under compromise. A developer workstation or CI runner with access to multiple tenants, subscriptions, repositories, and package registries can become a pivot point across the business.
That makes incident response harder. Rotating npm tokens is necessary but not enough. A serious response needs to include GitHub personal access tokens, GitHub Actions secrets, npm credentials, SSH keys, cloud access keys, Azure federated credentials, GCP service account material, Kubernetes contexts, Vault tokens, Docker credentials, and any secrets exposed through local configuration or CI logs. In the world Miasma represents, “dependency compromise” is only the first line of the incident ticket.
Developer Workstations Are Now Tier-Zero Assets
Enterprise security has long treated domain controllers, identity providers, and production cloud accounts as crown jewels. Developer workstations often sat in a messier category: important, privileged, but also personal, tool-heavy, and difficult to lock down without harming productivity. Miasma is another reminder that this hierarchy is outdated.A modern developer endpoint may hold access to private repositories, production-like test environments, internal packages, cloud consoles, SSH bastions, container registries, AI coding tools, and deployment pipelines. It may also run arbitrary code from package managers dozens of times a day. That combination makes it one of the most valuable targets in the enterprise.
The same applies to CI runners. A GitHub Actions runner, Azure Pipelines agent, or self-hosted build box often has access that no human user should hold persistently. It checks out code, installs dependencies, signs artifacts, builds containers, publishes packages, deploys infrastructure, and reads secrets along the way. If dependency installation becomes attacker execution, the runner becomes a credential vending machine.
Miasma also reportedly looked for signs of endpoint detection and response products such as CrowdStrike, SentinelOne, and Carbon Black. That does not make it unstoppable, but it does show the attacker’s expectation: developer and CI environments are defended, monitored, and worth evading. The days when supply-chain malware could be treated as noisy package spam are over.
The Open-Source Social Contract Is Under Strain
Open source has always relied on a bargain that is more social than technical. Maintainers publish code, users consume it, companies build on it, and trust accretes through reputation, transparency, and habit. Package registries made that bargain scale. Attackers are now exploiting the scale.Miasma follows a sequence of recent npm and open-source ecosystem attacks involving Shai-Hulud variants, popular package compromises, AI-adjacent developer tooling, and CI/CD abuse. The common thread is not npm alone. It is the industrialization of dependency trust.
Every organization wants fast builds, reusable components, automated publishing, and low-friction developer experience. Every attacker wants exactly the same thing, because low friction for legitimate software often means low friction for malicious updates once trust is compromised. The more invisible the dependency layer becomes, the more dangerous a poisoned dependency can be.
This is why “just audit your dependencies” is both true and insufficient. Large organizations do not have a dependency graph; they have a dependency weather system. Packages appear through direct imports, transitive dependencies, build plugins, generated clients, test frameworks, scaffolding tools, and internal templates. If security teams cannot answer where a package exists, when it was installed, which version was used, and what credentials were present at install time, they are already behind.
Windows Shops Are Not Bystanders
It is tempting to frame npm supply-chain attacks as a JavaScript or Linux problem. That is a mistake. Windows development environments are deeply embedded in the same ecosystem, especially in enterprises using Node.js tooling, Visual Studio Code, GitHub, Azure, WSL, container workflows, and cross-platform build pipelines.A Windows developer using VS Code and npm can trigger the same install-time scripts as anyone else. A Windows-hosted build agent can hold Azure credentials, GitHub tokens, npm authentication, and SSH keys. WSL can blur boundaries further by putting Linux-style developer secrets alongside Windows identity and tooling. The endpoint operating system changes the artifacts, not the premise.
The reported persistence behavior around developer tools, including Visual Studio Code and Claude Code configurations, also deserves attention. Attackers understand that the developer environment is now an operating layer of its own. Editors, AI assistants, CLIs, package managers, and cloud SDKs are all places where trust can be harvested or quietly modified.
For Windows administrators, the defensive implication is practical: software restriction, EDR, and patching are only one part of the story. Organizations need visibility into package-manager execution, suspicious child processes from
npm, unexpected downloads of runtimes such as Bun during builds, anomalous GitHub CLI usage, and credentials stored in developer-accessible paths. The workstation is not just where code is written. It is where supply-chain risk lands.The Response Must Start With Assumed Exposure
The first response to an incident like Miasma is inventory. Which projects used affected@redhat-cloud-services packages? Which versions were installed? Which machines or CI jobs performed the installation? Which secrets were reachable from those environments at the time? These are uncomfortable questions because many organizations cannot answer them quickly.The second response is rotation, but rotation needs discipline. Rotating obvious npm tokens while leaving GitHub PATs, cloud credentials, Kubernetes configs, Vault tokens, and SSH keys untouched is security theater. If a machine installed a malicious package that broadly searched for secrets, responders should assume all accessible credentials may have been exposed until logs and telemetry prove otherwise.
The third response is containment of publishing paths. Review GitHub workflows, especially those able to request OIDC tokens or publish packages. Look for temporary branches, unexpected workflow files, orphan commits, unusual release timing, and changes to package metadata. Verify that only protected branches can trigger publishing and that release jobs require the approvals your organization thinks they require.
Finally, treat package revocation as the beginning, not the end. Malicious versions disappearing from npm does not remove credentials already stolen, repositories already touched, workflows already modified, or persistence already placed on developer systems. The registry is only the distribution point. The incident lives wherever the payload executed.
The Real Fix Is Slower Than the Attack
The uncomfortable truth is that the best defenses against Miasma-like attacks are not glamorous. They are version pinning, lockfile enforcement, least privilege, branch protection, workflow review, secrets hygiene, short-lived credentials, egress monitoring, and boring approval gates around publishing. These measures slow teams down just enough to matter, which is why they are often weakened in the name of velocity.Security vendors will, correctly, ship detections for known indicators. Registries will revoke malicious packages. Researchers will publish hashes, package lists, domains, repository markers, and YARA-like logic. Those steps are necessary, but they are reactive by design.
The strategic fix is to make the development pipeline less trusting by default. A package install should not be allowed to become an unobserved credential sweep. A CI workflow should not publish because a branch with a plausible name appeared. A developer token should not reach every repository forever. A cloud identity available to a build should not be able to enumerate half the company.
That is the hard cultural shift. Developers have been asked to move faster for two decades. Miasma is another invoice for that speed.
The Red Hat Miasma Lesson Is Smaller Trust Zones
The practical readout from this incident is not that npm is hopeless or that Red Hat packages should be treated as radioactive. It is that trusted ecosystems now require narrower trust zones, because package reputation, vendor branding, and automated provenance cannot carry the whole burden.- Organizations should identify any use of affected
@redhat-cloud-servicespackages and verify the installed versions, installation times, and systems involved. - Teams should rotate all credentials that were accessible from machines or CI runners that installed malicious versions, not only npm tokens.
- Build systems should restrict lifecycle scripts where possible and alert on unexpected install-time execution, runtime downloads, and obfuscated package payloads.
- GitHub and npm publishing workflows should be limited to protected branches, pinned actions, least-privilege permissions, and explicit release approvals.
- Cloud identities used by developers and CI jobs should be scoped narrowly enough that credential theft does not become environment-wide reconnaissance.
- Security teams should treat developer workstations and CI runners as high-value assets, not merely productivity endpoints.
References
- Primary source: secnews.gr
Published: 2026-06-02T08:30:10.235179
Miasma: New Supply Chain Attack Compromises Red Hat Npm Packages
New Miasma campaign compromises Red Hat npm packages to steal credentials and spread worms.
www.secnews.gr
- Related coverage: whiteintel.io
Red Hat Miasma Attack: A Linked GitHub Credential Surfaced in Stealer Logs
A Red Hat GitHub credential and session cookie were exposed in infostealer logs on April 13 and May 15, 2026, before the Miasma supply chain attack was disclosed. The credential belongs to an active Red Hat employee verified via LinkedIn.whiteintel.io
- Related coverage: wiz.io
Miasma: Supply Chain Attack Targeting RedHat npm Packages | Wiz Blog
Detect and mitigate malicious npm packages linked to the latest npm supply chain attack, based on the open sourced Mini Shai-Hulud malware.
www.wiz.io
- Related coverage: research.jfrog.com
Shai-Hulud - Miasma: The Spreading Blight Hits Red Hat npm Packages | JFrog
JFrog Security Research analyzed 31 hijacked `@redhat-cloud-services` npm package versions carrying a new Shai-Hulud variant. The campaign, identified in the payload as "Miasma: The Spreading Blight", uses install-time execution, layered JavaScript obfuscation, Bun-based payload delivery...
research.jfrog.com
- Related coverage: threataft.com
Miasma: Red Hat npm Packages Hijacked by Supply Chain Worm | ThreatAft
Miasma compromised 32 Red Hat npm packages in a supply chain attack, deploying a credential-stealing worm targeting AWS, GitHub, and SSH keys. Rotate now.threataft.com - Related coverage: snyk.io
Miasma Attack Hits Red Hat npm Packages | Snyk
A supply chain worm dubbed Miasma has been found in dozens of @redhat-cloud-services npm releases. The malicious preinstall hook steals credentials, probes cloud identities, and can republish other packages.snyk.io
- Related coverage: techradar.com
Mini Shai-Halud hackers publish over 600 compromised npm packages
The Shai-Hulud campaign continues, now affecting hundreds of new packages and potentially compromising thousands of projects.www.techradar.com
- Related coverage: access.redhat.com
Multiple Supply Chain Attacks against npm Packages - Red Hat Customer Portal
This document details two significant supply chain attacks affecting Node.js (NPM) packages: the "s1ngularity" attack on the Nx package and a separate compromise targeting several highly popular NPM developers. Red Hat Product Security has confirmed thataccess.redhat.com
- Related coverage: thehackernews.com
Miasma Supply Chain Attack Compromises Red Hat npm Packages with Credential-Stealing Worm
Compromised npm packages targeted Red Hat cloud services, enabling credential theft and expanding supply chain risks.
thehackernews.com
- Related coverage: panther.com
Mini Shai-Hulud Worm Hits @redhat-cloud-services npm Packages
A new Mini Shai-Hulud wave abused GitHub Actions OIDC to publish malicious @redhat-cloud-services npm packages under Red Hat's trusted identity. IOCs and response steps inside.
panther.com
- Related coverage: tomshardware.com
Compromised Mistral AI and TanStack packages may have exposed GitHub, cloud and CI/CD credentials in 'mini Shai Hulud' malware infection — supply-chain campaign spreads across npm and AI developer ecosystems like wildfire
The malware reportedly refused to run on Russian-language systems but could execute a destructive payload under certain geographic conditions.www.tomshardware.com
- Related coverage: cambiumnetworks.com
- Related coverage: labs.cloudsecurityalliance.org
- Related coverage: media.jfrog.com
- Related coverage: axis.com
