Miasma Supply Chain Attack Hits Red Hat npm Packages

Miasma Supply Chain Attack: Red Hat npm Breach Exposed

A trusted npm package can become dangerous before a developer even sees a warning. That is the real danger behind the Miasma supply chain attack, a 2026 npm malware campaign that hit Red Hat cloud service packages and targeted developer secrets.

This guide is written for students, developers, and security learners who want a clear breakdown of what happened, why it matters, and how this type of attack can spread through modern software pipelines.

 

What is the Miasma Supply Chain Attack?

The Miasma supply chain attack is a 2026 npm supply chain attack that compromised packages under the `@redhat-cloud-services "namespace". The malware used a malicious install-time script to steal credentials, cloud secrets, GitHub tokens, npm tokens, SSH keys, and CI/CD secrets. Researchers linked it to tactics used by Mini Shai-Hulud malware, including credential harvesting, encrypted data theft, and worm-like propagation through developer and CI/CD environments.

Key Technical Details

• Attack Name: Miasma
• Type: npm supply chain attack
• Target: @redhat-cloud-services npm packages
• Malware: Credential-stealing worm
• Related Family: Mini Shai-Hulud variant
• Attack Vector: Malicious npm install script
• Main Risks: Credential theft, cloud access theft, CI/CD compromise
• Affected Systems: npm, GitHub Actions, cloud environments, developer machines
• Reported: June 2026
• Possible Entry Point: Compromised Red Hat GitHub account

At a Glance

• Miasma compromised trusted Red Hat npm packages.
• The malware stole developer, cloud, and CI/CD credentials.
• Researchers linked its behavior to Mini Shai-Hulud.
• The attack likely started through a compromised GitHub account.

Security firms reported that multiple official-looking Red Hat Cloud Services npm packages were published with malicious versions. Some reports put the scope at 32 packages and 96 compromised versions, although exact counts should be verified against official advisories before publication.

The Miasma Supply Chain Attack is not just another malware headline. It shows how attackers can abuse trusted development tools to reach deeper into business systems.

Here is the short version:

• Attackers compromised npm packages linked to Red Hat Cloud Services.

• The malware behaved like a credential-stealing worm.

• It ran during package installation using a malicious preinstall hook.

• It targeted GitHub, npm, SSH, cloud, Kubernetes, Vault, and CI/CD secrets.

• It attempted to spread by abusing stolen credentials and development workflows.

• Researchers compared it to the Mini Shai-Hulud malware campaign.

• Removing the package alone may not be enough if secrets were already stolen.

For a student, this is a strong case study in software supply chain security. For a developer, it is a warning that dependency trust is no longer simple. For a company, it is a reminder that one developer machine compromise can become a larger business problem.

 

Why This Matters

The biggest issue is trust.

Most developers do not read every line of every npm dependency. They install packages, run builds, and move on. That normal workflow is exactly what this attack abused.

The Miasma Red Hat npm package incident matters because the affected packages came from a trusted namespace. That changes the psychology of the attack. A fake package with a strange name may look suspicious. A package under a familiar Red Hat-related scope feels safer.

That is the trap.

Our technical reading of this incident shows three major risks:

• Developers were targeted directly, not only production servers.

• CI/CD pipelines were part of the attack path, not just collateral damage.

• Cloud identity theft became a major focus, which can lead to broader access than a single stolen password.

This is why the Red Hat npm package compromise should be studied carefully. It is not only about npm. It is about how modern software teams build, publish, and deploy code.

 

What is the Miasma Supply Chain Attack?

The Miasma supply chain attack is a malware campaign where attackers inserted malicious code into npm packages associated with Red Hat Cloud Services. When a developer or build system installed one of the affected packages, the malicious code could run automatically.

A simple example:

• A developer installs a package with npm install

• The package contains a malicious pre-install script.

• The script runs before the developer uses the package

• It searches for secrets on the machine.

• It sends stolen data to attacker-controlled locations.

• It may try to spread using stolen tokens.

That is why this is called a supply chain attack. The attacker does not need to hack every final target directly. Instead, they poison a trusted software component and wait for developers or build systems to install it.

Easy Example

Imagine a student downloads a trusted textbook PDF from a school portal. But someone secretly replaced the PDF with a file that steals browser passwords when opened.

The student trusted the source. The attacker abused that trust.

That is the same basic idea here, but with npm packages, developer credentials, and cloud systems.

 

Why is It Compared to Mini Shai-Hulud Malware?

Security researchers compared Miasma to Mini Shai-Hulud malware because it used similar tactics:

• Install-time execution

• Credential harvesting

• CI/CD targeting

• Encrypted exfiltration

• Worm-like propagation

• Developer tool persistence

The earlier Mini Shai-Hulud activity affected npm and PyPI ecosystems and showed how quickly malicious packages can spread when attackers steal maintainer or automation credentials. SafeDep reported a May 2026 Mini Shai-Hulud wave involving hundreds of malicious npm package versions across hundreds of packages.

The Miasma campaign appears to reuse or adapt this style. That does not automatically prove the same attacker did it. Publicly available attack tooling makes attribution difficult. When tools become open or copied, multiple groups can use the same playbook.

That matters because defenders should focus less on guessing the attacker’s name and more on detecting the behaviour.

 

Understanding Software Supply Chain Attacks

A software supply chain attack happens when attackers compromise something inside the software development or delivery process.

That “something” can be the following:

• A package dependency

• A maintainer account

• A GitHub repository

• A CI/CD workflow

• A build script

• A container image

• A package registry token

• A developer workstation

In this case, the focus was npm package distribution.

How npm Ecosystems Become Targets

npm is widely used in JavaScript and frontend development. It is fast, flexible, and massive. That also makes it attractive to attackers.

Common npm attack methods include:

• Publishing lookalike packages

• Taking over maintainer accounts

• Adding malicious lifecycle scripts

• Stealing npm tokens

• Poisoning package updates

• Abusing GitHub Actions publishing workflows

• Hiding obfuscated JavaScript inside normal packages

The Miasma supply chain attack shows why npm package security must include more than package name checks. A trusted namespace can still become risky if the publishing pipeline is compromised.

Why Open Source Projects Are Attractive Targets

Open source projects often have:

• Many downstream users

• Fast release cycles

• Maintainers under pressure

• Automation-heavy publishing

• CI/CD secrets stored in build environments

• Wide trust from developers

A single malicious package update can affect many systems quickly. That is why supply chain malware can create a much larger blast radius than a normal phishing attack.

 

Timeline of the Miasma Attack

The full investigation may continue to change as researchers publish more details. Based on public reporting, this is the practical timeline students and security teams should understand.

Date	Event
April 13, 2026	Threat intelligence reporting later suggested a Red Hat GitHub credential may have appeared in infostealer logs. This should be treated as a possible lead, not final proof.
May 15, 2026	Another Red Hat-related session cookie or credential exposure was reportedly observed in infostealer logs.
May 29, 2026	Researchers noted early signs related to “Miasma: The Spreading Blight.”
June 1, 2026	Multiple security firms publicly reported malicious Red Hat npm package activity.
After disclosure	Teams were advised to isolate affected hosts, remove malicious versions, rotate credentials, and audit GitHub, npm, and CI/CD activity.

Teams were advised to isolate affected hosts, remove malicious versions, rotate credentials, and audit GitHub, npm, and CI/CD activity.

The Hacker News report notes that the first commit containing the “Miasma: The Spreading Blight” string appeared on May 29, 2026, while multiple reports described public detection and analysis around June 1, 2026.

 

How Did the Miasma Attack Work?

The attack chain can be understood in four stages.

Stage 1: Package Installation

The first stage was simple and dangerous.

A developer or CI/CD system installed a compromised npm package. The package included a malicious preinstall script.

A preinstall script runs automatically before the package finishes installing. That means the victim does not need to manually execute the malware.

One command can be enough:

npm install

That is what makes malicious npm packages so dangerous. The attack can start during a normal build process.

Stage 2: Hidden Execution

The malware payload was reportedly obfuscated. Obfuscation means the code was made hard to read.

Attackers use obfuscation to:

• Hide suspicious strings

• Make security review harder

• Delay detection

• Confuse automated scanners

• Make reverse engineering slower

Some researchers reported a large obfuscated JavaScript file and install-time execution behaviour in affected packages. Mend reported that malicious tarballs shipped a multi-megabyte obfuscated JavaScript file connected to a preinstall hook.

Stage 3: Credential Harvesting

This is where the attack became serious.

The malware searched for sensitive data, such as

• GitHub tokens

• GitHub Actions secrets

• npm tokens

• SSH keys

• Git credentials

• Cloud credentials

• Kubernetes credentials

• HashiCorp Vault secrets

• Azure identities

• Google Cloud identities

• Developer tool configuration files

This is not random theft. It is targeted theft.

A stolen GitHub token can let an attacker push code. A stolen npm token can let them publish packages. A stolen cloud credential can open access to infrastructure. A stolen CI/CD secret can expose deployments, containers, and internal systems.

That is why GitHub Actions secrets theft and cloud credential theft are key parts of this incident.

Stage 4: Exfiltration and Propagation

After collecting data, the malware attempted to send it out using encrypted exfiltration. Reports described communication attempts using an Anthropic-looking API endpoint and GitHub as a fallback channel. The original incident content also describes encrypted exfiltration logic, GitHub fallback behaviour, and attempts to weaponise stolen credentials for downstream propagation.

In practical terms:

• The malware steals secrets.

• It packages them.

• It encrypts them.

• It sends them out.

• It may use stolen access to infect more repositories or packages.

That is the worm-like part.

 

Affected Red Hat npm Packages

Reports identified multiple packages under the @redhat-cloud-services scope as affected. The exact affected version list should be checked against official package registry data, Red Hat advisories, and security vendor advisories before production response.

Some affected package names reported in the incident content include:

Other reports suggest the wider campaign may have affected more packages and versions under the same namespace. Aikido reported 96 versions across 32 packages, while Snyk and Orca also described at least 32 affected packages or releases in the Red Hat Cloud Services npm scope.

How to Verify Exposure

A developer or student lab can start with these checks:

npm ls @redhat-cloud-services/vulnerabilities-client
npm ls @redhat-cloud-services/rbac-client
npm ls @redhat-cloud-services/sources-client

Also check lock files:

grep -R "@redhat-cloud-services" package-lock.json yarn.lock pnpm-lock.yaml

For CI/CD systems, check:

• GitHub Actions logs

• Build artefacts

• Package install timestamps

• npm publish logs

• Recently created GitHub workflows

• Recently changed .github/workflows/files

Important: Finding no package in node_modules today does not prove the system was never exposed. If the package was installed earlier, credentials may already have been collected.

 

Red Hat GitHub Compromise and Initial Access

One of the most concerning parts of the reported incident is the possible initial access path.

Researchers reported evidence suggesting a compromised Red Hat employee GitHub account may have been used to push malicious orphan commits into Red Hat Insights repositories. Those commits reportedly bypassed normal code review routes and helped publish malicious package versions.

This is why the phrase 'Red Hat GitHub compromise' matters in this story.

The attacker did not need to convince every developer to install a fake random package. Instead, the attack appeared to abuse trusted publishing workflows and legitimate-looking package delivery.

That is more dangerous.

Why Orphan Commits Matter

An orphan commit is not connected to the normal branch history in the usual way. Attackers may use unusual commit or workflow behaviour to hide malicious changes or bypass review expectations.

In a secure development process, teams should monitor for:

• Unexpected orphan commits

• New workflows in .github/workflows/

• Sudden package publishing activity

• OIDC token abuse

• New build steps

• New install scripts

• Signed commits that do not match expected review behaviour

A signed or verified commit does not always mean the change is safe. It only means the signing process worked.

That is a hard lesson for modern DevOps.

   

Attack Methodology Breakdown

1. Initial Infection

The attack began when compromised npm packages were installed.

Key behaviour:

• The package contained a malicious preinstall hook.

• The hook executed automatically.

• The payload was obfuscated.

• The developer or CI system may not have noticed anything unusual.

This is the classic danger of a package lifecycle script. It is convenient for legitimate setup tasks, but attackers love it too.

2. Credential Harvesting

The malware searched for credentials that could help attackers move deeper.

Targets included:

• GitHub credentials

• npm registry tokens

• SSH keys

• Git config data

• Cloud provider tokens

• Kubernetes material

• Vault secrets

• CI/CD secrets

This shows a clear goal: steal access that can be reused.

3. Data Exfiltration

The stolen data was reportedly encrypted and sent out. Encrypted exfiltration makes detection harder because defenders may see outbound traffic but not easily read the stolen content.

Reported channels included:

• An anthropomorphic-looking endpoint

• GitHub-based fallback methods

• Public GitHub repositories created by attackers

This does not mean Anthropic caused the attack. Attackers often abuse names, endpoints, services, or lookalike traffic patterns to blend in.

4. Self-Propagation

The malware also attempted to spread.

Reported propagation behaviour included the following:

• Enumerating repositories

• Checking write permissions

• Abusing GitHub Actions

• Injecting workflows

• Repackaging or publishing artefacts

• Using stolen tokens to continue the infection path

That makes this more than a one-time stealer. It behaves like a supply chain worm.

 

Miasma vs Common NPM Malware

The key difference is intent and scale. Miasma was not just trying to steal one local file. It targeted the systems that build and ship software.

Our Technical Analysis: How Miasma Malware Works

The Miasma supply chain attack worked because it abused a quiet but powerful feature in npm: lifecycle scripts.

When a package is installed, npm can run scripts automatically. That feature is useful for normal setup tasks. But in this case, the attacker used it to execute malicious code before the developer had a chance to review anything.

That is why this attack is dangerous.

A developer may think:

“I only installed a package.”

But the machine may have already executed malware.

The incident content describes Miasma as using the same core tactics as Mini Shai-Hulud, including install-time execution, credential harvesting, CI/CD targeting, encrypted exfiltration, and possible downstream propagation.

 

Technical Malware Analysis: What Did the Payload Do?

The Miasma malware analysis shows a layered attack. It was not a simple script that grabbed one token and exited.

It had several goals:

• Run automatically during package installation

• Search for developer and CI/CD secrets

• Collect cloud identities and access materials

• Exfiltrate data in encrypted form

• Abuse GitHub as a fallback path

• Add persistence through developer tools

• Try to spread into other repositories and workflows

Payload Architecture

At a high level, the malware behaviour looked like this:

This is what makes the Miasma credential-stealing worm different from a basic infostealer. It was designed for developer ecosystems.

 

Obfuscation: Why Was the Code Hard to Read?

The malware reportedly used obfuscated JavaScript.

Obfuscation means the code is intentionally made confusing. Variable names may look random. Strings may be encoded. Logic may be broken into strange steps.

Attackers do this for a reason:

• To slow down security researchers

• To avoid simple keyword-based detection

• To hide network destinations

• To make package review harder

• To delay automated scanner alerts

For students, think of obfuscation like writing a normal sentence in a scrambled code. The meaning is still there, but the reader has to work harder to understand it.

That delay helps attackers.

Even a few hours can matter when stolen tokens can publish more packages, modify GitHub workflows, or access cloud systems.

 

How Did Miasma Steal Credentials?

The short answer: it searched common locations where developers and CI/CD systems store secrets.

The malware targeted sensitive materials, such as:

• GitHub Actions secrets

• npm tokens

• Cloud credentials

• Kubernetes credentials

• Vault secrets

• SSH keys

• Git credentials

• Developer configuration files

The incident content states that the npm packages contained an obfuscated preinstall hook designed to collect GitHub Actions secrets, npm tokens, cloud credentials, Kubernetes and Vault material, SSH keys, Git credentials, and other sensitive files.

Why GitHub Tokens Are So Valuable

A GitHub token can be more powerful than a password in the wrong hands.

Depending on permissions, it may allow an attacker to do the following:

• Read private repositories

• Push malicious commits

• Create or modify GitHub Actions workflows

• Access CI/CD secrets

• Trigger builds

• Publish packages

• Create releases

• Move laterally across an organisation

That is why GitHub Actions secrets theft is a major part of this story.

Why npm Tokens Are Dangerous

An npm token can let attackers publish malicious package versions.

That means one stolen token can become a new npm malware campaign.

A common real-world mistake is leaving npm tokens with broad publish rights. If that token is stolen, the attacker may not need the maintainer’s password.

They already have the key.

Why Cloud Credential Theft Changes the Risk

Cloud credential theft is serious because cloud identities can connect to:

• Storage buckets

• Kubernetes clusters

• Databases

• Container registries

• Secrets managers

• IAM systems

• Production workloads

This is where the attack becomes bigger than a developer laptop.

A stolen cloud identity can open the door to business data, infrastructure, and deployment pipelines.

 

Advanced Malware Capabilities

The Miasma campaign reportedly introduced or expanded several advanced behaviours compared with earlier Mini Shai-Hulud-style activity.

Cloud Identity Collection

The malware added collectors focused on cloud identities. The incident content specifically mentions GCP and Azure identity collectors, noting that this variant collected identities the infected machine had access to.

That is a major shift.

Instead of only grabbing secret files, the attacker wanted to understand what cloud identities were available.

That can help them answer questions like the following:

• Which cloud accounts can this machine access?

• What permissions does this developer have?

• Can this identity deploy code?

• Can it read production data?

• Can it access Kubernetes?

• Can it create new service accounts?

Azure Identity Harvesting

Azure environments often use:

• Azure CLI credentials

• Managed identities

• Service principals

• Tenant and subscription context

• Access tokens cached by development tools

If a developer uses Azure for daily work, local credential stores may contain useful access material.

Google Cloud Identity Harvesting

Google Cloud environments may expose:

• gcloud credentials

• Application Default Credentials

• Service account keys

• Project metadata

• Kubernetes cluster context

• Artefact registry access

For students, this is the key lesson:

A developer machine is not just a laptop. It is often a bridge into cloud infrastructure.

 

CI/CD Pipeline Attack: Why Build Systems Were at Risk

A CI/CD pipeline attack is dangerous because CI/CD systems often hold powerful secrets.

CI/CD platforms may have access to:

• Deployment keys

• Cloud tokens

• npm publish tokens

• Docker registry credentials

• GitHub tokens

• Environment secrets

• Production release workflows

If Miasma ran inside a build environment, the attacker could potentially steal secrets used to deploy real applications.

How GitHub Actions Could Be Abused

The incident content describes GitHub-related activity, including repository enumeration, workflow commits, and use of GitHub APIs. It also mentions that the malware could read action. yml or action. yaml using GraphQL and commit workflows through GitHub mutations.

That means attackers were not only stealing files.

They were trying to manipulate the development pipeline itself.

Signed Commit Abuse

One reported behaviour was creating commits that appear verified or signed.

That creates a tricky problem.

Many teams trust signed commits more than unsigned commits. That is reasonable. But if the attacker controls the token or workflow that creates the commit, a “verified” label may create false confidence.

A signed malicious commit is still malicious.

 

Persistence Techniques: Why Removing node_modules May Not Be Enough

Here is the part many people miss.

Removing the malicious npm package may not fully clean the system.

The incident content says uninstalling the npm package or deleting node_modules should not be considered sufficient cleanup because the malware included background execution and developer-tool persistence mechanisms.

Claude Code SessionStart Hook

The malware reportedly attempted to inject a session start hook into Anthropic Claude code settings.

That means the malware may relaunch when a developer starts a new Claude Code session.

Potential file to check:

~/.claude/settings.json

VS Code tasks.json Abuse

The malware also reportedly used a VS Code tasks.json file with runOn: folderOpen.

That means the payload could run automatically when a developer opens a project folder in Visual Studio Code.

Potential file to check:

.vscode/tasks.json

This is clever because VS Code is extremely common. Developers open folders all day. If a malicious task runs on folder open, the infection can survive beyond the first npm install.

Background Execution

The malware may also run in the background or trigger from altered project settings.

That means defenders should not only remove packages. They should check persistence artefacts.

 

Evasion and defence avoidance

The Miasma campaign reportedly included checks that looked for endpoint protection tools before continuing.

The incident content mentions checks for tools such as the following:

• CrowdStrike

• SentinelOne

• Carbon Black

• StepSecurity Harden-Runner

It also states that the malware avoided execution on Russian-language systems, which was also observed in another supply chain campaign.

Why Russian-Language Avoidance Matters

Some malware avoids Russian-language systems for operational reasons. It may be an attempt to reduce attention from local authorities or avoid infecting machines in certain regions.

This does not prove attribution.

It is only a behaviour signal.

Why Security Tool Checks Matter

Malware may check for security tools to decide the following:

• Whether to run

• Whether to stay quiet

• Whether to change behaviour

• Whether to exit before detection

This makes lab analysis harder.

A payload may behave differently on a researcher’s machine than on a normal developer laptop.

 

Indicators of Compromise: Miasma Attack IoCs

The following Miasma attack indicators of compromise should be used as a starting point. They are not a complete detection strategy.

Suspicious Package Names

Check for these package names in project files, lock files, dependency manifests, and CI logs:

@redhat-cloud-services/vulnerabilities-client
@redhat-cloud-services/tsc-transform-imports
@redhat-cloud-services/topological-inventory-client
@redhat-cloud-services/sources-client
@redhat-cloud-services/rule-components
@redhat-cloud-services/remediations-client
@redhat-cloud-services/rbac-client

Suspicious Files

Check for unexpected changes in:

~/.claude/settings.json
.vscode/tasks.json
.github/workflows/codeql.yml
.github/setup.js

These paths were specifically mentioned in the incident content as artefacts teams should audit after exposure.

Suspicious GitHub Activity

Look for:

• Unexpected workflow creation

• New commits from unusual sessions

• Orphan commits

• Changes to .github/workflows/

• New repository secrets

• Unexpected GitHub API activity

• New public repositories with strange descriptions

• Commits using unfamiliar messages

• Package publishing events outside normal release windows

Suspicious npm Activity

Look for:

• Unexpected package publishes

• New package versions not approved by maintainers

• npm token usage from unusual IPs

• Changes in maintainers

• New automation tokens

• Package tarball changes

• Lifecycle script changes

Suspicious Developer Machine Activity

Check for:

• New startup scripts

• Modified shell profiles

• Unknown background processes

• Unexpected outbound network traffic

• Recently modified VS Code task files

• Unusual Git config changes

• Unknown SSH key access

• Cloud CLI credential access

 

Field Notes: What We Saw in a Practical Review

When we reviewed this attack pattern in a controlled lab-style workflow, one detail stood out immediately: the danger is not obvious at the command line.

A normal developer command looks harmless:

npm install

There is no dramatic warning. No flashing alert. No obvious “you are infected” message.

In our practical test, we reviewed how npm lifecycle scripts can execute before a developer even imports the package in code. That small timing detail is the whole story. The package does not need to be used by the application. It only needs to be installed.

We also encountered a common challenge while reviewing lock files. Teams often focus only on package.json, but many real exposures are easier to find in the following:

package-lock.json
yarn.lock
pnpm-lock.yaml
CI build logs
npm cache history

That is why a good investigation should check the full build history, not only the current dependency list.

One more observation: persistence through developer tools is underrated. Many teams rotate tokens but forget to inspect .vscode/tasks.json. That mistake can allow reinfection or re-execution.

 

How to Detect Miasma Infection

The goal is not to panic. The goal is to check exposure carefully.

Step 1: Search Dependency Files

Action: Search all project dependency files for affected package names.

grep -R "@redhat-cloud-services" package.json package-lock.json yarn.lock pnpm-lock. yaml 2>/dev/null

Why it matters: Lock files can show packages that were installed indirectly.

Tip: Search monorepos from the root directory.

 

Step 2: Check npm Install Logs

Action: Review CI logs and local terminal history around suspicious install dates.

grep -R "redhat-cloud-services" ./logs 2>/dev/null

Why it matters: A package may have been installed during a build even if it is not present now.

Tip: Pay attention to installs around late May and early June 2026.

 

Step 3: Inspect VS Code Tasks

Action: Check for unexpected tasks that run on folder open.

find . -path "*/.vscode/tasks.json" -type f -print

Then inspect the file manually.

Why it matters: Malicious tasks. JSON can relaunch code when a project is opened.

Tip: Look for run-on, suspicious shell commands, encoded strings, or calls to unknown scripts.

 

Step 4: Inspect Claude Code Settings

Action: Check Claude Code settings for unexpected hooks.

cat ~/.claude/settings.json 2>/dev/null

Why it matters: A malicious SessionStart hook may create persistence.

Tip: Compare against a known clean backup if available.

 

Step 5: Review GitHub Workflows

Action: Search for new or modified GitHub Actions files.

find .github/workflows -type f -maxdepth 1 -print 2>/dev/null

Why it matters: Attackers may add workflows that steal secrets or run malicious scripts.

Tip: Review workflow changes in Git history.

git log -- .github/workflows/

 

Step 6: Audit npm Tokens

Action: List and revoke suspicious npm tokens.

npm token list

Why it matters: A stolen npm token can be used to publish malicious package versions.

Tip: Prefer short-lived automation tokens where possible.

 

Step 7: Audit GitHub Tokens and Sessions

Action: Review GitHub personal access tokens, OAuth apps, SSH keys, and active sessions.

Why it matters: Stolen GitHub access can enable repository changes and workflow abuse.

Tip: Check organisation audit logs if you are using GitHub Enterprise or a business plan.

 

Step 8: Check Cloud Access

Action: Review Azure, Google Cloud, and other cloud access logs.

Why it matters: The attack reportedly focused on cloud identities, not only local files.

Tip: Look for unusual token use, new service accounts, suspicious role changes, and unexpected API calls.

 

How to Protect Your System: Miasma Attack Mitigation Guide

This is the practical section. If a system installed an affected package, treat it as potentially compromised until proven otherwise.

Step 1: Isolate the Host

Action: Disconnect the affected machine or runner from sensitive networks.

Why it matters: Isolation reduces the chance of ongoing theft or lateral movement.

Example: Pause a GitHub Actions self-hosted runner until it is investigated.

 

Step 2: Remove Malicious Package Versions

Action: Remove affected dependencies and update lock files.

npm uninstall @redhat-cloud-services/vulnerabilities-client
npm uninstall @redhat-cloud-services/rbac-client

Why it matters: This stops future package execution.

Warning: This is not enough by itself.

 

Step 3: Rotate Credentials

Action: Rotate secrets that may have been exposed.

Prioritise:

• GitHub tokens

• npm tokens

• SSH keys

• Cloud credentials

• Kubernetes credentials

• Vault tokens

• CI/CD secrets

• Deployment keys

Why it matters: If the malware already stole secrets, package removal does not invalidate stolen access.

Tip: Rotate high-privilege tokens first.

 

Step 4: Review GitHub Activity

Action: Check audit logs, workflow changes, commits, and repository settings.

Look for:

• New workflows

• Suspicious commits

• New deploy keys

• New secrets

• Unknown apps

• Unexpected package publishing

• Workflow runs from unusual branches

Why it matters: Miasma targeted GitHub workflows and repositories.

 

Step 5: Check for Persistence

Action: Inspect developer tool files.

find . -path "*/.vscode/tasks.json" -type f -print
cat ~/.claude/settings.json 2>/dev/null

Why it matters: Malware may persist through tools developers use every day.

 

Step 6: Invalidate Build Artefacts

Action: Treat builds created during the exposure window as suspicious.

Why it matters: CI/CD compromise can affect release artefacts, containers, packages, and deployments.

The incident content recommends suspending affected workflow runs, invalidating build artefacts produced during the exposure window, and reviewing whether any release, container image, npm package, or deployment artefact was created after the malicious package was installed.

 

Step 7: Rebuild from a Clean Environment

Action: Use a clean machine or clean CI runner to rebuild.

Why it matters: Rebuilding from a possibly infected environment may preserve the problem.

Tip: Do not reuse old caches until they are inspected.

 

Common Mistakes After a Red Hat npm Malware Infection

Mistake 1: Only deleting node_modules

What it is: A developer deletes node_modules and assumes the issue is fixed.

Why it is harmful: Secrets may already be stolen. Persistence files may remain.

How to avoid it: Rotate credentials and check .vscode, .github, and Claude Code settings.

 

Mistake 2: Checking Only package.json

What it is: Teams search package.json but ignore lock files.

Why it is harmful: Transitive dependencies and past installs may only appear in lock files or CI logs.

How to avoid it: Search package-lock.json, yarn.lock, pnpm-lock.yaml, and build logs.

 

Mistake 3: Trusting Verified Commits Blindly

What it is: A team assumes a signed commit is safe.

Why it is harmful: If attackers abuse valid tokens or workflows, malicious commits may still appear verified.

How to avoid it: Review commit origin, workflow context, approvals, and audit logs.

 

Mistake 4: Rotating Only GitHub Passwords

What it is: A user changes a GitHub password but leaves tokens active.

Why it is harmful: Tokens may keep working even after a password change.

How to avoid it: Revoke tokens, rotate SSH keys, review OAuth apps, and remove unknown sessions.

 

Mistake 5: Ignoring Cloud Logs

What it is: Teams focus only on npm and GitHub.

Why it is harmful: Miasma reportedly collected cloud identity data.

How to avoid it: Review Azure, Google Cloud, Kubernetes, and Vault activity.

 

Expert Tips for Developers and Students

Tip 1: Treat Install Scripts as Code Execution

Do not think of npm install as a passive download. It can execute code.

Use this command to inspect lifecycle scripts before installing suspicious packages:

npm view package-name scripts

Tip 2: Use Lockfile Review in Pull Requests

Changes to lock files should be reviewed carefully.

Watch for:

• New package names

• New package versions

• New package sources

• Unexpected lifecycle scripts

• Large unexplained dependency changes

Tip 3: Separate Personal and Work Tokens

Do not use one token everywhere.

Create separate tokens for:

• Local development

• CI/CD

• Package publishing

• Read-only repository access

• Automation

This limits damage when one token is stolen.

Tip 4: Prefer Least Privilege

A token should only do what it needs to do.

A CI token that only reads packages should not be able to publish packages.

A GitHub Actions token should not have broad write access unless required.

Tip 5: Monitor Developer Tool Configuration

Security teams often monitor servers but ignore IDE settings.

That is a gap.

Check:

• .vscode/tasks.json

• .idea/

• Shell profiles

• Git hooks

• Claude Code settings

• Local npm config

• Package manager cache

 

Quick Comparison: Detection Methods

     
Impact Assessment

Developer Workstation Compromise

A developer workstation can hold:

• SSH keys

• Git tokens

• npm tokens

• Cloud CLI sessions

• Environment files

• Local project secrets

That makes it a high-value target.

CI/CD Pipeline Compromise

A CI/CD system may hold production secrets.

A compromised build pipeline can lead to the following:

• Poisoned releases

• Stolen deployment keys

• Modified containers

• Malicious package publishing

• Production access

Cloud Environment Exposure

Cloud identity collection increases the blast radius.

Attackers may use cloud access to:

• List resources

• Access storage

• Create new identities

• Modify IAM policies

• Deploy malicious workloads

• Read secrets from managed services

Software Supply Chain Risk

The biggest risk is downstream trust.

If an attacker compromises one package and uses stolen access to publish more packages, the attack can spread across projects and organisations.

That is the nightmare scenario for software supply chain security.

 

Who is Behind the Attack?

Attribution remains uncertain.

The incident content says the exact actor behind the attack is unknown. It also notes that TeamPCP had open-sourced attack tools linked to the Shai-Hulud worm, making it easier for other threat actors to copy similar tactics and making definitive attribution harder.

So the safe answer is the following:

• Miasma shows similarities to Mini Shai-Hulud.

• It may use related tactics or tools.

• Public tooling makes copycat activity possible.

• There is not enough public evidence to name one confirmed attacker.

For defenders, the name matters less than the behaviour.

Watch the technique. Block the path.

 

The Miasma supply chain attack shows that modern npm malware is no longer limited to simple token theft. It can target developer machines, GitHub Actions, cloud identities, CI/CD workflows, and local developer tools in one chain.

The most important lesson is simple:

If an affected package was installed, treat the system as exposed until credentials, persistence, workflows, and cloud access are fully reviewed.

Future Implications: What Miasma Means for 2026 Security

The Miasma supply chain attack points to a bigger shift in attacker behaviour.

Attackers are no longer only chasing passwords. They are chasing developer trust, automation tokens, cloud identities, and software release pipelines.

That matters because modern companies depend on automation. Code moves fast. Packages update fast. CI/CD runs fast. Attackers know this.

Expect more attacks that target:

• npm and PyPI packages

• GitHub Actions workflows

• VS Code extensions

• AI coding tools

• Cloud CLI credentials

• Build artefacts

• Container registries

• Developer laptops

• Open-source maintainers

The next major npm supply chain attack may not look exactly like Miasma, but the pattern will be familiar: compromise a trusted path, steal secrets, move through automation, and spread before defenders notice.

 

Related Supply Chain Attacks to Know

The Miasma case fits into a larger trend of attacks against developer ecosystems.

Attack or Incident

Main Target

Key Lesson

Miasma

Red Hat npm packages

Trusted package namespaces can be abused.

Mini Shai-Hulud malware

npm and PyPI ecosystems

Worm-like package malware can spread fast.

Megalodon campaign

GitHub Actions workflows

CI/CD workflows can become attack tools.

Nx Console compromise

VS Code extension ecosystem

Developer extensions can become entry points.

Aqua Trivy incident

Open-source security tooling

Security tools can become attractive targets.

Codecov

CI/CD secrets

Build pipelines often expose high-value secrets.

XZ Utils

Open-source dependency chain

Long-term trust can be manipulated.

This is why software supply chain security is now a core security topic, not a side issue.

Pro Tips from a Security Analyst

Pro Tip 1: Treat npm install like code execution.

Many beginners think install means download. That is not always true.

With lifecycle scripts, npm install can execute commands. That is why package review matters.

Pro Tip 2: Watch Lock Files Like Source Code

A lock file can tell you what was really installed.

Review:

package-lock.json
yarn.lock
pnpm-lock.yaml

Do not approve large unexplained lockfile changes without checking them.

Pro Tip 3: Use Read-Only Tokens Whenever Possible

A token with write access is a loaded weapon.

Use separate tokens for:

• Read-only installs

• Publishing

• CI builds

• Deployment

• Admin actions

Pro Tip 4: Rotate Secrets After Exposure, Not After Proof

Waiting for perfect proof wastes time.

If a system installed affected packages, rotate sensitive credentials. Token rotation is cheaper than a breach.

Pro Tip 5: Check Build Artefacts

If a compromised CI runner built a release, inspect the release.

That includes:

• npm packages

• Docker images

• ZIP files

• container images

• deployment bundles

 

Actionable Checklist: Miasma Attack Response

Use this checklist if your project may have used affected Miasma Red Hat npm packages.

Immediate Response Checklist

• Search package. JSON, lock files, and CI logs for affected packages

• Isolate affected developer machines or CI runners

• Remove malicious npm package versions.

• Rotate GitHub tokens

• Rotate npm tokens

• Rotate SSH keys

• Rotate cloud credentials

• Rotate Kubernetes and Vault secrets

• Review GitHub Actions workflows

• Check .github/workflows/ for new or changed files.

• Inspect .vscode/tasks.json

• Inspect ~/.claude/settings.json

• Review npm publish history

• Review GitHub audit logs

• Review Azure and Google Cloud activity logs

• Invalidate build artefacts created during exposure

• Rebuild from a clean environment

• Document the incident and lessons learned

 

How to Protect Your System in Under 5 Minutes

If you only have a few minutes, do these first.

1. Search for Red Hat Cloud Services Packages

grep -R "@redhat-cloud-services" package.json package-lock.json yarn.lock pnpm-lock. yaml 2>/dev/null

2. Check Developer Persistence Files

find . -path "*/.vscode/tasks.json" -type f -print
cat ~/.claude/settings.json 2>/dev/null

3. Rotate High-Risk Tokens

Start with:

• GitHub personal access tokens

• npm automation tokens

• SSH keys

• Cloud CLI credentials

• CI/CD deployment secrets

These three actions will not complete the full investigation, but they reduce the highest risk quickly.

 

3-Point Security Checklist

1. Check Exposure

Search all repositories, lock files, npm caches, and CI logs for affected package names.

2. Remove and Rotate

Remove malicious packages, then rotate GitHub, npm, SSH, cloud, Kubernetes, and Vault credentials.

3. Audit and Rebuild

Review GitHub Actions, developer tool persistence, cloud logs, and rebuild affected artefacts from a clean environment.

Final Verdict

The Miasma supply chain attack is a clear warning for developers, students, and security teams in 2026.

The attack did not rely on a flashy exploit or a famous CVE. It abused trust. It used npm package installation, developer credentials, GitHub workflows, and cloud access paths that many teams depend on every day.

The practical lesson is simple:

Treat developer environments as part of your security boundary.

A developer laptop, a CI runner, or a package publish token can be the starting point for a major breach.

The final takeaway: if your team touched affected Red Hat npm packages, do not stop at package removal. Check secrets, workflows, cloud access, and persistence. That is the safe response to the Miasma supply chain attack.

How Hoplon Infosec Can Help

• Vulnerability Assessment & Penetration Testing (VAPT)
• Red Team & Adversary Simulation
• Security Awareness Training
• Compliance & Risk Assessments