Red Hat npm Packages Compromised to Spread a Credential-Stealing Worm (aikido.dev)
(Monday June 01, 2026 @05:00PM (BeauHD)
from the red-alert dept.)
- Reference: 0183544132
- News link: https://it.slashdot.org/story/26/06/01/1624228/red-hat-npm-packages-compromised-to-spread-a-credential-stealing-worm
- Source link: https://www.aikido.dev/blog/red-hat-npm-packages-compromised-credential-stealing-worm
Aikido Security says more than 30 official @redhat-cloud-services npm packages were [1]compromised with a credential-stealing worm called "Miasma ," a variant resembling the open-sourced [2]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.
[1] https://www.aikido.dev/blog/red-hat-npm-packages-compromised-credential-stealing-worm
[2] https://www.aikido.dev/blog/mini-shai-hulud-is-back-tanstack-compromised
> 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.
[1] https://www.aikido.dev/blog/red-hat-npm-packages-compromised-credential-stealing-worm
[2] https://www.aikido.dev/blog/mini-shai-hulud-is-back-tanstack-compromised
I wonder about this all the time. (Score:3)
by oldgraybeard ( 2939809 )
I use script blocker and it is amazing what commercial sites allow to run on their sites. 10-20-30 or more 3rd party libraries doing god knows what.
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:2)
by oldgraybeard ( 2939809 )
I use script blocker -> I use a script blocker
Re: (Score:2)
by PPH ( 736903 )
> 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)
by subreality ( 157447 )
What script blocker do you use?
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:
> 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. Those orphan commits contained a workflow file (ci.yaml) and a script (_index.js).
That nugget really should've been in TFS.
Re: (Score:3)
> 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: (Score:1)
Was this RHEL paid for subscribers that got hit or regular FOSS users?
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.