Multiple redhat-cloud-services npm packages compromised (StepSecurity Blog) [LWN.net]

StepSecurity is reporting that a number of npm packages in the @redhat-cloud-services scope include malware that runs automatically on every npm install:

The payload is a multi-stage credential harvester that sweeps GitHub Actions secrets along with AWS, GCP, Azure, Kubernetes, HashiCorp Vault, npm, and CircleCI tokens, and it is purpose-built to evade detection, including an explicit attempt to bypass StepSecurity Harden-Runner.

StepSecurity analyzed @redhat-cloud-services/host-inventory-client@5.0.3 in full. Its index.js, executed at install time, is 4.2 MB, a file that should weigh a few kilobytes, with the real payload buried under three separate layers of obfuscation. The malware is also a self-propagating worm: using stolen npm tokens and npm's bypass_2fa parameter, it republishes backdoored versions of other packages on its own, even against accounts protected by two-factor authentication, so every infected machine can seed the next wave with no attacker involvement. All affected packages were published via GitHub Actions OIDC from the RedHatInsights/javascript-clients repository, indicating the upstream CI/CD pipeline itself was compromised. Analysis of the remaining packages is ongoing.

A blog post from SafeDep has additional analysis about the incident. We did not find an advisory from Red Hat on this yet.

to post comments

Is this our chance to stop using NPM?

Posted Jun 1, 2026 14:52 UTC (Mon) by jpeisach (subscriber, #181966) [Link] (11 responses)

Does anybody else dislike NPM (and JavaScript)? I feel like this is a great time for us to stop using it.

Is this our chance to stop using NPM?

Posted Jun 1, 2026 15:47 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (3 responses)

The article is about RedHat compromise. NPM is owned and operated by Microsoft. You seem confused.

And even if we were to stop using NPM – where's your alternative?

Is this our chance to stop using NPM?

Posted Jun 1, 2026 18:02 UTC (Mon) by jepsis (subscriber, #130218) [Link] (1 responses)

Use pnpm instead of npm, enable the strictest security settings, and configure a reasonable release cooldown period.

Is this our chance to stop using NPM?

Posted Jun 3, 2026 0:40 UTC (Wed) by fredi@lwn (subscriber, #65912) [Link]

I like Javascript in general. However, here IMO is not the language in general as much as the fast moving changes in package managers of various languages change. And it is impossible following each of pip / pip3 / npm / upnp (jociing here) / whatever for each language, unless one has unlimited hours per day, and no real life.

Is this our chance to stop using NPM?

Posted Jun 1, 2026 23:40 UTC (Mon) by AdamW (subscriber, #48457) [Link]

It's about a compromise of upstream NPM repositories maintained by Red Hat. It's a complex situation involving multiple people, systems and companies.

Is this our chance to stop using NPM?

Posted Jun 1, 2026 15:48 UTC (Mon) by yodermk (guest, #3803) [Link] (2 responses)

Yeah, but this can be an issue with pretty much any language package repo. It's kind of a real problem, and maybe borderline insane to install the latest stuff from there on any computer with important data. Maybe a best practice is to install the latest version that has been out longer than, say, 2 months?

Is this our chance to stop using NPM?

Posted Jun 1, 2026 16:07 UTC (Mon) by zdzichu (subscriber, #17118) [Link]

There just was an article about dependency cooldowns: https://lwn.net/Articles/1068692/

Is this our chance to stop using NPM?

Posted Jun 1, 2026 18:07 UTC (Mon) by ibukanov (subscriber, #3942) [Link]

It was specifically JS that ended up with huge number of tiny packages vastly increasing the chance of compromise. I do not think it was just language popularity but specifically language features like tiny standard library and the way external modules are loaded that lead to this. Plus NPM made it too easy in retrospect to create and submit a package.

Is this our chance to stop using NPM?

Posted Jun 2, 2026 6:13 UTC (Tue) by dsommers (subscriber, #55274) [Link] (3 responses)

That is avoiding the elephant in the room.

What I've seen reported so far is just what the malware does and where and how it was found. But this can happen to any packaged product, doesn't even need to be NPM at all.

I wonder much more about HOW this malware got into the package. That is is how you add protection against such supply chain attacks like this one in the future.

Now the discussions are more about the symptoms of this issue, not the cause of the issue. And security firms brags about how they detected the malware. Detection of malware clearly is important. But it should not be the first line of defence. The first line should be to stop the malware being added as early as possible, long before the package is fully released for widespread consumption.

Is this our chance to stop using NPM?

Posted Jun 2, 2026 20:58 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

The Red Hat advisory says "a compromised GitHub account". So existing mechanisms:

- 2FA (already possible)
- branch protections (already possible)
- require signed commits (possible?)
- require signed pushes (possible?)

Is this our chance to stop using NPM?

Posted Jun 2, 2026 22:29 UTC (Tue) by dsommers (subscriber, #55274) [Link]

A compromised GH account is likely. But it might also include an API token key approach, where 2FA does not help much.

Signed commits, tags and pushes, which would need to be verified to complete a build process, is one good way. Or pulling two (or more) independent git repositories (not automatically mirrored ones) and verify branches/tags matches would be another way.

Is this our chance to stop using NPM?

Posted Jun 4, 2026 16:21 UTC (Thu) by cortana (subscriber, #24596) [Link]

According to this description:

npm binds trusted publishing to a repository plus a workflow filename, not to a branch

... making the repo the unit of trust. I celebrate NPM's bold decision to enforce the concept of Git as a distributed system of repos, rather than the centralized model favoured by enterprises of a single repo with branch protection rules...

Red Hat bulletin

Posted Jun 2, 2026 10:58 UTC (Tue) by donaldh (subscriber, #151569) [Link]

https://access.redhat.com/security/vulnerabilities/RHSB-2...