The editorial argues that the playbook for these attacks hasn't changed in years, and neither has the defense: Yarn 4's npmMinimalAgeGate and pnpm 9.x's minimumReleaseAge already exist to block freshly-published versions. The community response is exhaustion, not shock, because the mitigation is sitting unused in package managers people already run.
Openly copy-pasted his recommendation from the previous TanStack compromise thread because the advice hasn't changed: enforce a dependency cooldown window so malicious versions get caught and unpublished before they enter your builds. His top-voted comment frames this as a solved problem that teams keep refusing to adopt.
The piece explicitly frames the Red Hat compromise as the same playbook that hit axios, TanStack, and a dozen other high-profile packages in 2025 — a compromised maintainer credential or CI token followed by a malicious patch version. The argument is that singling out Red Hat misses the point; the npm publishing model itself is the vulnerability.
The submitter routed readers to StepSecurity's broader OSS security feed rather than treating this as a Red Hat-specific incident, positioning the @redhat-cloud-services compromise as one entry in an ongoing stream of npm supply-chain attacks tracked across the ecosystem.
The editorial highlights that Red Hat and IBM announced Project Lightwell — pitched as helping enterprises detect supply-chain vulnerabilities — the same day the @redhat-cloud-services compromise broke. It treats the collision of the press release and the compromise notice as a pointed commentary on enterprise security marketing versus operational reality.
Spotted the Project Lightwell announcement within minutes of the compromise thread going up and surfaced it in the HN discussion, making the juxtaposition impossible to miss. His comment crystallized the irony that the same vendor pitching supply-chain remediation tooling was simultaneously the victim of a supply-chain attack.
On June 2, 2026, StepSecurity flagged multiple compromised npm packages published under the `@redhat-cloud-services` scope. The affected packages are part of Red Hat's JavaScript clients ecosystem — the libraries that power Red Hat Insights, the Hybrid Cloud Console, and a chunk of the customer-facing tooling that ships inside paying enterprise Red Hat subscriptions. The GitHub issue (RedHatInsights/javascript-clients#492) is now the canonical tracking thread, and it climbed to 748 points on Hacker News within hours.
The attack vector follows the now-familiar pattern: a maintainer account or CI token gets compromised, the attacker publishes a new patch version with malicious post-install or runtime code, and the package propagates through transitive dependencies before anyone notices. Red Hat has not yet published a full post-mortem, but the StepSecurity feed indicates the malicious versions were live long enough to be pulled into downstream builds. This is the same playbook that hit axios, the TanStack ecosystem, and at least a dozen other high-profile packages in 2025 — only the logo on the package scope changes.
There's a darkly funny coincidence sitting on top of all this. The same day this broke, Red Hat and IBM jointly announced Project Lightwell, a new initiative pitched as helping enterprises detect and remediate software supply chain vulnerabilities. Commenter `kitd` on the HN thread spotted it within minutes. The press release and the compromise notice are now competing for the same SEO real estate.
The community response in the HN thread isn't shock. It's exhaustion, with a side of practical advice. The top comment, from `eranation`, openly copy-pasted from the previous compromise thread (TanStack) because the recommendation hasn't changed: use a dependency cooldown. Yarn 4 ships `npmMinimalAgeGate`. pnpm 9.x ships `minimumReleaseAge`. Both refuse to install any package version that's less than N days old (typical setting: 2–3 days). The mechanism is dumb and effective — by the time you're allowed to install a poisoned version, the security community has usually already yanked it.
Every major npm supply chain compromise in the last 18 months has been detected and removed within 1–3 days of publication. That's the entire window of exposure. A two-day cooldown closes it. The objection — "but what about urgent CVE patches?" — turns out to be mostly theoretical: critical CVEs that require sub-24h patching are rare, and when they exist, you override the cooldown manually for that specific package. The default-deny posture catches the supply-chain attacks; the manual override catches the CVE emergencies. You get both.
The second class of mitigation that came up repeatedly: `npm install` runs arbitrary code. So does `npm test`. So does anything that touches `node_modules`. Commenter `insanitybit` made the obvious-but-rarely-implemented point that install and test steps should run in environments with no credentials, no cloud metadata access, and no write access to anything outside the project directory. CI runners that have AWS keys, GitHub PATs, and npm publish tokens sitting in env vars are doing the attacker's lateral movement for them. Most teams know this. Almost no teams enforce it.
The third thread — pnpm vs npm vs yarn culture wars — is mostly noise, but there's a real signal underneath it. `mnahkies` pushed back on the snark that frames this as an npm-specific failure. It isn't. PyPI has had typo-squats and dependency confusion attacks. crates.io has had compromised crates. Go modules at least benefit from immutable versions and the module proxy, but the broader ecosystem-level problem — that any maintainer account compromise becomes a build-system compromise for thousands of downstream consumers — is universal. The difference between ecosystems isn't whether they get attacked; it's whether the tooling makes the obvious defenses ergonomic. pnpm and Yarn 4 made cooldowns a one-line config. npm itself still hasn't shipped a built-in equivalent.
If you're running a Node.js codebase in production and you do not have a dependency cooldown configured, this is the action item: configure one this week. The Yarn 4 incantation is `enableHardenedMode: true` plus `npmMinimalAgeGate: 2d` in `.yarnrc.yml`. For pnpm, it's `minimumReleaseAge=2880` (minutes) in `.npmrc` or the equivalent in `pnpm-workspace.yaml`. Neither setting requires changing a single line of application code, and both close roughly 90% of the supply-chain attack surface that has been actively exploited in 2025.
If you're stuck on npm proper, the workarounds are uglier but exist: `npm install --ignore-scripts` blocks the post-install code execution path that most of these attacks rely on, at the cost of breaking packages that legitimately need install scripts (sharp, esbuild, native bindings). Combine it with an allowlist for the handful of packages you actually need scripts for. It's not as clean as a cooldown, but it raises the bar significantly.
The Red Hat customers reading this have a more specific question: what's actually in the affected versions, and do my Insights deployments need to be torn down and rebuilt? At time of writing, the issue thread is still being updated with the full list of affected packages and the specific malicious behavior. If you have any Red Hat Insights client code in your dependency tree, audit your lockfiles for versions published in the last 72 hours, pin to a known-good prior version, and rotate any credentials those builds had access to. The compromised versions are being unpublished as they're identified, but lockfiles freeze the bad versions in place — `npm audit` will not save you here.
The interesting question isn't whether the next npm compromise happens — it will, probably within weeks. The question is whether the registry itself eventually grows the defenses that the package managers have bolted on. npm's parent (GitHub, owned by Microsoft) has the leverage to make 2FA mandatory for all publishers, to enforce a default publication delay on the registry side, and to require signed provenance for any package that wants to claim a verified badge. They've shipped pieces of this — npm provenance and Sigstore integration exist — but adoption is voluntary and most maintainers haven't opted in. Until the defaults change at the registry layer, the burden stays on every individual consumer to configure their package manager defensively. Red Hat just paid the tuition. Pay attention to the lesson before your scope is the one in the StepSecurity feed.
In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair.There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and other
I'll be honest, I have always found the "trusted" publishing concept quite suspect -- the boiled-down argument is that developers are too incompetent to manage their own keys. Yes, there are obviously problems with storing plaintext publishing keys and tokens in $HOME, but that isn&#x
Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days).https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
Just some suggestions:1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs.2. Anywhere you have `npm install` or `npm test` or anything where code executes, that should happen in an environment that has no privileges. In your
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised):I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain a