16 ms·

Malicious npm packages detected across Red Hat Cloud Services

• numron-dev 4mo ago
  As a dev mostly working on Node. Those are scary title to read
• victorrpham 4mo ago
  [dead]
• jofzar 4mo ago
  'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
  • matheusmoreira 4mo ago
    All programming language package managers are vulnerable. They all have the exact same caveats as the Arch Linux User Repository. There are no trusted maintainers taking responsibility for things. Any random person can make an account and push packages.
    • the__alchemist 4mo ago
      I think this is a thought-terminating cliche, and false equivalences. Stating "This area where problems occur at a high rate is not a problem, as problems can happen elsewhere too" is a curt dismissal of a valid concern. It implies the course of action, rather than to address a high-problem area, is to ignore any solutions which aren't global, or equate it to lower-incidence areas. You bring up a good point that this class of problem, or related ones can occur with other package managers. It was frustrating how long it took the Crates.io team (Rust manager) to address name squatting, in what appeared to be a "no perfect solution exists, so we won't act" line of reasoning.
      • kalcode 4mo ago
        It's the exact same logic people used for Apple computers back in the day. The idea that Macs didn't get viruses because they were inherently more secure. But that wasn't true. It was purely a numbers game. Windows' popularity was so far off the charts that hackers naturally targeted Windows users instead of Mac users; it was just a better use of their time. The same thing is happening here. Other package managers do get compromised, but the sheer frequency of npm incidents just reflects how overwhelmingly popular Node.js and web apps are right now. JavaScript simply has a much higher usage rate than most other languages.
      • matheusmoreira 4mo ago
        It was a reply to "only package manager where this regularly happens". Anyone who thinks it can't happen to them just because they're writing Python instead of Javascript is in for a world of hurt. The comment I replied to is a literal meme. That's as charitable as it gets. Nothing "thought-terminating" about it.
    • ajross 4mo ago
      While true, tarring Arch here is a little unfair. AUR isn't enabled by default. It can't even be used via the same package front end, and in fact the "official" usage model requires that you clone the source yourself. Indeed, AUR is bad as a software distribution mechanism (really it's best understood as a proving ground for baby packages before they get real maintainers and distro blessing), but it's less bad than NPM which puts the malware in the trusted/default/automated path.
      • Ancapistani 4mo ago
        I didn’t take it that way at all - rather, Arch is the only one that does it “right” with the AUR.
        • nailer 4mo ago
          If you want a usable system, you enable AUR. It's not 'doing it right', it's avoiding responsibility.
          • antiframe 4mo ago
            Depends on who 'you' are. I have one package I installed from the AUR and it's from a corporation that just repackages their builds. The problem is always who vets the packages. I trust the Arch team and I trust that one corporation. Also to use the AUR it's a different command, so I can't get surprised by an AUR package. It's not a pacman -Syu is going to pull in a new unknown to me AUR package.
          • Ancapistani 4mo ago
            It's putting the responsibility on the party most capable and interested in evaluating the packages for security.
      • matheusmoreira 4mo ago
        I'm not tarring Arch, I was praising it. I made sure to explicitly spell out the "User Repository". Arch is the one that does it right.
    • CBLT 4mo ago
      Eh, it's worse than that. The GP comment is repeating a joke derived from an Onion headline about gun control. Where the very poignant message is about political will to make change. However, the npm ecosystem is very much willing and has already made several changes. If we're going to engage in discussion instead of meme-posting, the GP should have (imo) included real commentary _in addition to_ the meme they really wanted to post. What is the policy they want? Why do they see the NPM ecosystem as still resistant to change?
      • jauntywundrkind 4mo ago
        They didn't back up their meme with real commentary because they have no real commentary to stand on: They're spreading cheap disdain & scorn for npm ("only package manager" framing). But most other package management systems have similar abilities to run pretty un-sandboxed code. TrapDoor has hit python, rust, and js repos. https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-crates https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra...
      • gbear605 4mo ago
        One easy change would be that before any package can be published, it has to wait a minimum of two weeks in a state where it can be reviewed but it can't be installed without jumping through several hoops with big warning signs, things like "INSTALL_INTENTIONALLY_DANGEROUS_PACKAGES_THAT_WILL_BREAK_MY_COMPUTER=1", selecting yes in a dialogue that asks if they want to install software that likely has viruses, and pointing to a different package repository URL. If there's some change that must get out sooner, then there can be some fee to pay to npm to have their security team do their own review. Critically, there must be time for someone to review before it's the default to be selected. I'm sure there are issues with this, this was off my head, but it seems like a really easy step to at least stem the problem for now. And there are a bunch of ideas like this that would help, but NPM doesn't seem willing to take it seriously as an existential threat to the ecosystem, rather than taking trivial steps.
        • matheusmoreira 4mo ago
          > where it can be reviewed > Critically, there must be time for someone to review By who? No one at npm is reviewing anything. "Someone" is doing a lot of work here. Linux distributions have trusted maintainers who are responsible for their packages. People who cared enough to figure out PGP and set up an actual web of trust. That's where the verification happens. All these programming language package managers have nothing of the sort. PyPI, Rubygems, crates, npm, it doesn't matter. I can just make an account and push whatever I want. These package managers are like this because that's what developers actually want. They don't want to deal with Linux distribution maintainers in order to get their software into the official repositories. They want to just run $packager push and have it out there with zero friction.
    • throwwwll 4mo ago
      Nix enters the room. (Everyone claps.)
    • myaccountonhn 4mo ago
      It's far far harder to do something exploits like this in elm because effects are tagged. There are solutions out there.
    • saturn_vk 4mo ago
      IIRC, go cannot run arbitrary code at build time, so that should not make it vulnerable
      • matheusmoreira 4mo ago
        That changes nothing. If you're downloading packages pushed by randoms, then it's vulnerable. There is no escaping it. Go's module index is filled with people's GitHub repositories. You have no idea what's inside those things unless you review the source yourself.
      • gus_ 4mo ago
        https://www.reddit.com/r/neovim/comments/1j45stl/someone_wrote_malicious_code_in_the_neovim_plugin/ https://www.reddit.com/r/neovim/comments/1j45stl/someone_wro...
  • chuckadams 4mo ago
    The big attacks of today are spread across several package ecosystems: TrapDoor and Shai-Hulud have been hitting npm, pypi, composer, and crates with the same malware.
    • throwwwll 4mo ago
      And all of them "thought" of security as an after-after-after-after-after-thought.
      • deleted 4mo ago
        [deleted]
      • freakynit 4mo ago
        Most of these are now building upon techniques that have already been exploited since past 1 years. This attack used 4 of those techniques. 1. Lifecycle Hook Execution 2. CI/CD Identity Plane Attacks 3. Maintainer Account Takeover and Malicious Publish 4. Self-Replicating npm Worms https://npm-supply-chain-attack-techniques.pagey.site/ https://npm-supply-chain-attack-techniques.pagey.site/
        • throwwwll 4mo ago
          Regardless of what these attacks exploit, see elsewhere a larping comment of mine: the solution exists, the implementation already mitigated numerous such and other exploits (it's nice to read "nix is not affected" on discourse or over matrix chat), it predates Docker by a decade, and is older than Ubuntu and Fedora (to give the perspective), yet people prefer to remain ignorant.
          • zitterbewegung 4mo ago
            You can have a security solution but with large ecosystems like this it can’t be pushed to the ecosystem immediately and everyone will take longer to test and deploy. Right now you could audit packages and make sure you don’t get the latest version
  • ajross 4mo ago
    PyPI and Cargo are, 100%, vulnerable to this same class of compromises. That NPM sucks isn't a statement that everyone else doesn't.
  • kalcode 4mo ago
    People make this joke often. It's package managers and how loose we are with installing them, not NPM. Cargo,PyPi,Nuget,PHP has had these recent too. It's not just only NPM. It's frequently repeated here just cause of the average bias against Node. But this problem isn't isolated to NPM.
    • Defletter 4mo ago
      The problem is compounded with NPM though thanks to lifecycle scripts: yes, any and all package managers create a risk of supply-chain attack, but NPM makes it dangerous to merely open a project up in an IDE.
      • kalcode 4mo ago
        That's a good point. For me it's getting people to realize they need to take up practice that help minimize these things. It's kinda us and them problem. We need to ensure we don't just blindly install the latest, patch every CVE by just bumping everything to the latest even if the vulnerability has nothing to do with their system or use of said library. We should have rules that we install the latest that's older than three days. We should be running "npm audit" and other stuff like Trivy. The three day rule alone could save most people.
        • thaumasiotes 4mo ago
          > The three day rule alone could save most people. The three day 'rule' is just you hoping that someone else does some free work for you. If it is adopted by everyone, it has zero effect. We need rules that still work if people follow them.
          • deleted 4mo ago
            [deleted]
      • Kuinox 4mo ago
        nuget have targets, and allow to run code on build, it doesn't have this problem because there is less dependencies.
  • Someone1234 4mo ago
    Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of other security settings, like minimum age, no trust downgrade, etc etc. All attackers can attack packages by updating how a package functions; but npm is particularly problematic as it runs non-sandbox scripts as the calling user. Putting not just your project at risk, but your entire machine/network. And this stuff has been known about for YEARS, they've taken no action.
    • dns_snek 4mo ago
      > since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. This is semi-common and in no way unique to NPM.
      • Ajedi32 4mo ago
        And even in the ones that don't, having to wait until the project executes to begin its attack is a minor inconvenience for malware.
      • an0malous 4mo ago
        What other package managers do this? I don’t think Ruby does
        • matheusmoreira 4mo ago
          https://docs.ruby-lang.org/en//master/Gem.html#method-c-post_install https://docs.ruby-lang.org/en//master/Gem.html#method-c-post...
        • IshKebab 4mo ago
          Python does too I believe. Really the reason not to allow that is for robustness, not security. You ideally don't want package installs doing random stuff to your system because package authors are generally bad at doing that sort of thing cleanly. The security impact is relatively minimal because as other people have said, you just installed a package. What's the very next thing you're going to do? Compile/run it obviously.
  • TZubiri 4mo ago
    tbf this is happening with a lot of package managers now, including pypi and composer
  • deleted 4mo ago
    [deleted]
  • junon 4mo ago
    Please stop posting this on every single security incident thread with npm. It was funny once, it's just rehashing the same debate over and over.
    • da_chicken 4mo ago
      On the other hand, if the same problem keeps happening, it's hard to argue that the problem isn't foundational to the design and that it should be called out until either the problem is fixed or the design abandoned.
    • chipdale 4mo ago
      Why should they stop? Maybe they want to rehash the issue that's not being adequately addressed. Maybe it's not supposed to be funny. How do you propose we address this issue? Instead of policing what people say, are you interested in sharing your or someone else ideas?
      • junon 4mo ago
        It's not that there isn't a conversation to be had. It's that it's a low-effort, karma farming, reddit-tier comment that always invites emotional/reactionary responses, typically the same ones as before, that usually shoots to the top of the comments section and drowns out any relevant or interesting (see: curious, as per HN guidelines) discussion.
        • moi2388 4mo ago
          [flagged]
          • junon 4mo ago
            HN has guidelines about curious discussion. Read them.
    • rectang 4mo ago
      Opponents of gun control surely feel the same way about the Onion’s story.
  • nailer 4mo ago
    I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong. So, explicitly: - pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer (limited) - Maven ...all allow scripts. We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager. npm shouldn't allow scripts, but exploits happen everywhere.
    • m4rtink 4mo ago
      If DNF/RPM is used there will often be a separate distro maintainer that should ideally review any changes coming from the upstream before pulling them into the distribution. Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack. Definitely not bulletproof but still IMHO more robust than "Lets just spray latest code from upstream without any review directly to production with a firehose!" that seems to be the norm.
      • cozzyd 4mo ago
        Yes and typically updates take a while to be deployed...
      • isityettime 4mo ago
        Yeah with RPM and dpkg you're trusting the distro, or maybe individual distro maintainers, depending on how you consider it. But there are norms in the distro about what those scripts are for and how to use them, and there's some social enforcement around that. The real issue for hooks in packaging formats like those is when you start adding third-party vendor repositories, e.g., Zoom, Google Chrome, Discord. None of the social enforcement mechanisms are there and the companies behind the products I just mentioned all have histories of abusing them. That's why it's generally better to use Flatpak for things like that if your distro itself doesn't include them.
        • nailer 4mo ago
  • latexr 4mo ago
    There’s actually a blog post with that exact title. https://kevinpatel.xyz/posts/no-way-to-prevent-this/ https://kevinpatel.xyz/posts/no-way-to-prevent-this/ https://news.ycombinator.com/item?id=48155690 https://news.ycombinator.com/item?id=48155690
  • paulddraper 4mo ago
    Last 30 days: PyPI, May 11. [1] Crates.io, May 22 [2] Composer, May 22 [3] [1] https://www.tenable.com/blog/mini-shai-hulud-frequently-asked-questions https://www.tenable.com/blog/mini-shai-hulud-frequently-aske... [2] https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-crates https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra... [3] https://phoenix.security/laravel-lang-composer-supply-chain-compromise-rce-backdoor/ https://phoenix.security/laravel-lang-composer-supply-chain-...
  • tonymet 4mo ago
    Npm developers can relate to Windows being a target because it’s the most popular package manager. Why would you target xyz pkg niche manager knowing that only 200 people will install them? NPM does perform active offline & online vuln scanning on the packages. Everyone can do more, but they are going to be the #1 target.
  • xena 4mo ago
    Ask and you shall receive: https://xeiaso.net/shitposts/no-way-to-prevent-this/supply-chain/2026-redhat-javascript-clients/ https://xeiaso.net/shitposts/no-way-to-prevent-this/supply-c...
  • EGreg 4mo ago
    https://qbix.com/blog/2026/04/01/no-way-to-prevent-this-says-only-industry-where-this-regularly-happens-3/ https://qbix.com/blog/2026/04/01/no-way-to-prevent-this-says...
• buckle8017 4mo ago
  Redhat's entire reason for existence is to prevent this.
  • dada216 4mo ago
    not really, no.
    • rob_c 4mo ago
      So why else do we pay someone to package and certify/verify open source projects? This is absolutely 90++% of what should be RedHats core day job.
      • duozerk 4mo ago
        Non-profit Open Source distributions also and already package and verify open source packages (arguably often with a higher quality of analysis than Red Hat). You pay red hat for compliance reasons (availability of a support you'll never call, mostly).
        • rob_c 4mo ago
          > You pay red hat for compliance reasons You may, have you heard of docker?
  • cozzyd 4mo ago
    did RPM packages get compromised?
• dmix 4mo ago
  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/b294a6c39ee700d24073c0e5a4e93104 https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
  • phoronixrly 4mo ago
    What happens when everyone adopts this policy? You just change it to two weeks?
    • deleted 4mo ago
      [deleted]
    • Tomte 4mo ago
      You rely on the security companies scanning the packages.
      • exitb 4mo ago
        Well, if that actually works, it should be part of the release process, before the packages get placed onto the regular channels.
        • blm126 4mo ago
          I think the key right now is that these are semi-automated scanning processes. Right now, companies like step security selectively publish. So, in order for a hacking group to find out if their malware is detected or not, they have to burn access to a useful package. None of this is to say I think Microsoft shouldn't be doing something as part of the release process on NPM. However, there is real value in giving more independent third parties a window to do things semi-manually.
        • pixl97 4mo ago
          It works because there are multiple companies doing it and double checking the results. For example, is a crypto miner actually an attack? If the package presents itself as a miner, then no. Is connections to other repositories an attack? Again, depends on what the package does. Connections to some other hostname? Depends. There is still a lot of human analysis that occurs in making the call that an attack is occurring.
• freakynit 4mo ago
  Lol.. yet again npm and install-scripts abuse at play. Updated: 1. All exploitation techniques used since May 2025: https://npm-supply-chain-attack-techniques.pagey.site/ https://npm-supply-chain-attack-techniques.pagey.site/ 2. All attacks that happened since May 2025: https://npm-supply-chain-attacks-25-26.pagey.site/ https://npm-supply-chain-attacks-25-26.pagey.site/
• indy 4mo ago
  This is a completely unexpected turn of events that no one could have possibly foreseen.
• m3kw9 4mo ago
  At some point, they need a new system for these "packages", you've got to be insane to install any of these right now.
• arianvanp 4mo ago
  Given they use nx my bet is on developer laptop compromise through the nx vscode extension that also compromised GitHub engineer's laptop
  • dist-epoch 4mo ago
    the security of their packages should not depend on one laptop being compromised
    • hrpulsar 4mo ago
      [dead]
• gbuk2013 4mo ago
  I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/misc/npm.md https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)
  • twodave 4mo ago
    For smaller shops (by small I mean <1,000 employees) this isn't even tenable. We (engineering team of about 10 people) mitigate what we can via tooling and cooldown periods/minimum release age. This will work as long as these malicious packages remain reasonably detectable. I think that's the proper balance, because we can adjust the # of days we are willing to risk against the SOTA of detection tooling.
  • dboreham 4mo ago
    I think the general idea that your supply chain should be rooted in source repositories and associated commit hashes is the right one. Tooling can be made to automate the process of putting together a product from those defined sources. Some languages/systems already have some support for this. E.g. Golang and Rust. The concept of a "binary" artifact is really dead now everyone uses git and builds are quick. It lives on in things like npm and docker hub but we don't actually need it.
    • Zardoz84 4mo ago
      DUB , for D Lang does that.
  • Cthulhu_ 4mo ago
    Nothing that couldn't be automated; in Go land this is (arguably) called vendoring (https://go.dev/ref/mod#vendoring https://go.dev/ref/mod#vendoring). Good to offload or reduce dependencies on 3rd party dependency hosters, pull a dependency into your own code review tools, and to ensure reproducible builds long term.
• what_hn 4mo ago
  Same actors again?
• rvz 4mo ago
  This repository itself had to previously update from the axios supply chain attack [0] (co-authored by Claude lol). But just by looking at the change itself, the package is unpinned and won't solve the problem if another malicious security update happens again. So if you have an unpinned version of this package and you run 'npm install', you immediately downloaded the compromised version and that's that. [0] https://github.com/RedHatInsights/javascript-clients/commit/1eea0dbb509dc1c620a4c4ad8480068a80e1370a https://github.com/RedHatInsights/javascript-clients/commit/...
• general_reveal 4mo ago
  That’s why I switched to Java.
  • UqWBcuFx6NV4r 4mo ago
    …. lol
  • keyle 4mo ago
    AbstractFinalFactoryShaiHuludSerialisedFactory
    • general_reveal 4mo ago
      Yeah but you don’t have to use that I think. I think us Node people can just pretend to write Ecmascript 2 in Java and be fine.
    • exabrial 4mo ago
      https://dayssincelastjavascriptframework.com https://dayssincelastjavascriptframework.com
  • Rp8yXmdmr 4mo ago
    You are absolutely right. The dangerous part of NPM packages is the post-install script. Therefore moving from JavaScript to Java removes the threat.
    • grezql 4mo ago
      [dead]
    • OrangeMusic 4mo ago
      You joke but, yeah, when you think about it, the problem with Javascript is the 'script' part. That's actually correct.
  • mschuster91 4mo ago
    Meh maven plugins are just as juicy a target as npm is
• paulbjensen 4mo ago
  Looks like RedHat got compromised by a Black Hat…
• phishin 4mo ago
  Chainguard based images, packages and libraries are first line of defense. Expensive? Yes. Foolproof? No. I think these types services will be mandatory in the near future.
  • dralley 4mo ago
    How would that help? These are not general purpose, base system libraries, these are libraries specific to a product that uses them. Either you're not using them and hence they would not be installed in the first place, or you're using them because you have the product installed. Though I would expect that Insights uses RPM packages to ship components and not the public NPM packages.
    • SSLy 4mo ago
      it wouldn't surprise me if insights was in fact a wrapper around npm install
      • cozzyd 4mo ago
        https://access.redhat.com/articles/7139622 https://access.redhat.com/articles/7139622
• king_zee 4mo ago
  I've made it a habit now to use the --before=2026-05-30 flag when installing packages, where it'll pick the version released before the date you specify, I usually pick around 5 days ago
  • sourcegrift 4mo ago
    Yarn 4 can automate this
    • vinnymac 4mo ago
      In case others are unaware, you just have to set https://yarnpkg.com/configuration/yarnrc#npmMinimalAgeGate https://yarnpkg.com/configuration/yarnrc#npmMinimalAgeGate to the value you want. It defaults to 1 day.
    • nullsex 4mo ago
      If supply-chain security is a concern yarn is the worst js package manager you can pick. It comes far down their priority list, below "just make things work without need for user input". Whatever you thought you configured will simply be ignored many times and that's considered a feature. Go look in that projects issue tracker and commit log for changes to relevant configuration and you will know what I mean. Even yarn 1.22 is a safer choice.
  • mihaelm 4mo ago
    I just use `pnpm` and set up a liberal `minimumReleaseAge`: https://pnpm.io/settings#minimumreleaseage https://pnpm.io/settings#minimumreleaseage Thankfully, it's on by default since v11.
  • sync 4mo ago
    If using straight npm (v11.10.0 or higher), you can just add to .npmrc in the project root: min-release-age=5
  • t-sauer 4mo ago
    If you use npm 11, you can simplify your workflow by setting min-release-age to 5. https://docs.npmjs.com/cli/v11/using-npm/config#min-release-age https://docs.npmjs.com/cli/v11/using-npm/config#min-release-...
• Sudhanshu2310 4mo ago
  We have done the complete analysis and there are 32 packages share the same publishing pipeline. https://safedep.io/redhat-cloud-services-hit-by-mini-shai-hulud-npm-worm/ https://safedep.io/redhat-cloud-services-hit-by-mini-shai-hu...
• voidUpdate 4mo ago
  One thing I've never understood is why NPM allows packages to run code immediately after they are installed. What's the use case for that? A package should just be some code you can call on at runtime
  • tom1337 4mo ago
    Some packages need to build native dependencies. sharp for example needs to build libvips on the system [0] to work 0: https://github.com/lovell/sharp/blob/main/install/build.js https://github.com/lovell/sharp/blob/main/install/build.js
    • vinnymac 4mo ago
      I’ve always felt this automation shouldn’t exist at all, but should rather be selectively controlled via a hook. The hooks yarn offers out of the box for example can be used to run any code you need to after install. Putting the project owner in control instead of the dependency.
    • yread 4mo ago
      Nuget/.NET ecosystem just handles it so much better. Netvips assumes libvips is available and they provide packages for common platforms. No need to waste electricity rebuilding stuff, or install native build chains, build and test deps. Similar for Skia or Sqlite or whatever.
      • tom1337 4mo ago
        but how can you verify that the prebuilt binaries aren’t compromised?
        • voidUpdate 4mo ago
          Out of interest, do you verify that every single binary file on your machine isn't compromised? All the packages coming from your package manager?
• shrikant 4mo ago
  Oooh now I'm wondering if this may have contributed to their Docker image distribution service getting disrupted earlier today... https://status.redhat.com/incidents/jn6r256zc62c https://status.redhat.com/incidents/jn6r256zc62c
• bobkb 4mo ago
  When will npm issues stop ? This has become a big pain !
• kitd 4mo ago
  Hmm, same day as RH and IBM announce Project Lightwell to help detect and fix supply chain vulns. https://www.redhat.com/en/lightwell https://www.redhat.com/en/lightwell
  • jamietanna 4mo ago
    That was a few days ago: https://news.ycombinator.com/item?id=48313577 https://news.ycombinator.com/item?id=48313577
• tetsgima 4mo ago
  man we gotta do smth with preinstall hooks atp
• deleted 4mo ago
  [deleted]
• 0x38B 4mo ago
  [dead]
• mellosouls 4mo ago
  Should link to the original announcement I think: https://www.stepsecurity.io/blog/multiple-redhat-cloud-services-npm-packages-compromised https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...
  • nailer 4mo ago
    Yes. Also Red Hat is misspelt in the title.
• dist-epoch 4mo ago
  if RedHat is unable to secure their packages, what can we expect from mere mortals...
  • cozzyd 4mo ago
    this looks like another GitHub Actions workflow compromise... Is it really so hard for people to make releases manually?
• Havoc 4mo ago
  The entire ecosystem is cursed
  • thewebguyd 4mo ago
    Always has been. I remember poking fun at it 15+ years ago (queue the 'MongoDB is web scale' meme video).
• kittikitti 4mo ago
  I'm refactoring all my personal and research projects to utilize pure HTML/CSS without any dependency of JavaScript. This was always on the table but the cybersecurity risks from all programming languages and frameworks have increased due to AI. I know of fundamental issues with JavaScript and see no reason why it's still standard on all web browsers.
• MadrasTh0rn 4mo ago
  Fucking Microsoft
• hsibenMohamed 4mo ago
  Salam
• bpavuk 4mo ago
  Violence!
• grugdev42 4mo ago
  The joke is on you NPM! I only use CDNs for my JS libraries.
  • iconicBark 4mo ago
    Is this more secure?? I would genuinely love to know
    • bdcravens 4mo ago
      Yes, none of npm's lifecycle hooks. You're just pulling bytes over the wire.
      • runtime_terror 4mo ago
        Except now you're making http calls to remote servers that could be compromised.
        • phpdave11 4mo ago
          As long as you embed it with an SRI integrity hash, you're safe, even if the remote server is compromised.
        • bdcravens 4mo ago
          Can be mitigated, as the sibling comment points out, but even in the situation you described, the blast radius is reduced, especially for frontend libs.
        • grugdev42 4mo ago
          This is a solved problem. Use HTTPS and use the integrity attribute. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/integrity https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... Also, what's more likely? Someone hacking jsDelivr/cdnjs OR some random NPM packages getting hacked?
    • n_e 4mo ago
• insanitybit 4mo ago
  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 github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and test them, another to do any sort of publishing, signing, etc. If you use AI, add a skill / guidance to enforce this pattern. 3. If you use Github Actions, install the latest version of zizmor. It will significantly improve your posture. (2) means that you are no longer "wormable", which is a massive part of the problem that we have today. (1) gives companies more time to respond to the attacks. There are some vendors in this space that you can and should evaluate as well.
  • tmpz22 4mo ago
    > anything where code executes ALL the agentic orchestrators like codex, claude-code, etc. seem to do this by default.
    • ffemac 4mo ago
      Exactly, popular AI coding harness (OpenCode/KiloCode) downloads random npm packages in the background without you knowing. What's worse is the devs don't care.
    • sureshpaulchamy 4mo ago
      With coding agents, npm install can become a side effect of "make the tests pass." That feels like a very different risk model.
  • pixl97 4mo ago
    >install the latest version of zizmor. What if it gets compromised? More of a joke. But was funny after saying that new packages should be delayed.
    • insanitybit 4mo ago
• rochak 4mo ago
  If this is what will take for folks to move away from JS ecosystem, I'll take it.
  • renox 4mo ago
    Bah, I think that these kind of vulnerabilities exist in any "packaging ecosystem" where the base language offer "ambient authorities"(any library can access your filesystem) which is .. all of them! AFAIK only research languages do not provide these ambient authorities :-(
  • jollyllama 4mo ago
    This x1000. This is the culmination of 15 years of frontend dev culture. Why does RedHat even have an NPM repo?
  • kogasa240p 4mo ago
    Seconded
  • czbond 4mo ago
    I am not a JS dev, but had to interact with the ecosystem some. It became so bad I won't install anything without it being in a Docker or Podman container.
  • OrangeMusic 4mo ago
    I honestly don't understand how you could do JS on the backend in 2026. This language and ecosystem are so bad it's ridiculous. Almost all other options (yes, even PHP) are better. On the browser at least you have the excuse that there's no other option (hoping Wasm will eventually kill JS for good, but we're not there yet).
• anoncow 4mo ago
  This seems to be sinister
• hirra 4mo ago
  [flagged]
• lepuski 4mo ago
  Qubes offers the strongest protection against these threats. It's surprising it isn't more commonly adopted.
  • no-name-here 4mo ago
    https://qubes-os.org https://qubes-os.org
• exabrial 4mo ago
  NPM broken by design. And the NIH syndrom that runs rampant in the community wont let them do anything simple.
  • beart 4mo ago
    I don't follow your second sentence. Doesn't npm have the opposite problem of 'not invented here'? By adopting many external packages rather than developing in-house, npm projects tend to have large, complex dependency trees. It has long been the complaint that packages such as https://www.npmjs.com/package/is-windows https://www.npmjs.com/package/is-windows create potential vulnerabilities and maintenance headaches, when writing the same piece of code directly is so simple.
  • TZubiri 4mo ago
    One common fallacy of the NIH folk is that reinventing X package would take a lot of time. But first, you will of course not remake every single feature, just the one you need. And furthermore, when you code just one feature, you don't need to make any abstraction or additional function interfaces. So it's cheaper, and probably better integrated. Another fallacy is that you'll make bugs and introduce vulnerabilities. Maybe, if you are a bad programmer, but you will also avoid a category of bugs where the vuln is introduced at the boundary of the integration between two different libraries that weren't designed to fit exactly together. (Many such cases)
• throwaway613746 4mo ago
  [dead]
• majorbugger 4mo ago
  I would like to meet the person behind the "postinstall scripts" idea and try to understand how they thought it was a good idea.
  • MadrasTh0rn 4mo ago
    Y'know just to talk a little bit
• throwaway613746 4mo ago
  [dead]
• ex-aws-dude 4mo ago
  Has anyone thought of having an agent review all dependency upgrades before upgrading? I feel like that would at least catch some of these
  • asxndu 4mo ago
    This outsourcing of thinking is why such issues will continue to happen and possibly accelerate. How about simply coming up with new standards that emcure such things don't happen at all?
  • insanitybit 4mo ago
    Yes, I do this. It absolutely would catch some of these.
• Pxtl 4mo ago
  The combined features that make npm particularly vulnerable: 1) Update by default. Manually updating your package references is annoying and does lead to other security issues as you don't automatically get latest, but it makes this risk much lower. 2) Code executed on install. Statically-typed languages don't run the code until you use them, and that might not happen on the developer machine at all for first run after upgrade, it might be a lower-priv test-server. 3) Culture of many tiny modules (this is good! It's the natural way to fight NIH! Yay modularity!) means many more points-of-failure for security for this kind of attack.
• replwoacause 4mo ago
  It's becoming laughable how frequently this is happening. Wow.
• _pdp_ 4mo ago
  Why blame on NPM? Would you blame GitLab if an opensource maintainer was hacked and as a result the repo contains malicious changes? All of these recent incidents is just developers doing stupid things ... like using their compromised devices for making production changes, which is basically a big red flag to begin with. In fact, the entire situation has been exacerbated by coding agents because now practically everything happens on a single device that touches hundreds of different production systems with full production credentials.
  • gred 4mo ago
    Days since last malicious packages in NPM: 0 (evergreen) Days since last malicious packages in PyPI: 30 Days since last malicious packages in Maven: 120 I'm sure this isn't 100% accurate, and there are probably better metrics (average number of malicious packages per year, average number of developers affected per year, etc) but they aren't as easy as a quick Google News search.
    • _pdp_ 4mo ago
      Except that the JavaScript / NPM ecosystem is 6-7 times larger than Python and Java / Maven. https://chatgpt.com/share/6a1da751-0d88-832e-ace7-572bc786e097 https://chatgpt.com/share/6a1da751-0d88-832e-ace7-572bc786e0... Check the linked resource which has the actual data.
      • gred 4mo ago
        Thanks for the link. However, a 7x size differential does not fully explain a 100x security incident differential -- although I'm sure it's part of it. Some of the root causes are very hard to address (e.g. a very limited standard library which encourages dependency explosions), some are just hard (e.g. established cultural norms around version pinning and upgrades, well-established reliance on install scripts) and some are easier (e.g. small tool improvements like min-release-age). I'm personally not going to touch npm with a ten foot pole in the next year or two, but I'd love to see significant improvement, so that I have that option again in 2 or 3 years. Stay safe!
• niros_valtos 4mo ago
  [flagged]
• eranation 4mo ago
  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 attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can work, 3 days is ok, 7 days is a bit of an overkill but works too) How to set them up? - use latest pnpm, they added 1 day cooldown by default https://pnpm.io/supply-chain-security https://pnpm.io/supply-chain-security - or if you want a one click fix, use https://depsguard.com https://depsguard.com (cli that adds cooldowns + other recommended settings to npm, pnpm, yarn, bun, uv, dependabot and, disclaimer: I’m the maintainer) - or use https://cooldowns.dev https://cooldowns.dev which is more focused on, well, cooldowns, with also a script to help set it up locally All are open source / free. If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, but each of them have a way to do so (described in detail in depsguard.com / cooldowns.dev) In the past few months, while I don't have hard numbers, it seems more risk has come from Software Supply Chain attacks (malicious versions pushed) than from new zero day CVEs (even in the age of Mythos driven vulnerability discovery)
  • Normal_gaussian 4mo ago
    > If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. This feels like a very very small group of people; and people who really could do with opening the file and adding the line.
    • eranation 4mo ago
      I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers. In any funnel, each step, no matter how easy, adds friction, remove the friction and you get bigger adoption. So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :)
• wg0 4mo ago
  Question - is there no way to catch these criminals?
  • a13n 4mo ago
    It’s difficult to determine which individuals are involved and even if you manage to do that they almost certainly live in countries without extradition.
• bel8 4mo ago
  The XML extension I use in VSCode is by Red Hat. Oh dear. Here we go again.
• czbond 4mo ago
  Podman? Podman for OSX comes with a login item from "Red Hat, Inc". Anyone know how to check if this subcomponent utilizes these npms?
• Escapade5160 4mo ago
  Can someone give a tldr on why this happens so much with npm ? I can't recall seeing this with any other package manager. Is npm just the default used these days and therefore sees this more often?
• deleted 4mo ago
  [deleted]
• Surac 4mo ago
  Npm is just borked by design. I hop it will take javascrip with it
• kogasa240p 4mo ago
  Throw the JS ecosystem into the sun at this point.
• Noaidi 4mo ago
  Human society, and our technology, is a fragile system built on our hubris, a cheap replacement for the Divine Eye of Providence.
• calvinmorrison 4mo ago
  [dead]
• zeraye 4mo ago
  There is some effort to make NPM more secure https://github.com/npm/cli/pull/9360 https://github.com/npm/cli/pull/9360.
• rectang 4mo ago
  About a week ago, I uninstalled Node from my laptop, which felt great. :) I'm trying to do all work in dev containers (or other sandboxes), limiting the blast radius if I'm unlucky enough to be hit by an exploit. The attackers may get a Claude token, but they won't easily be able to escape the container and scan my home dir. Cooldowns and allow-listing of installer scripts are good additions to layered security, especially for CI. However, I think the fundamental thing that needs to change is the OS permissions model. The default of trusting third-party software with everything your user has access is no longer workable.
  • backwardsponcho 4mo ago
    Are you using something like Bubblewrap/Firejail/Flatpak, or what does such a setup look like? I've been entertaining a similar idea for a while but haven't gotten to it
    • rectang 4mo ago
      I'm using VSCode dev containers, powered by Podman on a Mac. Most people would probably choose Docker over Podman but I'm weary of Docker and wanted to try something else. I would not consider myself an expert on containers but with the help of Claude I've been able to fight my way through various challenges: * Persist a volume for Claude so that conversations don't get blown away with every container rebuild. An attacker may still be able to get a Claude token from me, which is something I'd like to tighten up in the future. * Fix file permissions issues by running rootful inside the container. (The container process still runs on the host as an ordinary user. Since my threat model is "compromised dependency scanning for credentials in project dir and home dir" rather than "attacker escaping the container", I figured that was good enough to get started.) * Work around architectural availability issues with precompiled PyPI libraries. This I punted on by choosing a different approach and eliminating the problematic dependency (by writing my hobbyist CAD 3d printing stuff using Blender extensions instead of CadQuery). I've gotten the impression that dependency compatibility with a container workflow is an ongoing challenge. * Run a database in a docker-compose sidecar for integration testing. For all the projects I'm containerizing I'm the solo dev with full control over the Git repo so I can make the call to add a `.devcontainer/devcontainer.json` config file. I haven't yet explored how to isolate projects I don't control.
• mnahkies 4mo ago
  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 others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintainer side: - MFA for publishing: https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification https://docs.npmjs.com/requiring-2fa-for-package-publishing-... - trusted publishers, available for about a year: https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/trusted-publishers And as of recently, staged publishing, essentially combining the best of both those features: https://docs.npmjs.com/staged-publishing https://docs.npmjs.com/staged-publishing Now you can: - Publish from CI, without static credentials - AND require a maintainer to approve it using MFA before it actually goes live to the registry If you want you can still use something like GitHub Actions Environments protection to require multiple approvals, or a time delay, on the CI side. We need to encourage the community to adopt these publishing protections or this will continue to be an issue.
  • selckin 4mo ago
    they need to make it required for everyone, and then they'll have done something
  • ajross 4mo ago
    IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate already-trusted upstreams for packages, it's that the upstreams cannot be trusted as the sole source for security at all. Upstreams are a bunch of hackers[1] who aren't really interested in, nor will ever be good at, solid release engineering practices. But some people are! The solution in the Linux world (and the one that saved us from xz-utils) is that there is a second level of human beings responsible for reviewing, auditing, packaging, and customizing those hacker-generated upstreams for the benefit of their users. These people have different eyes, different consumer requirements and different quality metrics. And they catch bugs and malfesance that the upstreams aren't prepared to do. NPM (and cargo/PyPI et. al.) continues to think it can short circuit this requirement for human labor. It can't. [1] In NPM's particular ecosystem, a bunch of web jockeys used to extremely fast release processes, loose compatibility requirements, and extreme reliance on reuse. This really explains why we see this with node packages more than Python or Rust: older and more conservative programmers just don't have as many rakes to step on.
• joshspankit 4mo ago
  Devs and other people who have seen behind the scenes at large companies know that most security is at best shaky and mostly hand-waved It’s not even really the fault of the people who pushed for these setups, it’s a seemingly simple business decision: build it in a way that looks secure, add some black-box process, and tell the overseers that the reason there are no attacks is because it’s bulletproof, and definitely not because no one has really tried Then, when someone finally turns their attention to you and walks in: fire whoever needs to be fired, patch that specific hole, maybe spend a bunch of money on a different system, assure the overseers that it’s handled, and move on with business as usual It’s cheaper in the long-run, it makes stockholders happy, it relieves the bosses and their bosses, and for the most part there are “no security holes”. Until now, of course
  • joshspankit 4mo ago
    Downvoters: I’m curious why
• ef2k 4mo ago
  perfect time to drop a reminder: vendoring might seem annoying, but it's way safer than trusting a remote registry.
• quantumsicarius 4mo ago
  I also commented on the other issue flagged: https://github.com/RedHatInsights/platform-frontend-ai-toolkit/issues/57 https://github.com/RedHatInsights/platform-frontend-ai-toolk... Also detonated the payload: https://leitwacht.eu/blog/valid-provenance-malicious-package https://leitwacht.eu/blog/valid-provenance-malicious-package
• deleted 4mo ago
  [deleted]
• ffemac 4mo ago
  It will only get much worse because popular AI coding harness (OpenCode/KiloCode) will just download random npm packages in the background without you knowing. And the devs don't care. Setting min age is useless if everyone is doing it. The whole point of setting min age is make someone else take the bait before you.
  • beart 4mo ago
    It isn't useless. Security researchers are the ones catching a lot of these and they will certainly not wait 3 days to inspect a package.
• ajdaughe 4mo ago
  [flagged]
• obsidianbases1 4mo ago
  Cool down sounds good until everyone does it and the issue isn't caught until afterwards
• greatgib 4mo ago
  In addition with my usual rant about the current situation with most devs that now want to use dependencies in prod almost the day that they are released, there is something else that I just realized. A big part of the problem might be attributed to Github and the modern CI/CD frameworks. Before, the source code was located somewhere, and the CI was usually located somewhere else, and slightly unrelated. At first, the CI job was to build ("privately") the artefacts, and they were manually released and deployed by maintainers and owner of software projects. Then, it became the norm to have the CI located within the VCS file and the VCS located source code controlling the CI. For example having "script"/"description" of the CI actions located within the VCS itself. Then, Github killed the CI/CD software market by offering "actions" almost for free and totally integrated within Github that was already widely used. But still, for a long time people were wary to put tokens and security keys in Github and "public" CI/CD jobs and services. And then, a few years ago, it became the gold standard also... You would look ridiculous to manually sign and deploy new releases with well guarded keys. What is expected from you is to have all your aws, github, ... secret api keys loaded in Github, and have your deployment and infrastructure provisioning automated with ("public") github accounts. All to be deployable in a second of a change being pushed. So, obviously, the moment a hacker get control of a Github account or Github API keys, it is game over for the entire infrastructure. Here I only referenced Github, but the bad things that it taught us became the norm and now these patterns are replicated everywhere (Gitlab, ...)
• bodash 4mo ago
  GitHub repo (800+ stars) on a list of tips for protecting against npm supply chain attacks: https://github.com/bodadotsh/npm-security-best-practices https://github.com/bodadotsh/npm-security-best-practices
  • TZubiri 4mo ago
    There's no magical solution, you just have to use (WAY) less dependencies
• SadErn 4mo ago
  [dead]
• photon-torpedo 4mo ago
  Red Hat security bulletin on this incident: https://access.redhat.com/security/vulnerabilities/RHSB-2026-006 https://access.redhat.com/security/vulnerabilities/RHSB-2026... Quote: > The affected packages are frontend libraries that are compiled and bundled into some container images during the Red Hat product build process. So you might be affected if you deployed any Red Hat container images built after the compromise, I guess. (I doubt anyone besides Red Hat is using the affected packages directly.)
• cyphar 4mo ago
  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't the only solution. You can use hardware keys for signing (I would wager a lot of open source maintainers have at least one Yubikey or NitroKey kicking around -- they used to give them away at conferences) and for upload tokens you can even just password-protect them or require them to log in each time. The alternative proposal with "trusted" publishing is to grant all of GitHub's automated infrastructure the ultimate authority to publish things on your behalf automatically in a way that it is shown as being more "trusted" than the developer uploading it themselves! I'm honestly surprised that it took this long for supply-chain attackers to start targeting this obvious security hole -- I doubt any user of GitHub would argue that GitHub Actions are a parogon of security, and yet the strongly recommended deployment workflow for several language communities involved bolting it into the core of your release mechanisms! I think the OCID stuff is interesting and provides some nice properties but it doesn't prove that the GHA workload is actually trusted in the sense that "trusted publishing" means. The arguments for adding speed bumps to auto-applying updates apply just as much to adding speed bumps to doing releases (arguably even more so -- even rapidly evolving libraries don't have hundreds of releases a week). Automating everything to the nth degree just expands the blast radius when stuff like this happens. I do all runc releases manually and sign them with a PGP key stored in a hardware token that requires a pin for every signature attempt. Yes, it's a bit more cumbersome but it certainly would be harder to supply-chain hundreds of projects of every maintainer would need to manually publish them. For some other projects that need to publish to crates.io or PyPI I was honestly a little dismayed at how prominently they push for "trusted" publishing and how little support there is for making the "dumb" publishing flow more secure (they even visually display such releases as less trusted, and the only way to get more green checkmarks is to let GitHub take the wheel).
• dennysora 4mo ago
  [flagged]