VPS Security & Server Management

Miasma Supply Chain Attack – What Node.js and VPS Owners Need to Know Right Now

Published by The Orange Club Infrastructure Team | June 2026 | 9 min read

If you run Node.js projects on a VPS and use npm packages, you need to read this. On June 1, 2026, a supply chain attack codenamed Miasma was discovered targeting the @redhat-cloud-services namespace on the npm registry. At least 32 package releases were found to contain a credential-stealing worm that executed automatically the moment you ran npm install – no interaction required.

The worm harvests developer credentials, CI/CD secrets, SSH keys, and cloud provider identities – then attempts to spread itself by republishing to other npm packages it can access. Proof-of-concept tooling has already been open-sourced, meaning copycat variants are expected throughout the rest of 2026. This guide will help you check whether you were affected and exactly what to do about it.

What Miasma Actually Is

Miasma is a supply chain attack campaign that compromised the @redhat-cloud-services npm namespace by gaining access to a Red Hat employee’s GitHub account. The attacker used this access to publish malicious versions of legitimate packages – 32 releases in total – embedding a credential-stealing worm derived from a previously known malware family called Shai-Hulud.

Unlike a traditional server vulnerability where an attacker scans for open ports or exploits a service, a supply chain attack targets the software you install. The malicious code rode inside packages that looked legitimate, signed through Sigstore, and published under a trusted namespace. There was no way to tell from the outside that anything was wrong.

The campaign is named Miasma after a string found in the first malicious commit – “Miasma: The Spreading Blight” – dated May 29, 2026. Active exploitation was confirmed on June 1, 2026 when researchers identified the compromised packages. Red Hat confirmed that no official Red Hat products were shipped with the compromised versions, and the malicious releases were rapidly revoked from the npm registry.

How the Worm Executes and Spreads

The Miasma worm is embedded in the preinstall script of each affected package. This is a standard npm lifecycle hook that runs automatically before a package’s dependencies are installed – meaning the malicious code executes the moment you run npm install, before you ever use the package for anything.

Here is what happens step by step once an affected package is installed:

• The preinstall script executes silently in the background during installation
• It calls npm’s OIDC token exchange endpoint and the whoami endpoint to harvest identity tokens
• It scans the environment for credentials: .env files, AWS/GCP/Azure environment variables, SSH keys, and CI/CD secrets
• It repackages a tarball (package-updated.tgz) and signs it through Sigstore to appear legitimate
• Stolen credentials are exfiltrated to attacker-controlled endpoints
• The worm then searches for other npm packages where the stolen tokens have write access and attempts to republish itself into those packages – spreading the infection further
• It also attempts privilege escalation on the host by launching containers that bind-mount the host’s /etc/sudoers.d directory, granting passwordless sudo access to CI runners

The worm also targets GitHub Actions. It searches for repositories where the stolen tokens have write permissions, inspects action.yml and action.yaml files via GraphQL, and injects malicious workflows through GitHub’s createCommitOnBranch mutation. The resulting commits appear as legitimate, verified, and signed changes – making them very difficult to detect through a normal code review.

Who Is Affected and Who Is Not

Affected:

• Anyone who ran npm install on a package from the @redhat-cloud-services namespace between approximately May 29 and June 1, 2026
• CI/CD pipelines that installed these packages during that window – even if a human never ran it directly on a VPS
• Developers and DevOps engineers who had the packages installed on their local machines and whose tokens or keys are reused on production servers
• Downstream npm packages that depend on any of the 32 compromised packages – check your full dependency tree, not just direct dependencies

Not Affected:

• VPS servers that never installed @redhat-cloud-services packages – the worm has no remote exploit capability. It cannot reach your server unless it was installed
• Python, PHP, Ruby, or other non-npm stacks – Miasma is entirely npm-specific
• Servers that only run pre-built Docker images – unless those images were built during the affected window using the compromised packages
• Projects using lockfiles that pinned versions before May 29, 2026 – if your package-lock.json or yarn.lock was committed before that date and you did not update it, you likely fetched clean versions

If you are not sure whether any of your projects ever depended on @redhat-cloud-services, the checks in the next section will tell you definitively.

How to Check If Your VPS Is Affected

SSH into your VPS and run the following checks in order. None of these commands modify anything – they are read-only scans.

Step 1: Check for the affected namespace

Search your entire filesystem for any installed @redhat-cloud-services packages:

If this returns nothing, you were not directly exposed and can stop here. If it returns any paths, continue to the next steps.

Step 2: Check your project package.json files

Search all project-level package.json files (excluding node_modules) for any reference to the namespace:

Step 3: Check for suspicious preinstall scripts

Review all preinstall hooks in your project files. Every legitimate preinstall should be something simple like only-allow pnpm – anything that calls a URL, runs a shell command fetching remote content, or references unfamiliar scripts is a red flag:

Step 4: Check for suspicious outbound connections

Look for any established connections to external IPs that you do not recognise. All your internal services (Redis, PostgreSQL, etc.) should only show ::1 or 127.0.0.1 addresses:

If you use Bun as your runtime or package manager, also check for bun processes with active external connections – Bun executes preinstall scripts the same way npm does, so the same attack surface applies:

Step 5: Check for unexpected cron jobs and sudoers changes

Miasma attempts to add persistence via privilege escalation. Check for unauthorised entries:

Step 6: Check for injected GitHub Actions workflows

If your VPS has any cloned repositories with GitHub Actions, check for recently modified workflow files:

Step 7: Run npm audit

On each Node.js project directory, run a full audit:

What to Do If You Are Affected

If any of the checks above flagged something, treat your environment as compromised and work through the following steps immediately. Do not delay – if credentials were stolen, every minute they remain valid is a risk.

1. Revoke and rotate all credentials immediately

This is the most urgent step. Rotate everything that was accessible in the compromised environment:

• npm tokens: Go to npmjs.com → Access Tokens → revoke all tokens and generate new ones
• GitHub tokens and SSH keys: Settings → Developer Settings → Personal Access Tokens → revoke all. Also audit Settings → SSH and GPG Keys
• AWS: IAM → Users → Security Credentials → deactivate and delete all access keys, generate new ones
• GCP: IAM & Admin → Service Accounts → rotate all keys
• Azure: App Registrations → Certificates & Secrets → rotate all secrets
• Any .env files: Rotate every secret, API key, and password stored in environment files visible to the affected process
• SSH keys on the server: Review ~/.ssh/authorized_keys and remove any entries you do not recognise

2. Audit and clean GitHub Actions workflows

If you found modified workflow files, review every change carefully. Look for steps that call external URLs, use curl or wget with unknown destinations, or introduce new environment variable exports. Revert any unauthorised changes and review your full git history for the affected repositories:

3. Remove the compromised packages

Remove the affected packages from your project and run a clean install:

4. Clean up any persistence mechanisms

If the worm successfully ran on your server, it may have attempted to add persistence:

5. Audit your server for further compromise

If the worm ran with access to cloud credentials or SSH keys, assume a motivated attacker may have used those credentials to gain further access. Review:

• Cloud provider access logs for your AWS/GCP/Azure accounts – look for API calls from unfamiliar IPs or at unusual times
• Server login history: last and lastb commands
• New user accounts: cat /etc/passwd | grep -v nologin
• Running processes for anything unfamiliar: ps aux
• Listening ports for unexpected services: ss -tlnp

How to Protect Yourself Going Forward

Miasma is part of a broader pattern of npm supply chain attacks that has accelerated through 2025 and 2026. The underlying tooling used in this attack has been open-sourced, meaning variants are expected. Here is how to reduce your exposure:

Lock your dependencies

Always commit your lockfile (package-lock.json, yarn.lock, or pnpm-lock.yaml) to version control and use npm ci instead of npm install in CI/CD pipelines. This installs exactly what the lockfile specifies, preventing silent version bumps to malicious releases:

Never run npm install as root

Preinstall scripts run with the same privileges as the process that calls npm. Running as root means a malicious preinstall script gets root access. Create a dedicated non-root user for Node.js processes and CI/CD operations.

Run regular audits

Use a supply chain monitoring tool

Services like Socket.dev and Snyk scan for malicious packages, suspicious preinstall scripts, and newly introduced network calls in dependencies – catching supply chain attacks before they reach your servers.

Restrict outbound network access on your VPS

A properly configured firewall that restricts outbound connections to known destinations would have stopped Miasma’s exfiltration step even if the package was installed. Consider adding outbound UFW rules:

Use least-privilege tokens in CI/CD

Never give CI/CD pipelines more permissions than they need. Use short-lived OIDC tokens instead of long-lived static secrets where possible. Scope npm tokens to publish-only for specific packages rather than granting full account access.