Red Hat npm Packages Compromised to Spread a Credential-Stealing Worm (aikido.dev) 19
Aikido Security says more than 30 official @redhat-cloud-services npm packages were compromised with a credential-stealing worm called "Miasma," a variant resembling the open-sourced Mini Shai-Hulud supply-chain malware. "The packages were published via GitHub Actions OIDC, indicating the CI/CD pipeline was compromised rather than an npm token," the report says. "If you have installed any affected package versions since June 1, 2026, treat all CI secrets, cloud credentials, SSH keys, and npm tokens as compromised and rotate them immediately." From the report: Each compromised package declares a preinstall script in its package.json that executes node index.js automatically on every npm install, before any application code runs and before the developer has any indication something is wrong. The index.js file is 4.2 MB payload hidden behind multiple layers of obfuscation.
As with previous Mini Shai-Hulud attacks, the payload performs a broad credential sweep across cloud providers, CI/CD environments, and developer tooling. On the CI side it targets GitHub Actions secrets including GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN. For cloud credentials it collects AWS access keys and session tokens, GCP application default credentials and service account key files, and Azure service principal credentials and managed identity tokens. It also sweeps for HashiCorp Vault tokens, Kubernetes service account tokens and kubeconfig files, npm and PyPI publish tokens, SSH private keys, Docker registry credentials, GPG keys, and any .env files it can find across the filesystem.
As with previous Mini Shai-Hulud attacks, the payload performs a broad credential sweep across cloud providers, CI/CD environments, and developer tooling. On the CI side it targets GitHub Actions secrets including GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN. For cloud credentials it collects AWS access keys and session tokens, GCP application default credentials and service account key files, and Azure service principal credentials and managed identity tokens. It also sweeps for HashiCorp Vault tokens, Kubernetes service account tokens and kubeconfig files, npm and PyPI publish tokens, SSH private keys, Docker registry credentials, GPG keys, and any .env files it can find across the filesystem.
Ah, what? (Score:2)
I do not understand what exactly happened here. Who messed up by getting attacked? Who messed up by trusting these people and downloading their packages without further review? Who is "@redhat-cloud-services"? Was this RHEL paid for subscribers that got hit or regular FOSS users?
Re:Ah, what? (Score:5, Informative)
From TFA:
That nugget really should've been in TFS.
Re:Ah, what? (Score:4, Insightful)
We found a Red Hat employee's GitHub account was compromised and used to push malicious orphan commits directly to several repositories, bypassing code review entirely. ...
It would be interesting to know how the account was compromised.
Re: Ah, what? (Score:2)
Thanks for the info. Shouldn't the repositories only allow to merge reviewed code though? Which can also be bypassed, but then you need two compromised accounts instead of one.
Re: (Score:1)
What a bunch of classist nonsense. It's OK if the hoi polloi get hit but not those corporate "subscribers". (The idea of even "subscribing" to Linux sucks).
Re: Ah, what? (Score:2)
He was clearly only trying to differentiate to determine the scope. Save your professional offense for an offensive situation.
Re: (Score:2)
Obviously. But the always offended cretins are not interested in facts or reality.
Re: (Score:2)
Clearly, the difference is that one group has an contractual relationship with Red Hat and paid for that, while the other does not. But you seem to be an idiot, so the difference in liability levels is probably lost on you.
Re: Ah, what? (Score:2)
Personally I find the exact question placed very interesting simply by the virtue of being the hoi polloi as well as the virtue of some people at work trying to push RHEL as something we should consider moving to.
The answer might imply two very different things to me, even though there's zerob priority implied to either user group in my mind.
If the public repos got got while enterprise didn't, then it indeed lowers appeal of the ecosystem as something I might try for my personal purposes, because it implies
I wonder about this all the time. (Score:4, Insightful)
Even if they were checked out in the beginning they can get changed at any time and no one would be the wiser.
If your site requires anything beyond what is @ (your-domain.xyz) my first question to myself is "Do I really need to figure this out" and most often the answer is No. And I am gone.
Re: (Score:1)
Re: (Score:2)
you need to be able to create proper web services with a framework language
Nah! Just do all the work on the server and ship raw html to the browser.
Re: (Score:2)
What script blocker do you use?
Re: (Score:2)
There are several that work. I think most people prefer what they are familiar with.
The main point over all is, the internet with a good script blocker is radically better than running without one.
NPM security needs to be better... (Score:3)
Any account with permission to upload packages to NPM should be required to have strong 2FA (TOTP or a hardware key of some sort or something equally secure), have session tokens that are linked to the browser/IP/device (to prevent session token theft) and maybe also require a 2FA auth before a file upload.
Although I am sure there are some who will say "that's not acceptable, we need to be able to automate things and 2FA gets in the way". Sorry but security against hackers is more important than being able to click "go" on some CI setup and have it automatically upload the new version with no human actions.