When most people picture a cyberattack, they picture someone hammering on the front door. Miasma doesn't do that. It walks in through a package you trusted, signed by a vendor you've worked with for years, and starts copying your keys before anyone notices.
This is supply chain malware. And the small business assumption that "we're too small to be a target" is the exact reason it works.
We have covered earlier incidents in this attack class, including the TanStack supply chain attack and the TeamPCP compromise. Miasma is different: it does not stop at one victim.
What Miasma actually is
Miasma is a self-replicating worm. It first surfaced on 1 June 2026, hidden inside 32 npm packages published under the @redhat-cloud-services namespace (Snyk, Upwind). Two weeks later, a variant compromised 73 Microsoft GitHub repositories across the Azure, Azure-Samples, Microsoft, and MicrosoftDocs organisations (The Hacker News, Dark Reading).
The mechanics are straightforward but nasty:
- An attacker compromises a developer's credentials.
- They publish a backdoored version of a real package, or push a malicious commit to a real repo.
- The moment a developer installs that package, or in the newer variant just opens the repo in an AI coding tool like Claude Code, Cursor, Gemini CLI, or VS Code, a credential harvester runs.
- It steals tokens for GitHub, AWS, Azure, GCP, Vault, Kubernetes, npm. Then it uses those tokens to publish backdoored versions of other packages the victim owns.
Repeat.
That last step is what earns it the "worm" label. Earlier supply chain attacks were one-shot. Miasma keeps going on its own.
There's also a specific detail worth knowing. Some variants plant a honeytoken called IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner. Revoke it the wrong way and a wiper routine runs rm -rf against the developer's home directory (Upwind, June 2026).
Why this hits small businesses harder, not less
Large companies have a security team. They have detection tools. They have someone whose job is to read CVE feeds at 7am. You probably don't.
Here's the part worth sitting with: Microsoft, Red Hat, and the Azure organisation all got hit. If they can't keep this out, the assumption that you're below the radar is fantasy. Miasma doesn't pick targets. It spreads to whoever installs the bad package.
For a small business or accounting firm, the practical risks are:
- Cloud credential theft. If your bookkeeping app runs on AWS or Azure and a developer's machine gets popped, the attacker now holds your infrastructure keys.
- Client data exposure. Accounting firms hold TFNs, bank details, payroll data. A compromised dev environment reaches all of it.
- Reputation damage that doesn't recover. Enterprise clients can absorb a breach. A 12-person firm usually can't.
The AI coding tool angle matters too. A lot of small dev teams started using Claude Code or Cursor in the last year. The newer Miasma variant doesn't need you to npm install anything. Just opening a compromised repo in your AI tool fires the payload (StepSecurity, via Dark Reading).
What to actually do
You don't need a SOC. You need three habits.
- Pin your dependencies. No
^or~ranges inpackage.jsonfor anything in production. Lockfiles committed. Dependabot or Renovate, with manual review. Not auto-merge. - Rotate tokens on a schedule, not on a panic. Most teams only rotate after they read the news. By then the worm has had the tokens for days.
- Don't open unfamiliar repos in an AI coding tool on a machine holding production credentials. Use a sandbox or devcontainer.
The supply chain isn't theoretical anymore. It's the most reliable way to compromise a small business in 2026, because it bypasses the parts you do well (firewalls, MFA on logins) and exploits the part you probably don't think about: trust in the packages and tools you already use.
If you're not sure where your real exposure sits, that's a conversation worth having before something forces it.
