16 ms·

Shai-Hulud Returns: Over 300 NPM Packages Infected

• fny 10mo ago
  I find it unbelievable that npm still doesn't upgrade integrity entries to SHA512 across the board. This seems like such a simple hole to plug. What gives?
• vintagedave 10mo ago
  Serious question: should someone develop new technologies using Node any more? A short time ago, I started a frontend in Astro for a SaaS startup I'm building with a friend. Astro is beautiful. But it's build on Node. And every time I update the versions of my dependencies I feel terrified I am bringing something into my server I don't know about. I just keep reading more and more stories about dangerous npm packages, and get this sense that npm has absolutely no safety at all.
  • sublinear 10mo ago
    The list of affected packages are all under namespaces pretty much nobody uses or are subdependencies of junk libraries nobody should be using if they're serious about writing production code. I'm getting tired of the anti-Node.js narrative that keeps going around as if other package repos aren't the same or worse.
    • pxc 10mo ago
      The only way a worm like this spreads is usage of the affected packages. The proliferation itself is clear evidence of use.
    • DJBunnies 10mo ago
      Ok, I'll bite; which package repos are "the same or worse" than those of nodejs?
      • cluckindan 10mo ago
        All of them. The issue at hand is not limited to a specific language or tool or ecosystem, rather it is fundamental to using a package manager to install and update 3rd party libraries.
    • macNchz 10mo ago
      I see a bunch under major SaaS vendor namespaces that have millions of weekly downloads…?
      • sublinear 10mo ago
        Popular junk is still junk
    • rlpb 10mo ago
      You need to explain how one is supposed to distinguish and exclude "namespaces pretty much nobody uses" when writing code in this ecosystem. My understanding is that a typical Node developer pretty much has no control over what gets pulled in if they want to get anything done at all. If that's the case, then you don't have an argument. If a developer genuinely has no control, then the point is moot.
      • sublinear 10mo ago
        How is this situation any different from any other ecosystem? I think you don't have an argument here other than that npm is a relatively large public repository. Bad actors and ignorant developers are everywhere else too. There are plenty of npm features to help assess packages and prevent unintended updates, but nothing replaces due diligence.
        • rlpb 10mo ago
          Debian does not excuse security compromises by saying "oh nobody uses that far corner of our repository anyway".
  • sph 10mo ago
    It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a cambrian explosion of dependencies to be a very good idea security-wise. Ambivalent about Go: they have a semblance of packaging system, but nothing so reckless like allowing third-party tarballs uploaded in the cloud to effectively run code on the dev's machine.
    • fouronnes3 10mo ago
      Surely in this case the problem is a technical one, and with more work towards a better security model and practices we can have the best of both worlds, no?
    • dotancohen 10mo ago
      Historically, arguments of "it's popular so that's why it's attacked" have not held up. Notable among them was addressing Windows desktop security vulnerabilities. As Linux and Mac machines became more popular, not to mention Android, the security vulnerabilities in those burgeoning platforms never manifested to the extent that they were in Windows. Nor does cargo or pip seem to be infected with these problems to the extent that npm is.
      • mschuster91 10mo ago
        > Nor does cargo or pip seem to be infected with these problems to the extent that npm is. Easy reason. The target for malware injections is almost always cryptocurrency wallets and cloud credentials (again, mostly to mine cryptocurrencies). And the utter utter majority of stuff interacting with crypto and cloud, combined with a lot of inexperienced juniors who likely won't have the skill to spot they got compromised, is written in NodeJS.
      • whizzter 10mo ago
        Compared to the JS ecosystem and number of users both Python and Rust are puny, also the the NPM ecosystem also allowed by default for a lot of post-install actions since they wanted to enable a smooth experience with compiling and installing native modules (Not entirely sure how Cargo and PIP handles native library dependencies). As for Windows vs the other OS's, yes even the Windows NT family grew out of DOS and Win9x and tried to maintain compatiblity for users over security up until it became untenable. So yes, the base _was_ bad when Windows was dominant but it's far less bad today (why people target high value targets via NPM,etc since it's an easier entry-point). Android/iOS is young enough that they did have plenty of hindsight when it comes to security and could make better decisions (Remember that MS tried to move to UWP/Appx distribution but the ecosystem was too reliant on newer features for it to displace the regular ecosystem). Remember that we've had plenty of annoyed discourse about "Apple locking down computers" here and on other tech forums when they've pushed notarization. I guess my point is that, people love to bash on MS but at the same time complain about how security is affecting their "freedoms" when it comes to other systems (and partly MS), MS is better at the basics today than they were 20-25 years ago and we should be happy about that.
  • dkdbejwi383 10mo ago
    Node itself is still fine and you can do a lot these days without needing tons of library. No need for axios when we have fetch, there's a built-in test runner and assertion library. There are some things that kind of suck (working with time - will be fixed by the Temporal API eventually), but you can get a lot done without needing lots of dependencies.
  • Gigachad 10mo ago
    The problem isn't specific to node. NPM is just the most popular repo so the most value for attacks. The same thing could happen on RubyGems, Cargo, or any of the other package managers.
    • vintagedave 10mo ago
      The concern is not 'could' happen, but _does_ happen. I know this could occur in many places. But where it seems highly prevalent is NPM. And I am genuinely thinking to myself, is this making using npm a risk?
      • cluckindan 10mo ago
        Just use dependency cooldown. It will mitigate a lot of risk.
        • yoavm 10mo ago
          If you started your Node project yesterday, wouldn't that mean you'd get the fix later?
          • cluckindan 10mo ago
            Obviously you bypass the cooldown to fix critical issues.
          • flexd 10mo ago
            no, because if you used dependency cooldown you wouldn't be using the latest version when you start your project, you would be using the one that is <cooldown period> days/versions old edit: but if that's also compromised earlier... \o/
      • Ygg2 10mo ago
        NPM is the largest possible target for such an attack. Attack an important package, and you can get into the Node and Electron ecosystem. That's a huge prize.
  • anonymous908213 10mo ago
    Node doesn't have any particular relation to NPM? You don't have to download 1000 other people's code. Writing your own code is a thing that you are legally allowed to do, even if you're writing in Javascript.
    • AIorNot 10mo ago
      So your supposed to write your own posthog? be serious
      • dkdbejwi383 10mo ago
        If they have a HTTP API using standard authentication methods it's not that difficult to create a simple wrapper. Granted a bit more work if you want to do things like input/output validation too, but there's a trade-off between ownership there and avoiding these kinds of supply-chain attacks.
        • jacquesm 10mo ago
          > Granted a bit more work if you want to do things like input/output validation too, A bit? A proper input validator is a lot of work.
          • dkdbejwi383 10mo ago
            If you aim for 100% coverage of the API you're integrating with, sure. But for most applications you're going to only be touching a small surface area, so you can validate paths you know you'll hit. Most of the time you probably don't need 100% parity, you need Just Enough for your use-case.
            • jacquesm 10mo ago
              That's an excellent way to get bitten.
              • 10mo ago
  • paradite 10mo ago
    There's only two kind of technologies. The ones that most people use and some people complain about, and the ones that nobody uses and people keep advocating for.
    • monooso 10mo ago
      This a common refrain on HN, frequently used to dismiss what may be perfectly legitimate concerns. It also ignores the central question of whether NPM is more vulnerable to these attacks than other package managers, and should therefore be considered an unreasonable security risk.
      • deleted 10mo ago
        [deleted]
  • jacquesm 10mo ago
    > Serious question: should someone develop new technologies using Node any more? Please, no. It is an absolutely terrible eco system. The layercake of dependencies is just insane.
    • cluckindan 10mo ago
      Node the technology can be used without blindly relying on the update features of npm. Vet your dependency trees, lock your dependency versions at patch level and use dependency cooldown. This is something you also need to do with package managers in other languages, mind you.
      • jacquesm 10mo ago
        If everybody in your country drives on the right side of the road you could theoretically drive on the left. But you won't get very far like that. People use Node because of the availability of the packages, not the other way around.
        • cluckindan 10mo ago
          That’s not a very good analogy. Doing what I suggested is not illegal and doesn’t prevent you from using packages from npm. It’s more akin to due diligence: before driving, you check that your car is safe to drive. At the gas and service station, you choose the proper fuel, proper lubricants and spare parts from a reputable vendor which are appropriate for your car.
          • jacquesm 10mo ago
            Nobody - and I mean absolutely nobody - using Node.js has fully audited all of the dependencies they use and if we find somewhere in a cave a person that did that they are definitely not going to do it all over again when something updates.
            • cluckindan 10mo ago
  • sandruso 10mo ago
    You can go very far with just node alone (accepts typescript without tsc, has testing framework,...). Include pg library that has no dependencies. Build a thin layer above node and you can have pretty stable setup. I got burnt so many times that I think it is simply impossible to build something that won't break within 3 months if you start including batteries. When it comes to frontend, well I don't have answers yet.
    • viraptor 10mo ago
      You can write simple front-end without reactive components. Most pages are not full blown apps and they were fine for a very long time with jQuery, whose features have been largely absorbed into plain js/dom/CSS.
  • zwnow 10mo ago
    Just keep the number of packages you use to a minimum. If some package itself has like 200 deps uninstall that and look for an alternative with less deps or think if you really need said package. I also switched to Phoenix using Js only when absolutely necessary. Would do the same on Laravel at work if switching to SSR would be feasible... I do not trust the whole js ecosystem anymore.
    • jacquesm 10mo ago
      Did Phoenix not require npm at some point or is that not true?
      • allanmacgregor 10mo ago
        At the beginning, but not anymore. You still have the option to pull libraries and packages but is not really required by default.
        • jacquesm 10mo ago
          Oh that's great news I will have to look at it again then. That was a huge turn-off for me, to take one of the most well respected and reliable eco systems and then to pull in one of the worst as a dependency. Thank you for clearing that up.
  • rvz 10mo ago
    > Serious question: should someone develop new technologies using Node any more? I think we have given the Typescript / Javascript communities enough time. These sort of problems will continue to happen regardless of the runtime. Adding one more library increases the risk of a supply-chain attack like this. As long as you're using npm or any npm-compatible runtime, then it remains to be an unsolved recurring issue in the npm ecosystem.
  • weregiraffe 10mo ago
    Building websites =/= Developing new technologies.
    • fragmede 10mo ago
      Yup! No new technologies have been invented or discovered thru building websites since CSS 1.0 in 1996.
      • reconnecting 10mo ago
        Even worse! We lost <FRAME> along the way.
  • reconnecting 10mo ago
    We chose to write our platform for product security analytics (1) with PHP, primarily because it still allows us to create a platform without bringing in over 100 dependencies just to render one page. I know this is a controversial approach, but it still works well in our case. "require": { "php": ">=8.0", "ext-mbstring": "*", "bcosca/fatfree-core": "3.9.1", "phpmailer/phpmailer": "6.9.3", "ruler/ruler": "0.4.0", "matomo/device-detector": "6.4.7" } 1. https://github.com/tirrenotechnologies/tirreno https://github.com/tirrenotechnologies/tirreno
    • embedding-shape 10mo ago
      Not sure what the language has anything to do with it, we've built JavaScript applications within pulling in 100s of NPM packages before NPM was a thing, people and organizations can still do so today, without having to switch language, if they don't want to. Does it require disciple and a project not run by developers who just learned program? You betcha.
      • reconnecting 10mo ago
        I might say that every interpreter has a different minimum dependency level just to create a simple application. If we're talking about Node.js, there's a long list of dependencies by default. So yes, in comparison, modern vanilla PHP with some level of developer discipline (as you mentioned) is actually quite suitable, but unfortunately not popular, for low-dependency development of web applications.
        • embedding-shape 10mo ago
          > If we're talking about Node.js, there's a long list of dependencies by default. But that's not true? I initialize a project locally, there is zero dependencies by default, and like I did five years ago, I can still build backend/frontend projects with minimal set of dependencies. What changed is what people are willing/OK with doing. Yes, it'll require more effort, obviously, but if you want things to be built properly, it usually takes more effort.
  • skwee357 10mo ago
    I’m not a node/js apologist, but every time there is a vulnerability in NPM package, this opinion is voiced. But in reality it has nothing to do with node/js. It’s just because it’s the most used ecosystem. So I really don’t understand the argument of not using node. Just be mindful of your dependencies and avoid updating every day.
    • shortrounddev2 10mo ago
      it's interesting that staying up to date with your dependencies is considered a vulnerability in Node
      • bichiliad 10mo ago
        Having a cooldown is different from never updating. I don’t think waiting a few days is a bad security practice in any environment, node or otherwise.
        • vrighter 10mo ago
          But only if most of everyone else doesn't do so.
      • skwee357 10mo ago
        People who live on the edge of updates always risk vulnerabilities and incompatibility issues. It’s not about node, but anything software related.
    • Aperocky 10mo ago
      It has everything to do with node/js. Because the community believes in tiny dependencies that must be updated as often as possible and the tooling reflects that belief.
  • throwawayffffas 10mo ago
    Just lock your packages to patch versions, make sure to use versions that are at least a week old. And maybe don't update your dependencies very often.
  • matheusmoreira 10mo ago
    It's not just npm, you should also not trust pypi, rubygems, cargo and all the other programming language package managers. They are built for programmers, not users. They are designed to allow any random untrusted person to push packages with no oversight whatsoever. You just make an account and push stuff. I have no doubt you can even buy accounts if you're malicious enough. Users are much better served by the Linux distribution model which has proper maintainers. They take responsibility for the packages they maintain. They go so far as to meet each other in person so they can establish decentralized root of trust via PGP. Working with the distributions is hard though. Forming relationships with people. Participating in a community. Establishing trust. Working together. Following packaging rules. Integrating with a greater dynamic ecosystem instead of shipping everything as a bloated container whose only purpose is to statically link dynamic libraries. Developers don't want to do any of that. Too bad. They should have to. Because the npm clusterfuck is what you get when you start using software shipped by totally untrusted randoms nobody cares to know about much less verify. Using npm is equivalent to installing stuff from the Arch User Repository while deliberately ignoring all the warnings. Malware's been found there as well, to the surprise of absolutely no one.
    • doug713705 10mo ago
      There are far too many languages and many packages for each of them for this (good) idea to be practicable.
  • jimbohn 10mo ago
    If I had to bet, the most likely and pragmatic solution will be to have dependencies cooldown and that's it
    • creata 10mo ago
      If everyone does it, then it becomes less effective, because there'd be fewer early testers to experience and report issues, no?
      • jimbohn 10mo ago
        Yes, it's gonna be heuristics all way down. This problem isn't solved formally but the ecosystem(s) having these issues are too big to be discarded "just" because of that.
  • taleodor 10mo ago
    If you're looking for practical recommendations how to work with npm maintaining reasonable safety expectations, my post here mostly covers it: https://worklifenotes.com/2025/09/24/npm-has-become-a-russian-roulette/ https://worklifenotes.com/2025/09/24/npm-has-become-a-russia...
  • jollyllama 10mo ago
    Hell no. You need standalone dependencies, like Tailwind offers with its standalone CLI. Predators go where there prey is. NPM is a monoculture. It's like running Windows in the 90's; you're just asking for viruses. But 90% of frontend teams will still use NPM because they can't figure anything else out.
  • Cthulhu_ 10mo ago
    Node is fine, the issue lies in its package model and culture: * Many dependencies, so much you don't know (and stop caring) what is being used. * Automatic and regular updates, new patch versions for minor changes, and a generally accepted best practice of staying up to date on the latest versions of things, due to trauma from old security breaches or big migrations after not updating for a while. * No review, trust based self-publishing of packages and instant availability * untransparent pre/postinstall scripts The fix is both cultural and technological: * Stop releasing for every fart; once a week is enough, only exception being critical security reasons. * Stop updating immediately whenever there's an update; once a week is enough. * Review your updates * Pay for a package repository that actually reviews changes before making them widely available. Actually I think the organization between NPM should set that up, there's trillion dollar companies using the Node ecosystem who would be willing and able to pay for some security guarantees.
    • dboreham 10mo ago
      Microsoft owns npmjs.com. They could pay for AI analysis of published version deltas, looking for backdoors and malware.
  • shevy-java 10mo ago
    You have this issue with ALL external code though. npm/node and javascript overall may exacerbate this problem, but you have it with any other remote repository too - often without even noticing it unless you pay close attention; see the xz-utils backdoor, it took a while before someone noticed the sneaky payload. So I don't think this works as a selective filter against using node, if you have a use case for it. Take ruby - even before when a certain corporation effectively took over RubyCentral and rubygems.org, almost two years ago they also added a 100.000 download limit. That is, after that threshold was passed, the original author was deprived of the ability to remove the project again - unless the author resigns from rubygems.org. Which I promptly did. I could not accept any corporation trying to force me into maintaining old projects (I tend to remove old projects quickly; the licence allows people to fork it, so they can maintain it if they want to, but my name can not be associated with outdated projects I already abandoned, since newer releases were available. The new corporate overlords running rubygems.org, who keep on lying about "they serve the community", refused to accept this explanation, so my time came to a natural end at rubygems.org. Of course this year it would be even easier since they changed the rules to satisfy their new corporate overlords anyway: https://blog.rubygems.org/2025/07/08/policies-live.html https://blog.rubygems.org/2025/07/08/policies-live.html)
    • Yokohiii 10mo ago
      You forget to account for the fact that the xz-utils backdoor was extremely high effort. Literally a high skilled person building trust over time. While it's obviously possible and problematic, it's still a scaling/time issue.
  • littlecranky67 10mo ago
    Professionally I am a fulltime FE Dev using Typescript+React. My Backends for my side projects are all done in C#, even so I'd be fluent in node+typescript for that very reason. In a current side project, my backend only has 3 external package dependencies, 2 of which are SQLite+ORM related. The frontend for that sideproject has over 50 (React/Typescript/MaterialUI/NextJS/NX etc.)
    • noveltyaccount 10mo ago
      .NET being so batteries-included is one of its best features. And when vulnerabilities do creep in, it's nice to know that Microsoft will fix it rather than hoping a random open source project will.
  • WorldMaker 10mo ago
    I've started to feel it is much more an npm problem than a node problem. One of the things I've started leaning on more is prioritizing packages from JSR [0]. JSR is a part of Deno's efforts, so is often easiest to use in Deno packages, but most of the things with high scores on JSR get cross-published to npm and the few that prefer JSR only there's an alright JSR bridge to npm. Of course using more JSR packages does start to add more reason to prefer Deno to Node. Also, there are still some packages that are deno.land/x/ only (sort of the first version of JSR, but no npm cross-compatibility) worth checking out. For instance, I've been impressed with Lume [1], a thoughtful SSG that's sort of the opposite of Astro in that it iterates at a slow, measured pace, and doesn't try to be a kitchen sink but more of workbench with a lot of tools easy to find. It's deno.land/x/ only for now for reasons I don't entirely agree with but I can't deny that JSR can be quite a step up in publishing complexity for not exactly obvious gain. [0] https://jsr.io/ https://jsr.io/ [1] https://lume.land/ https://lume.land/
  • venturecruelty 10mo ago
    Serious answer: no.
  • knowitnone3 10mo ago
    Node and npm are not the same things. I'm not even a developer. You're seriously a developer?
  • deleted 10mo ago
    [deleted]
  • willtemperley 10mo ago
    > Serious question: should someone develop new technologies using Node any more? Serious answer: no. I think I'm going to just use a static site generator, maybe add some WASM modules built with a language that has a sane package manager and enjoy my life instead of getting involved with this cluster of a show.
  • 0manrho 10mo ago
    Npm has been a shit show from day 1. Unfortunately, Industry momentum and vc funded "fail fast, fail often" is a hell of a drug. EDIT: Coffee hasnt kicked in yet, that was harsher than I intended. For what it's worth, it's not specifically/solely NPM/nodes fault, more of a convergance of the above and the ecosystem/users just as much as any of the Node/NPM devs/maintainers in combination with it having such a large attack cross section. Even if it had a reputation for being bulletproof and secure as fuck there's still such a large userbase with huge potential if exploited that'd it'd almost assuredly inevitably be compromised from time to time regardless. While I feel we could use a whole lot less javascript on the web (client and server side both), without a competitor or something, it's shear size ensures any such expliot/issue gets amplified 1000x versus nearly any other project save for maybe major OS's and Browsers themselves.
  • serial_dev 10mo ago
    Couldn't similar issues happen with Rust, Python, Dart, C#, Java, Ruby? Supply chain attacks are not unique to Node / NPM. I'm sure the list of available attacks are somewhat different, but you can get pwned in all of these ecosystems.
• julius-fx 10mo ago
  The list of affected packages is concerning - indeed.
• timgl 10mo ago
  co-founder of PostHog here. We were a victim of this attack. We had a bunch of packages published a couple of hours ago. The main packages/versions affected were: - posthog-node 4.18.1, 5.13.3 and 5.11.3 - posthog-js 1.297.3 - posthog-react-native 4.11.1 - posthog-docusaurus 2.0.6 We've rotated keys and passwords, unpublished all affected packages and have pushed new versions, so make sure you're on the latest version of our SDKs. We're still figuring out how this key got compromised, and we'll follow up with a post-mortem. We'll update status.posthog.com with more updates as well.
  • spiderfarmer 10mo ago
    If we don't know how it got compromised, chances are this attack is still spreading?
  • brabel 10mo ago
    If anything people should use an older version of the packages. Your newest versions had just been compromised, why should anyone believe this time and next time it will be different?!
    • timgl 10mo ago
      The packages were published using a compromised key directly, not through our ci/cd. We rolled the key, and published a new clean version from our repo through our CI/CD: https://github.com/PostHog/posthog-js/actions/runs/19630358112/job/56210138138 https://github.com/PostHog/posthog-js/actions/runs/196303581...
      • progbits 10mo ago
        Why do you keep using token auth? This is unacceptable negligence these days. NPM supports GitHub workflow OIDC and you can make that required, disabling all token access.
        • timgl 10mo ago
          Yep, we are moving to workflow OIDC as the next step in recovery.
• rvz 10mo ago
  Very concerning, so that was what the "impending disaster" was as I first noted. [0] Quite worrying that this happened again to the NPM ecosystem. Really looking forward to a deeper post-mortem on this. [0] https://news.ycombinator.com/item?id=46031864 https://news.ycombinator.com/item?id=46031864
  • jacquesm 10mo ago
    It will keep happening until someone takes responsibility and starts maintaining the whole of the node eco system. This is probably a viable start-up idea: Node but audited.
    • notpachet 10mo ago
      Maybe we can convince Shopify to hijack NPM too while they're at it.
    • venturecruelty 10mo ago
      You don't even need to enshittify Yet Another Service, you just need package maintainers. Debian manages to do this, and I'm guessing they get paid nothing (although, yeah, Amazon and The Goog really ought to chip in a few bucks, considering their respective empires). Unfortunately, it means you can't just YOLO your code into other people's programs anymore.
      • jacquesm 10mo ago
        > Unfortunately, it means you can't just YOLO your code into other people's programs anymore. That's a good thing, in my book.
        • venturecruelty 10mo ago
          Oh, agreed 100%. I find it endlessly frustrating that these same conversations happen every single time there's a supply chain attack like this, because nobody wants an _actual_ solution, they want an _easy_ solution that doesn't involve changing anything about how they work. So we just get 500 comments asking if we can solve the Halting Problem, and then everyone forgets until the next breach. It was ever thus.
• spiderfarmer 10mo ago
  Will the list of affected packages expand? How were these specific packages compromised in the first place?
• gonepivoting 10mo ago
  We're monitoring this activity as well and updating the list of affected packages here: https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-... Currently reverse engineering the malicious payload and will share our findings within the next few hours.
• westoque 10mo ago
  a concern i have is that it's only a matter of time before a similar attack is done to electron based apps (which also have packages installed using npm). probably worse because it's installed in your computer and can potentially get any information especially given admin privileges.
  • hedora 10mo ago
    I'd really like to know how signal deals with this. It's supposedly super secure + stuff, but it's built on top of this ecosystem.
    • venturecruelty 10mo ago
      They probably don't willy-nilly install every new patch that comes down the pike?
  • chasd00 10mo ago
    I’m starting an electronjs project in a few weeks and have been reading up on it. They make a big deal about the difference between the main and renderer processes and security implications. The docs are there and the advice given but it’s up to the developers to follow them. That leads me to another point. Devs have to take responsibility for their code/projects. Everyone wants to blame npm or something else but, as software developers, you have to take responsibility for the systems you build. This means, among may other things, vetting code your code depends on and protecting the system from randomly updating itself with code you haven’t even heard about.
• vintagedave 10mo ago
  The list of packages looks like these are not just tiny solo-person dependencies-of-dependencies. I see AsyncAPI and Zapier there. Am I right that this seems quite a significant event? AsyncAPI is used as the example in the post. It says the Github repo was not affected, but NPM was. What I don't understand from the article is how this happened. Were the credentials for each project leaked? Given the wide range of packages, was it a hack on npm? Or...?
  • throw-the-towel 10mo ago
    My understanding is, it's a worm that injects itself into the current package and publishes infected code to npm.
  • merelysounds 10mo ago
    There is an explanation in the article: > it modifies package.json based on the current environment's npm configuration, injects [malicious] setup_bun.js and bun_environment.js, repacks the component, and executes npm publish using stolen tokens, thereby achieving worm-like propagation. This is the second time an attack like this happens, others may be familiar with this context already and share fewer details and explanations than usual. Previous discussions: https://news.ycombinator.com/item?id=45260741 https://news.ycombinator.com/item?id=45260741
    • vintagedave 10mo ago
      Thanks. I saw that sentence but somehow didn't parse it. Need a coffee :/
    • tasuki 10mo ago
      I don't get this explanation. How does it force you to run the infection code? Yes, if you depend on an infected package, sure. But then I'd expect not just a list, but a graph outlining which package infected which other package. Overall I don't understand this at all.
      • merelysounds 10mo ago
• I_am_tiberius 10mo ago
  I guess you should never use the latest versions of libraries.
  • sublinear 10mo ago
    Not sure if you're serious, but if so I agree that people should take the time to set up their own package mirrors. Not just for npm but all other package managers as well. This is why it's so important to get to know what you're actually building instead of just "vibing" all the time. Before all the AI slop of this decade we just called it being responsible.
    • moebrowne 10mo ago
      How does having a mirror help?
      • sublinear 10mo ago
        Maintaining a package mirror is a shared responsibility beyond just the software dev teams. The packages and their publishers need to be approved to be added to the mirror, testing needs to occur, and updates are delayed until the newer version is added to the mirror. The network team would block npm and force all machines to use this mirror. All this would have mitigated this incident in the event that an npm install was done during the window of this update being rolled out and unpatched. The npm install would continue as normal on the last known good version and the newer vulnerable version would simply not exist on the mirror.
    • prmph 10mo ago
      Exactly, there is no easy solution to these problems. The solutions that are effective also involve actually doing work, as developers, library authors, and package managers. But no, we want as much "convenience" as possible, so the issues will continue. Developers and package authors should use a lockfile, pin their dependencies, be frugal about adding dependencies, and put any dependencies they do add through a basic inspection at least, checking what dependencies they also use, their code and tests quality, etc. Package managers should enforce namespacing for ALL packages, should improve their publishing security, and should probably have an opt-in verified program for the most important packages. Doing these will go a long way to ameliorate these supply chain attacks
• darkamaul 10mo ago
  The "use cooldown" [0] blog post looks particularly relevant today. I'd argue automated dependency updates pose a greater risk than one-day exploits, though I don't have data to back that up. That's harder to undo a compromised package already in thousands of lock files, than to manually patch a already exploited vulnerability in your dependencies. [0] https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns https://blog.yossarian.net/2025/11/21/We-should-all-be-using...
  • jacquesm 10mo ago
    But even then you are still depending on others to catch the bugs for you and it doesn't scale: if everybody did the cooldown thing you'd be right back where you started.
    • woodruffw 10mo ago
      The assumption in the post is that scanners are effective at detecting attacks within the cooldown period, not that end-device exploitation is necessary for detection. (This may end up not being true, in which case a lot of people are paying security vendors a lot of money to essentially regurgitate vulnerability feeds at them.)
    • falcor84 10mo ago
      I don't think that this Kantian argument is relevant in tech. We've had LTS versions of software for decades and it's not like every single person in the industry is just waiting for code to hit LTS before trying it. There are a lot of people and (mostly smaller) companies who pride themselves on being close to the "bleeding edge", where they're participating more fully in discovering issues and steering the direction.
    • vintagedave 10mo ago
      That worried me too, a sort of inverse tragedy of the commons. I'll use a weeklong cooldown, _someone else_ will find the issue... Until no-one does, for a week. To stretch the original metaphor, instead of an overgrazed pasture, we grow a communally untended thicket which may or may not have snakes when we finally enter.
• tomaytotomato 10mo ago
  Could npm adopt a reverse domain naming system similar to Java's for Maven libraries? com.foo.bar That would require domain verification, but it would add significant developer friction. Also mandatory Dune reference: "Bless the maker and his water"
  • KomoD 10mo ago
    I don't see how this solves the problem?
  • ramon156 10mo ago
    I was thinking something similar to cargo-audit, because domain names don't really fix anything here
  • chasd00 10mo ago
    Some MFA requirement to publish a new version of the package would be a good idea. In me experience releasing a new version of software is a big enough deal that the product owner is on hand to authorize the release via a separate device no matter how automated the pipeline is.
• amiga386 10mo ago
  "No Way To Prevent This" Says Only Package Manager Where This Regularly Happens
  • AndroTux 10mo ago
    Okay then, tell me a way to prevent this.
    • blueflow 10mo ago
      The same way it always has been done - vendor your deps.
      • hu3 10mo ago
        that's what I do whenever feasible. Which is often
      • sph 10mo ago
        To be fair this does only work in ecosystems where libraries are stable and don't break every 3 months as it often happens on the JS world. You can vendor your left-pad, but good luck doing that with a third-party SDK.
        • CGamesPlay 10mo ago
          ... you vendor the third-party SDK? Nobody worth working with is breaking their SaaS APIs with that cadence.
      • joshstrange 10mo ago
        That literally makes no difference at all. You’ll just vendor the malicious versions. No, a lock file with only exact versions is the safe path here. We haven’t seen a compromise to existing versions that I know of, only patch/minor updates with new malicious code. I maintain that the flexibility in npm package versions is the main issue here.
        • 10mo ago
• mittermayr 10mo ago
  I always (very naively, I fully get it) wonder if someone at GitHub could take a minute and check the logs (if there are any at this level) from a week ago or so and scan them for patterns? The code seems to grab a few files off of GitHub, use Github actions, etc. -- perhaps there's a pattern in there that shows the attacker experimenting and preparing for this? I assume most people at this level have VPNs and so forth, but I'd never underestimate the amount of bad luck even those folks can have. Would be interesting, I know I'd have a look, if those logs existed.
  • hofrogs 10mo ago
    That's usually what those security companies do, they monitor all those repositories and look for patterns, then investigate anything suspicious.
  • not_doctorq 10mo ago
    I have first hand knowledge that they do, or at least that the data exists and can be queried in that way, but it’s a game of cat and mouse.
• wolfi1 10mo ago
  the left-pad fiasco seems to have been the only time npm changed a policy and reacted to a security problem, since then it seems that supply chain attacks just belong to the npm-eco-system
• inesranzo 10mo ago
  If the JS ecosystem continues like this, we're Duned.
• kome 10mo ago
  why don't web devs just learn html and css properly, and maybe xslt for the really complex transformations then use vanilla js only when it's truly necessary? instead we've got this absolute mess of bloated, over-engineered junk code and ridiculously complicated module systems.
  • vorticalbox 10mo ago
    the issue is not that devs don't know what they are its that they don't pin packages if you run `npm i ramda` it will set this to "ramda": "^0.32.0" (as of comment) that ^ means install any version that is a feature or patch. so when a package is released with malware they bump version 0.32.1 and everyone just installs it on next npm i. pinning your deps "ramda": "0.32.0" completely removes the risk assuming the version you listed is not infected. the trade off is you don't get new features/patches without manually changing the version bump.
    • christophilus 10mo ago
      > the trade off I see that as a desirable feature. I don’t want new functionality suddenly popping into my codebase without one of my team intending it.
      • vorticalbox 10mo ago
        me too but a lot of people see it as massive overhead they don't want to deal with. personally i pin all mine because if you don't a version could be deployed during a pipeline and this makes your local version not the same as the one in docker etc. pinning versions is the only way to be sure that the version I am running is the same as everyone elses
    • dboreham 10mo ago
      For context: ramada 0.32.0 isn't a concrete thing, in the sense that glibc 2.35 is. It really means "the latest ramada code because if you were to pin on this version it'll at some point stop working". glibc 2.35 never stops working.
  • 10mo ago
• jhancock 10mo ago
  containerize all the things...Nix, Podman, Docker. It's not a big hassle once you get through the initial steps. Would be good to see projects (like those recently effected) nudging devs to do this via install instructions.
  • christophilus 10mo ago
    Yep. This is what I do. I edit and run my code in a container. That container cannot access my ssh keys or publish to GitHub. I review all changes, and manually commit / publish on my host. It’s not perfect, but that plus vendoring my dependencies goes a long way towards mitigating these kinds of things.
• jz10 10mo ago
  Funny coincidence reading this while in the middle of rewatching Dune 2 on Netflix
  • throwawayffffas 10mo ago
    My guy what are you doing on HN. Put down the phone and watch the movie.
    • ghthor 10mo ago
      Second screen experience
• throwawayffffas 10mo ago
  > Upon execution, the malware downloads and runs TruffleHog to scan the local machine, stealing sensitive information such as NPM Tokens, AWS/GCP/Azure credentials, and environment variables. That's a wake up call to harden your operations. NPM Tokens, AWS/GCP/Azure credentials have no reason to be available in environments where packages may be installed. The same goes for sensitive environment variables.
  • junon 10mo ago
    That's the goal, but it's not feasible in e.g. professional settings. Much easier said than done, unfortunately.
    • codedokode 10mo ago
      My code editor works in a sandbox. It's difficult because Linux doesn't provide it and one has to write it manually using shell scripts, random utilities. For example, I had also to write a limited FUSE emulation of /proc to allow code editor work without access to real /proc which contains lot of unnecessary information. And if it's a "professional" setting, the company could hire a part-time developer for writing the sandbox.
      • junon 10mo ago
        Good luck selling that to thousands of managers. That's my point. It's easy to list things that should be done. It's harder to get them greenlit.
      • bartmr 10mo ago
        could you share with us those utilities? I've tried doing the same with AppArmor, but I ended up having endless warnings and weird bugs.
        • codedokode 10mo ago
          I am using bwrap - it allows blocking network, creating a new process namespace (so that sandboxed program cannot mess with host processes) and creating a new filesystem, where you can mount host directories. I only pass through minimal set of directories like /usr and /lib, and only selected files from /etc, as they can contain valuable information. I also pass through several device files like /dev/null, but not the whole /dev. I do not pass through /proc, as it contains not only information about processes (which is not a concern), but a lot of identifying information about a machine. However, lot of modern software due to poor coding and not following standards crashes or exhibits various bugs without /proc, so I wrote a minimal Python /proc emulator using FUSE: https://pastebin.com/s49V5nVL https://pastebin.com/s49V5nVL . /proc doesn't allow bind mounting its subdirectories somewhere else, so the only option was FUSE (or writing a kernel module). As you see, with Linux you learn something new every day, like it or not. The emulator is not perfect - it doesn't expose thread information, and, for example, Grand Central Dispatch library [1] terminates the application because of this. Telegram is using the library and crashes randomly because of this. I expected better quality from Apple and Swift. Most importantly, I run the app as a different user (Android-style), because historically Linux was built around idea of protecting users from each other, and I don't trust namespaces as much. I clear the environment variables as well. Ideally, I should also be closing file descriptors to prevent leaks (for example, you can easily leak a file descriptor to your Wayland server, Dbus or something else). To use Xorg, I grant access to the app's user. X server has no issues with sharing access to it. I am not sure if one can use Wayland with different users (is uses unix sockets). Pipewire doesn't allow its use by different users, so I have to add a pipewire-pulse plugin listening on localhost, and configure ALSA inside sandbox to connect to that pulseaudio server. Obviously, the app in sandbox has no direct access to audio devices in /dev. Dbus is also necessary to display tray icons, but you should never grant direct access to it because it is almost like giving the root password. I use xdg-dbus-proxy [2] which I had to patch because originally it only supported running the sandboxed app under the same user. You can still find my patch in open pull requests. I also did some experimentation with passing through a camera through a fake video4linux device, so that the app cannot know the real camera model, but it is not working great, for example, Gnome Cheese app cannot see it, because it needs not only a kernel device, but something more to detect cameras. The sandbox cannot use hardware acceleration. It would be not easy to add because every GPU vendor uses its own directories and device files, /sys entries to interact with the hardware and I think you can get the full list only by reverse engineering. Furthermore, I am not sure if it is safe. This setup is not perfect, and looks like a bunch of random utilities glued with shell scripts (which is not uncommon in Linux world). If I had more time, I would write something better, that can dynamically add and revoke privileges, can provide fake serial numbers and even emulate a working network which sadly loses 100% of sent packets. I looked into using Flatpak, but they seem to grant full access to /sys, /proc and generally I don't feel that they care much about protection from malware and fingerprinting by legitimate software. Also, as I understand, they run the app as the same user which is not secure. Probably their primary goal is making installation easier but not making the use of software safer. I am not going to use Docker because it officially says that it is not a security tool. [1] https://github.com/swiftlang/swift-corelibs-libdispatch https://github.com/swiftlang/swift-corelibs-libdispatch [2] https://github.com/flatpak/xdg-dbus-proxy https://github.com/flatpak/xdg-dbus-proxy
• jhancock 10mo ago
  Is there a terminal AI assistant that doesn't have heaps of depenedancies and preferably no node? Claude and codex both require node. I'm a fan of the lightweight octofriend. But also node. I do not like installing node on systems that otherwise would not require it.
  • gspr 10mo ago
    llama.cpp?
    • ashirviskas 10mo ago
      Does it have a terminal assistant that I have not heard of? Otherwise, the parent asks about an assistant that is able to run various tools and stuff, not just talk.
  • ashirviskas 10mo ago
    You can install codex without npm if you build it yourself, they have migrated to rust in June and npm is just a convenient install wrapper it seems. Just `git clone git@github.com:openai/codex.git`, `cd codex-rs`, `cargo build --release` (If you have many cores and not much RAM, use `-j n`, where n is 1 to 4 to decrease RAM requirements)
• amitassaraf 10mo ago
  There are actually hundreds more NPM packages infected, see here: https://www.koi.ai/incident/live-updates-sha1-hulud-the-second-coming-hundred-npm-packages-compromised https://www.koi.ai/incident/live-updates-sha1-hulud-the-seco...
  • hrudham 10mo ago
    You don't provide any more information, and are promoting your own site here without even saying so despite your name being on the About page. This felt like clickbait.
• yourapostasy 10mo ago
  GitHub back in September already published their roadmap of mitigations to NPM supply chain attacks: https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/ https://github.blog/security/supply-chain-security/our-plan-... I'm guessing no one yet wants to spend the money it takes for centralized, trusted testing where the test harnesses employ sandboxing and default-deny installs, Deterministic Simulated Testing (DST), or other techniques. And the sheer scale of NPM package modifications per week makes human in the loop-based defense daunting, to the point that only a small "gold standard" subset of packages that has a more reasonable volume of changes might be the only palatable alternative. What are the thoughts of those deep inside the intersection of NPM and cybersecurity?
  • dboreham 10mo ago
    You would need to hear the thoughts of those deep inside the intersection of money and money.
• codedokode 10mo ago
  Does NPM use any automatic scanners? Just scanning for eval/new Function/base64 and other tokens often used by malware, and requiring a manual review, could already help. Also package manager should not run scripts.
  • tmvnty 10mo ago
    Not aware of any NPM native ways but here are few community tools: - https://socket.dev/blog/introducing-socket-firewall https://socket.dev/blog/introducing-socket-firewall - https://github.com/lirantal/npq https://github.com/lirantal/npq - https://bun.com/docs/pm/security-scanner-api https://bun.com/docs/pm/security-scanner-api source: https://github.com/bodadotsh/npm-security-best-practices?tab=readme-ov-file#4-preinstall-preventions https://github.com/bodadotsh/npm-security-best-practices?tab...
  • amiga386 10mo ago
    Static scanning won't help. You can write this["eval"]() instead of eval(), therefore you can write this["e" + "v" + "a" + "l"](), and you can substitute (!![]+[])[!+[]+!+[]+!+[]] for "e", (![]+[])[+!+[]] for "a" (and so on: https://jsfuck.com/ https://jsfuck.com/) In this Turing-equivalent world, you can only know what actually executes (e.g. eval, fetch) by actually executing all code in the package and then see what functions got executed. Then the problem is the same as virus analysis; the virus can be written to only act under certain conditions, it will probe (e.g. look at what intepreter fingerprints, get the time of day, try to look at innocuous places in filesystem or network, measure network connection times, etc), so that it can determine it is in a VM being scanned, and go dormant for that time. So the only thing that actually works is if node and other JS evaluators have a perfect sandbox, where nothing in a module is allowed (no network, no filesystem) except to explicit locations declared in the module's manifest, and this is perfectly tracked by the language, so if the module hands back a function for some other code to run, that function doesn't inherit the other code's network/fs access permissions. This means that, if a location is not declared, the code can't get to it at scanning time nor install time nor any time in the future. This still leaves open the door for things like a module defining GetGoogleAnalyticsURL(params) that occasionally returns "https://badsite.com/copyandredirect?ga= https://badsite.com/copyandredirect?ga=...", to get some other module to eventually make a credential-exfiltrating network call, even if it's banned from making it directly or indirectly...
• prmph 10mo ago
  There is no easy solution to these problems. The solutions that are effective also involve actually doing work, as developers, library authors, and package managers. But no, we want as much "convenience" as possible, so the issues continue. Developers and package authors should use a lockfile, pin their dependencies, be frugal about adding dependencies, and put any dependencies they do add through a basic inspection at least, checking what dependencies they also use, their code and tests quality, etc. Package managers should enforce namespacing for ALL packages, should improve their publishing security, and should probably have an opt-in verified program for the most important packages. Doing these will go a long way to ameliorate these supply chain attacks.
  • Yokohiii 10mo ago
    I think if you generally depend on npm packages, being frugal is hard, because every random package works against you. Last time my perception was also that publishing sec is a weak point. If at least heavily used packages would be forced to do manual security steps for publishing, it would help quite a bit as long the measures a safe.
  • venturecruelty 10mo ago
    There absolutely is an easy solution to these problems, and Linux has been doing it forever: package maintainers. Don't treat your repository like a superfund site, and it won't fill up with garbage.
    • zahlman 10mo ago
      That solution is not easy, and as stated it takes work. And there is a serious problem of funding people to do that work. And it has not yet been demonstrated at PyPI/NPM scale, either.
• qbane 10mo ago
  `--ignore-scripts` should be the default behavior.
• exceptione 10mo ago
  My motto wrt language choices: "It's the standard lib, stupid!" My ultra hot take: there are only¹ two² programming ecosystems suitable for serious³ work: - .net (either run on CLR or compile as an AOT standalone binary) - jvm The reason why is because they have a vast and vetted std lib. A good standard lib is a bigger boost then any other syntactic niceties. __ 1. I don't want other programming languages to die, so I am happy if you disagree with me. Other valid objection: some problems are better served by niche languages. Still, both .net and java support a plethora of niche languages. 2. Shades of gr[e|a]y, some languages are more complete out of the box than others. 3. cf «pick boring tools»
  • querez 10mo ago
    Arguably both Go and Python also have great stdlibs. The only advantage that JVM and .NET have is a default GUI package. Which is fair, but keeps getting less and less relevant as people rely more on web UIs.
    • BrouteMinou 10mo ago
      .Net has Blazor for WebUI. I don't ask you to judge if you like it, I'm just saying that you can totally make a professional WebUI within the dotnet stdlib.
    • exceptione 10mo ago
      Respectfully disagree. Python and Go std lib do not even play in the same league. I had to help someone with datetime¹ handling in Python a while back. The stdlib is so poor, you have to reach out for a thirdparty lib for even the most basic of tasks². Don't take my word for it, take a dive. You wouldn't be the first to have adjust their view. For example, this section is just about the built-in web framework asp.net: https://learn.microsoft.com/en-us/aspnet/core https://learn.microsoft.com/en-us/aspnet/core ______ 1. This might be a poor example as .net has NodaTime and the jvm has YodaTime as 3rd-party libs, for if one has really strict needs. Still, the builtin DateTime constructs offer way more than what Python had to offer. 2. Don't get me started on the ORM side of things. I know, you don't have to use one, but if you do, it better does a great job. And I wouldn't bat an eye if the ORM is not in the standard, but boy was I disappointed in Python's ecosystem. EF Core come batteries included and is so much better, it isn't fun anymore.
• bodash 10mo ago
  I compiled a list of NPM best practices one can adopt to reduce supply chain attack risks (even if there's no perfect security preventions, _always_): https://github.com/bodadotsh/npm-security-best-practices https://github.com/bodadotsh/npm-security-best-practices Discussion on HN last time: https://news.ycombinator.com/item?id=45326754 https://news.ycombinator.com/item?id=45326754
  • giantg2 10mo ago
    Do you know of anything similar for pip?
    • bodash 10mo ago
      Most of the best practices can be translated to python ecosystem. It’s not exact 1:1 mapping but change few key terms and tools, the underlying practices should be the same. Or copy that repo’s markdown into an llm and ask it to map to the pip ecosystem
      • giantg2 10mo ago
        Yeah, was mostly interested in the tooling.
    • kernc 10mo ago
      No.1: Run untrusted code in a sandbox! https://github.com/sandbox-utils/sandbox-venv https://github.com/sandbox-utils/sandbox-venv
  • herpdyderp 10mo ago
    For anyone publishing packages for others to use: please don't pin exact dependency versions. Doing so requires all your users to set "overrides" in their own package.json when your dependencies have vulnerabilities.
  • btbuildem 10mo ago
    I have a shorter list of NPM best practices: 1. Don't
• deanc 10mo ago
  I see a bunch of postman packages vulnerable. Does that mean the desktop application is compromised (oof)?
  • stepquiet 10mo ago
    Postman posted a blog entry about the event: https://blog.postman.com/engineering/shai-hulud-2-0-npm-supply-chain-attack/ https://blog.postman.com/engineering/shai-hulud-2-0-npm-supp... "Our security engineering team is investigating the matter and thus far has concluded that while some public Postman NPM packages were infected, (1) Postman as an app is not compromised, and (2) our production cloud services are also not compromised."
• wiz21c 10mo ago
  Once again, you cannot ask the open source world to provide you with free dependencies and security. At some point, someone has to pay for an organisation whose job will be to review the contents of all of these modules. Maybe one could split the ecosystem into "validated" and "non validated" stacks ? much like we have stable and dev branches ? The people validating would of course give their own identity to build trust. And so, companies (moral person) should do that.
• BrouteMinou 10mo ago
  I was going to tell my team that we didn't hear about a NPM supply chain attack for about 2 weeks and that we should celebrate. I guess it's not going to happen...
• rishabhaiover 10mo ago
  Why can't package managers enforce attestations backed by a transparent log for each commit made to a public repository?
  • hashstring 10mo ago
    They can, but what does it solve? If a malicious package gets pushed, who or what is the equivalent of the CA that you are you going to nuke?
    • rishabhaiover 10mo ago
      I was working with the assumption in this model the attestation is signed by ephemeral keys (OIDC) which would reveal the bad actor or give breadcrumbs. Enough to reduce incentives to hijack packages.
  • dboreham 10mo ago
    They can but that wasn't done in this case and isn't commonly done for various reasons.
• benob 10mo ago
  How was the attack detected in the first place?
• das_keyboard 10mo ago
  Slightly OT, but who is HelixGuard? The website is a mess (broken links, broken UI elements, no about section) There is no history on webarchive. There is no information outside of this website and their "customers" are crypto exchanges and some japanese payment provider. This seems a bit fishy to me - or am I too paranoid?
  • bhouston 10mo ago
    Based in Singapore / Japan according to X: https://x.com/HelixGuard_ai https://x.com/HelixGuard_ai
  • gooob 10mo ago
    same thing i was thinking lol
• nautilus12 10mo ago
  If you always run npm inside of docker does that pretty much prevent attacks like this?
  • mfro 10mo ago
    Docker is not a sandbox. There is some work that can be done to harden it, but you're better off looking at genuinely sandboxing your dev environment
    • ashishb 10mo ago
      What is genuine sandboxing? Everyone waives there hands by saying this
      • mfro 10mo ago
        Good question with a lot of possible answers. You can take sandboxing as far as you want, really. I typically just use bubblewrap (linux)
        • ashishb 10mo ago
          I have a perfect set up in inside docker that works. I would love to know why bubblewrap is a superior alternative. Here's mine https://github.com/ashishb/dotfiles/blob/067de6f90c72f0cf849fb6edcd941b347712ced9/bashrc_includes/custom_aliases.bash#L19-L21 https://github.com/ashishb/dotfiles/blob/067de6f90c72f0cf849...
          • mfro 10mo ago
            My understanding is that docker escapes are not all that difficult, and your aliases really aren’t doing much to harden the container. but I am not an expert on the matter. I’m sure there is plenty of info online
            • ashishb 10mo ago
• efortis 10mo ago
  Mitigate this attack vector by adding: ignore-scripts=true to your .npmrc https://blog.uxtly.com/getting-rid-of-npm-scripts https://blog.uxtly.com/getting-rid-of-npm-scripts
  • herpdyderp 10mo ago
    Also add it to ~/.npmrc!
    • hedora 10mo ago
      So, I do this because it's universally recommended, but why does it help? Can't they just jam the malware into the package itself? It runs with the same permissions on my machine (in unit tests, node servers, etc).
      • herpdyderp 10mo ago
        > why does it help? Because install scripts are being actively exploited, so blocking them will reduce your exposure. Install scripts will also run anywhere that runs npm ci, npm install, etc., including build pipelines. > Can't they just jam the malware into the package itself Yes. Disabling install scripts won't safeguard you from all attack vectors.
      • efortis 10mo ago
        Yes, if the malware is injected in the application code this doesn’t prevent it. But in some cases it could help for that. For instance, if the package runs in the browser and the payload requires file-system access, etc., then the attack can’t execute in the browser. And if in addition it was added to a life-cycle script, it would be mitigated. At any rate, it’s worth having `ignore-scripts=true` because NPM life-cycle scripts are a common target (e.g., this one targets `preinstall`).
• darnthenuggets 10mo ago
  Both of these attacks have used trufflehog. Is there an out of the box way to block that executable by name or signature?
  • jamietanna 10mo ago
    I'd say an alternative question is "how can we stop storing secrets in source control" so then tools like Trufflehog can't find them :)
• dboreham 10mo ago
  Here's the underlying problem: let's imagine someone very smart. They figure out a way to solve this problem. They are not going to make any money by doing so. That's why we have this problem.
  • nullbio 10mo ago
    You're right, that is the underlying problem. Not only of this, but of our entire economy.
• scottcorgan 10mo ago
  Thought this was about the band ...
• k__ 10mo ago
  Maybe, we have to rethink depencies from the ground up. Implementing everything yourself probably won't cut it. Copying a dependency into your code base and maintaining it yourself probably won't yield much better results. However, if a dependency would be part of the version control, depends could at least do a code review before installing an update. That wouldn't help with new dependencies, that come in with issues right from.the start, but it could help preventing new malware from slipping in later. A setup like that could benefit from a crowd-sourced review process, similar to Wikipedia. I think, Nimble, the package manager of Nim, uses a decentralised registry approach based on Git repos. Something like that could be a good start.
• rglover 10mo ago
  This is a good sign that it's time to get packages off of NPM and come up with an alternative. For those who haven't heard of or tried Verdaccio [1], it may be an option. Relatively easy to point at your own server via NPM once you set it up. [1] https://verdaccio.org/ https://verdaccio.org/
  • hedora 10mo ago
    I've had decent luck running it locally, but claude keeps screwing up the cool-down settings in my monorepo. This is probably a common problem. Has anyone gotten verdaccio to enforce cool-down policies? I also waste a ton of time because post-install scripts are disabled. Being able to cut them off from network access, and just run a local server with 2-4 week cool-down would help me sleep better at night + simplify the hell out of my build.
• abhisek 10mo ago
  Documenting technical details and payload analysis here: https://safedep.io/shai-hulud-second-coming-supply-chain-attack/ https://safedep.io/shai-hulud-second-coming-supply-chain-att... Like previous variant, it has credential harvesting, self-replication and GitHub public repository based exfiltration. Double base64 encoded credentials being exposed using GitHub repositories: https://github.com/search?q=%22Sha1-Hulud%3A%20The%20Second%20Coming%22&type=repositories https://github.com/search?q=%22Sha1-Hulud%3A%20The%20Second%...
• jackconsidine 10mo ago
  Used the following script to see if I had any affected packages: https://gist.github.com/considine/2098a0426b212f27feb6fb3b4d714660 https://gist.github.com/considine/2098a0426b212f27feb6fb3b4d... It checks yarn.lock for any of the above. Maybe needs a tweak or two but you should be able to run from a directory with yarn.lock
• ChicagoDave 10mo ago
  I’m looking for info on whether MalwareBytes would catch this and not finding anything.
• Yokohiii 10mo ago
  https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/ https://github.blog/security/supply-chain-security/our-plan-... So github has some tools available to mitigate some of the problems tied to it. Probably not perfect for all use cases. But considering the current scale, it doesn't seem to have any effect, as enough publishers seem not to care. I think npm should force higher standards on popular packages.
• AmazingTurtle 10mo ago
  I looked through some of the GH repositories and - dear god - there are some crazy sensitive secrets in there. AWS Prod database credentials, various API keys (stripe, google, apple store, ...), passwords for databases, encryption keys, ssh keys, ... I think hijacked NPM packages are just the tip of the ice berg.
  • deleted 10mo ago
    [deleted]
• kunley 10mo ago
  Why the biggest package mess is always with the Node ecosystem? Why in particular this community still insists on preemptively updating all deps always, on running complicated extra hooks together with package installation and pretending this all is good engineering practices? ("Look, we have so plenty of things and are so busy, thus it must be good") Why certain kind of mindset is typical to this community? Why the Node creator abandoned his creation years ago? Why, oh why?
  • jalapenos 10mo ago
    Feels good, just for a second, to type pretence you're above everyone doesn't it? Just for those few seconds, you're better than a big whole arbitrary collection of people, and for those few seconds you have relief from the reality of your life.
    • kunley 10mo ago
      No. I am tired of seeing people dragged into poor quality environments for the wrong reasons. These people would do much better using other tools. Your attempt to make it personal does not compute.
    • venturecruelty 10mo ago
      Well it certainly doesn't feel good to get your shit pwned every two weeks.
    • int_19h 10mo ago
      The reality of my life is that I have to write code targeting Node because of choices that other people made for their libraries and products. I didn't hate JS & npm with a passion before. I do now, and it hasn't even been two years.
  • deleted 10mo ago
    [deleted]
  • sph 10mo ago
    Node is the new PHP: massive ecosystem, enormous mind share, and made up for a large part by programming newbies for whom JS is their first language and have no serious understanding of engineering practices, security and quite eager to use a library rather than wasting hours figuring out how to pad a string.
• snickerbockers 10mo ago
  Why does every major Javascript vulnerability come off as something that would be easily avoided by not doing obviously stupid things (in this case automatically updating packages with no authentication, testing or oversight)?
  • chasd00 10mo ago
    Coding boot camps.
• gdotdesign 10mo ago
  - There is a single root dependency somewhere which gets overtaken - A new version of this dependency is published - A CI somewhere of another NPM package uses this new version dependency in a build, which trigger propagation by creating a new modified version of this dependency? - And so on... Am I getting this right?
  • chasd00 10mo ago
    I think so. It’s that third step that I can’t figure out. Build systems are configured to pull the latest version of a dep automatically, without review, and then publish. It seems the poorly configured pipelines are what enable these attacks. Fix your pipelines
• shadymoney 10mo ago
  This is why I am not a huge fan of separate package managers for libraries, such as in the case of rust, or node. The C style of sharing deps. couldn't really be simpler as just including the headers in your Makefile. We really don't need more package managers other than the ones provided by your operating system, but I dunno maybe its just me.
  • btbuildem 10mo ago
    The JS ecosystem in particular, it really seems like it was built by people hell-bent on reinventing the wheel and making all the mistakes / paying all the costs along the way. It's a pretty octagonal wheel so far, but maybe they'll get there eventually.
    • alehlopeh 10mo ago
      Ecosystems aren’t built by any homogeneous group of people. They’re a sum of their parts. It’s not like there was a committee and that committee decided how things should work wrt wheel reinvention. People publish packages, and the result is something we call an ecosystem.
  • kortex 10mo ago
    That ship has sailed, traveled around the world, and docked in a foreign port at this point. Including headers isn't remotely "simple". There's so many considerations in linking, .SO version compatibility, architecture and instruction set issues, building against multiple versions on the same system. Or if you want to feel frustrated in a single word: GDAL (IYKYK) And that's only where #include is even applicable. That is not gonna fly for any interpreted language - JS in this case, but also python, ruby, php.
    • YouAreWRONGtoo 10mo ago
      [dead]
    • shadymoney 10mo ago
      > Including headers isn't remotely "simple". There's so many considerations in linking, .SO version compatibility, architecture and instruction set issues, building against multiple versions on the same system. Or if you want to feel frustrated in a single word: GDAL (IYKYK) I'd say for issues with instruction sets is a minor edge case, you could argue that having layers of abstraction gives even more room for fault. That said I am not familiar with GDAL, but from google-fu it seems relatively heavy. Being said, I don't have much familiarity with compiling CXX programs as I do with programming C programs, and C with it's smaller footprint tends to not give me as many problems. Again, this is from personal experience.
• indigodaddy 10mo ago
  Is this a problem with Python package management too? If not, what distinguishes Python from NPM or makes it more resistant etc?
  • kevincox 10mo ago
    Yes. But Python is less popular so it isn't targeted as often.
• nathan_compton 10mo ago
  I never, ever, do development outside of a podman container these days. Basically if I am going to run some code from somewhere and I haven't read it, it goes in a container. I know its not foolproof, but I can't believe how often people run code they haven't read where it can make a huge mess, steal secrets, etc. I'll probably get owned someday, I'm sure, but this feels like a bare minimum.
  • rco8786 10mo ago
    How are you doing this in practice? These are npm packages. I don't see how could reasonably pull in Posthog's SDK in a container.
    • christophilus 10mo ago
      What do you mean? You can drop into bash in a container and run any arbitrary command, so `npm install foo` works just fine. Why would posthog's SDK be a special case?
      • LeifCarrotson 10mo ago
        I think the issue is more about what else has to go into or be connected to that container. Posthog isn't really useful if it's air-gapped. You're going to give it keys to access all kinds of juicy databases and analytics, and those NPM tokens, AWS/GCP/Azure credentials, and environment variables are exactly what it exfiltrates. I don't run much on the root OS of my dev machine, basically everything is in a container or VM of some kind, but that's more so that I can reproduce my environment by copying a VMDK than in an effort to limit what the container can do to itself and data it has access to. Yeah, even with root access to a VM guest, an attacker they won't get my password manager, personal credit card, socials, etc. that I only use from the host OS... But they'll get everything that the container contains or has access to, which is often a lot of data!
        • Lutger 10mo ago
          You're severely limiting the blast radius. This malware works by exfiltrating secrets during installation, if I understood it correctly. If you would properly containerize your app and limit permissions to what is absolutely required, you could be compromised and still suffer little to no consequences. Of course, this is not a real defense on its own, its just good practice to limit blast radius, much like not giving everybody admin rights.
• jbverschoor 10mo ago
  I use the following to at least sandbox things in containers with an easy to use develop experience. https://github.com/jrz/container-shell https://github.com/jrz/container-shell
  • jbverschoor 10mo ago
    0.2.4 had an issue btw
• alexchantavy 10mo ago
  Small plug for my open source project: you can use Cartography [https://github.com/cartography-cncf/cartography https://github.com/cartography-cncf/cartography], to map your infra and then run this query (https://gist.github.com/achantavy/2cc7cc49919a8f761fea5e2d75d9769a https://gist.github.com/achantavy/2cc7cc49919a8f761fea5e2d75...) to see if you're affected
• ChrisArchitect 10mo ago
  More: SHA1-Hulud the Second Comming – Postman, Zapier, PostHog All Compromised via NPM https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting...
• David-Henrry 10mo ago
  [dead]
• xnorswap 10mo ago
  Perhaps it's time to organize a curated "stable" stream for npm packages. If I want more stability for my OS I can choose Debian-stable rather than Ubuntu-nightly. But for npm, there doesn't seem to be the same choice available. Either I sign up to the fire-hose or I don't. I can choose to only upgrade once a month, but there's a chance I'm still getting a package that dropped 5 minutes before.
  • philipwhiuk 10mo ago
    pnpm minimumReleaseAge: 43200
  • Etheryte 10mo ago
    Upgrading once a month is insane at any rate, I could see the point in upgrading maybe once a year. For stable projects, you're very much fine upgrading only when there's a vulnerability or you need something from a newer release. Upgrade when you actually need to and use stable versions that have been out for a while, no need to hamster wheel it.
    • hinkley 10mo ago
      When I worked in commercial aerospace, before we even shipped live there was an incident with a CERT advisory against the XML package we were using. But the fix was only added to the current major version and we were stuck one behind. It took ~3 of our best problem solvers about a week to get that damned thing upgraded. Which put us behind on our schedule. This made some of my more forward thinking coworkers nervous because what if this happened after we went live? So we started a repeating story called “upgrade dependencies” and assigned it round robin once a month to someone on each application. Every time someone got it the first time they would ask me, “but upgrade what?” Whatever you want, but preferable something that hasn’t been in a while. For IP and security reasons we were already on vendored dependencies, so it was pretty straightforward to tell what was old. But that made “upgrade immediately” problematic if fixes weren’t back ported far enough and we didn’t want that live.
• smallerfish 10mo ago
  Because PostHog's "Talk to a human" chat instead gets a grumpy gatekeeping robot (which also doesn't know how to get you to a working urgent support link), and there's nothing prominently on their home page or github about this: Hey PostHog! What version do we need to avoid?
  • raunakchowdhuri 10mo ago
    Have a slack channel with them, these are the versions they mentioned: posthog-node 4.18.1 posthog-js 1.297.3 posthog-react-native 4.11.1 posthog-docusaurus 2.0.6
  • timgl 10mo ago
    co-founder here. We mentioned it in the main thread about this: https://news.ycombinator.com/item?id=46032650 https://news.ycombinator.com/item?id=46032650 and on status.posthog.com - posthog-node 4.18.1, 5.13.3 and 5.11.3 - posthog-js 1.297.3 - posthog-react-native 4.11.1 - posthog-docusaurus 2.0.6 If you make sure you're on the latest version you should be good.
    • smallerfish 10mo ago
      Thanks. Also - maybe change "talk to a human" to "talk to a grumpy robot" :)
      • timgl 10mo ago
        Hm did you click on "help" (on the right side) -> "Email our support engineer" when logged in?
        • smallerfish 10mo ago
          Ahhh, TBH I didn't look on the right. I dug through the menu on the left, thinking the right hand bar (which has the rotated labels) was all getting-started/docs related things. In my defense I have a fairly wide monitor and tend to full-screen the browser.
• jamietanna 10mo ago
  See also: https://news.ycombinator.com/item?id=46005111 https://news.ycombinator.com/item?id=46005111 As it arguably would have reduced impact (I'm one of the Renovate maintainers and have recently pushed for this to be more of a widely used feature)
  • philipwhiuk 10mo ago
    I think everyone just gets hit after 7 days frankly.
    • pixl97 10mo ago
      Why? Everyone won't use cooldowns, but the key is to have just enough people running brand new to set off a warning/have systems that check dependencies scan and find vulns go off and the packages get pulled before production builds them. Monocultures where everyone pulls and builds with every brand new thing for the most minor changes is dangerous.
• burninhell 10mo ago
  I wish everyone here would read https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security and then realize that maybe, JUST MAYBE, THE PROGRAMMING LANGUAGES WE USE SHOULD NOT ALLOW IMPORTED PACKAGES TO ACCESS EVERYTHING, AND THEIR LACK OF SECURITY GUARANTEES AND ACCESS RESTRICTION MECHANISMS MAKES THEM DANGEROUS! The number and range of affected devices may be reduced with any number of package manager level workarounds, but NOT the impact of attacks once any succeeds. For this, you NEED the above.
• twistedpair 10mo ago
  ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packages (e.g. workflow A can only publish pkg A), and IP bound it to your self hosted CI/CD runners. No one should have publish keys on their local, and even if they got the publish keys, they couldn't publish from local. (Granted, GHA fans can use OIDC Trusted Publishers as well, but tokens done well are just as secure)
  • latchkey 10mo ago
    ProTip: `use bun` Funny that this is getting downvoted, but it installs dependencies super fast, and has the same approval feature as pnmp, all in a simple binary.
    • benjifri 10mo ago
      This is like saying "use MacOS and you won't get viruses" in the 2000s
      • hiccuphippo 10mo ago
        Except trying it out takes a minute and costs nothing.
      • latchkey 10mo ago
        The suggestion was to use pnpm, and I'm suggesting something I prefer more than pnpm.
      • koito17 10mo ago
        Bun disables post-install scripts by default and one can explicitly opt-in to trusting dependencies in the package.json file. One can also delay installing updated dependencies through keys like `minimumReleaseAge`. Bun is a drop-in replacement for the npm CLI and, unlike pnpm, has goals beyond performance and storage efficiency. Not sure what your analogy is trying to imply.
• JadoJodo 10mo ago
  Would the adoption of a Deno-like security posture in NPM have mitigated this?
  • jkrems 10mo ago
    pnpm is the better comparison maybe in this context. Most of Deno's approach to security is focussed on whole program policies which doesn't do much in this context. Just like pnpm and others, they do have opt-in for install scripts though. The npm CLI is an outlier there by now.
• benmccann 10mo ago
  Hundreds of people had access to publish the Zapier SDK, so it's little surprise they were eventually compromised! (https://bsky.app/profile/benmccann.com/post/3m6fdecsbdk2u https://bsky.app/profile/benmccann.com/post/3m6fdecsbdk2u) The e18e community are reducing dependencies in popular libraries and building tools to prevent and reduce the impact of such attacks. Join if you want to help out! https://e18e.dev/ https://e18e.dev/ Just this morning, after trying to make the case over the past year, we had a change landed to remove more than a dozen dependencies from typescript-eslint! https://bsky.app/profile/benmccann.com/post/3m6fcjax7ec2h https://bsky.app/profile/benmccann.com/post/3m6fcjax7ec2h
  • mcintyre1994 10mo ago
    FYI your first link is the same as your third link. It's correct as the third link, so the Zapier one is missing.
    • benmccann 10mo ago
      fixed!
  • balamatom 10mo ago
    >e18e Yay! >Discord ...ew.
• root_axis 10mo ago
  Seems to me the root problem here is poor security posture from the package maintainers. We need to start including information about publisher chain of custody into package meta data, that way we can recursively audit packages that don't have a secure deployment process.
• leo_e 10mo ago
  Postman getting hit is scary. For many teams, it's effectively an unmanaged password manager for API keys.
  • smt88 10mo ago
    No one should have sensitive/production keys in Postman. That's a huge security lapse in the first place. My devs don't have access to production keys at all (and would never need them).
• blackoil 10mo ago
  What we need is an open source industry standard stdlib equiv developed and maintained by MS, GOOG and some open source players. All libraries should strive to have dependency only on it.
• qi_reaper 10mo ago
  "This appears to have limited the imapct of the attack at this time." typo after the listed affected packages
• jhatemyjob 10mo ago
  And this, kids, is why you should vendor your dependencies
  • jkrems 10mo ago
    Vendoring wouldn't really affect this at all. If anything it would keep you vulnerable for longer because your vendored copy keeps "working" after the bad package got removed upstream. There's a tiny chance that somebody would've caught the 10MB file added in review but that's already too late - the exploit happened on download, before the vendored copy got sent for review.
    • withinboredom 10mo ago
      But you would have code reviewed it
• liampulles 10mo ago
  Ok, I think the verdict on the "JavaScript for everything" experiment is in. It was already resolved long ago (in my opinion), but this should convince any stragglers. Let's accept that the one thing JS is really great for is DOM patching, and move on. Going forward, use WASM if you really want to make an SPA (and think about that choice), where the source language is not something that ties into the JS dependency ecosystem. Ban it and burn it with fire for anything on the backend, for christ.
• agentifysh 10mo ago
  these packages stood out for me shinhan is a large korean bank and this admin area geo json util seems to be embedded in many korean gov services. shinhan-limit-scrap korea-administrative-area-geo-json-util
• lukebechtel 10mo ago
  This is still happening -- github should implement a hotfix to disallow creation of repos with this exact name and structure...
• tony-john12 10mo ago
  [dead]
• hinkley 10mo ago
  > bun_environment.js is a highly obfuscated malicious JavaScript file. It is over 10MB in size and contains a significant amount of built-in logic for information theft. That seems a bit silly. Even on the beefy boi I used to work on a 10MB hiccup in deployable size would have been sufficient to make me look. I released one of the packages I work on last night so of course this drew my eye. I assume checking the unpacked size hasn’t gotten ridiculous confirms that your code is not infected yeah? And looks like it’s past time for me to set up a separate account for release management.
• ashishb 10mo ago
  Run npm and yarn inside docker [1]. Infact, do this for all risky tools[2] 1 - https://github.com/ashishb/dotfiles/blob/067de6f90c72f0cf849fb6edcd941b347712ced9/bashrc_includes/custom_aliases.bash#L19-L21 https://github.com/ashishb/dotfiles/blob/067de6f90c72f0cf849... 2 - https://ashishb.net/programming/run-tools-inside-docker/ https://ashishb.net/programming/run-tools-inside-docker/
  • anpat 10mo ago
    I think it's better to not run npm as root user on container. I would suggest adding --user 1000 to your docker run command.
    • ashishb 10mo ago
      > I think it's better to not run npm as root user on container. I would suggest adding --user 1000 to your docker run command. Good point. Here's the improvement that work for me https://github.com/ashishb/dotfiles/commit/fe4fb15fe867bf77a53e0754c8444d87dd4abcf4 https://github.com/ashishb/dotfiles/commit/fe4fb15fe867bf77a...
      • jayknight 10mo ago
        It gets tricky with private dependencies, then you have to pass some sort of token into the container to authenticate with the host when installing dependencies.
        • ashishb 10mo ago
          Definitely. Would you prefer doing those tricks or exposing everything on your machine to random npm packages?
• cm2012 10mo ago
  As a marketer who relies on tools like Zapier and PostHog and n8n, etc - terrifing. Since it means the dev/security teams may take our toys away :(
• cm2012 10mo ago
  I am amazed at the dates in this article. This compromise appears to have been discovered literally this morning. Incredibly fast turnaround on this article.
• Aperocky 10mo ago
  Shai-Hulud is the best thing to happen for npm. It's much easier to demonstrate a problem (twice!) than to convince a herd that there is a problem. I hope that other languages with similar package manager (looking at you, cargo) take note.
• vedhant 10mo ago
  Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.
  • lesuorac 10mo ago
    To me this is asking the question of "what's the safest way to drink from a polluted river". The answer is really, don't. NPM and the JS eco-system has really gone down a path of zero security and they're paying the price for it. If you really need libraries from NPM and whatnot, vendorize them so you're relying on known-safe files and don't arbitrarily update them without re-verification.
    • vedhant 10mo ago
      This is true. Today its npm, tomorrow it could be some other language. Shouldnt we focus on solving it at the root?
    • samdoesnothing 10mo ago
      Some of us need to drink from the river to eat :(
• throwaway1389z 10mo ago
  What is going on with this website though? It gives cursor stutter and slow scrolling. It seems like we now need an insane amount of CPU to read static text. What a regression.
• vedhant 10mo ago
  Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.
  • Aperocky 10mo ago
    To not use npm. Or create a package manager like npm. Or believe in philosophy that we should have as many small dependencies as possible. If you must use npm, containerize/VM it? treat it as if you're observing malware.
  • divmain 10mo ago
    pnpm’s minimumReleaseAge can help a ton with this. There’s a tricky balance, because allowing your dependencies to get stale makes you inherently more vulnerable to vulnerabilities in your packages. And, critically, fixing a vulnerability in an urgent situation (i.e. you were compromised) gets increasingly harder to address the more stale your dependencies are. minimumReleaseAge strikes a good balance between protecting yourself against emerging threats like Shai-Hulud and keeping your dependencies up-to-date. Because you asked: you can get another layer of protection through Socket Firewall Free (sfw), which prevents dependencies known to be malicious from being installed. Socket typically identifies malware very soon after its is published. Disclaimer: I’m the lead dev on the project, so obviously biased — YMMV.
  • Nathanba 10mo ago
    I think we shouldn't be using package repositories in this way at all, shouldn't it be much better to have a package system like golang has where you directly import the sourcecode from github? You get around an entire class of problems. At least now you can only be compromised if the github source code itself is compromised, not any part of some build pipeline or a tool like npm or an npm registry. That means to vendor everything and only upgrade if you need to upgrade, treat all the code like you are responsible for it all because you are. The entire concept of relying on builds of other people is part of the problem, it's bad enough that we rely on source code of other people but that goes with the territory. Relying on their build systems is not as mandatory.
• mkhalil 10mo ago
  I use pnpm, but even so: thankfully naming things is hard, and all my env variable names are very_convuluted_non_standard_names for things lol.
• 1vuio0pswjnm7 10mo ago
  I have never tried NPM. Somehow I can still find the software I want, or write it myself. I think I would find Javascript too slow
• biff1 10mo ago
  Friends don’t let friends NPM.
• thepill 10mo ago
  How do you test your projects if there are any infected/affected dependencies used? As i understand it could also be a dependency of a dependency ... that could be affected?
  • efortis 10mo ago
    npm audit and npm audit --fix Or if you want to know the version of a package you have installed: npm ls some-pkg
• m4rtink 10mo ago
  So people using only distro provided dependencies were indeed right all along. ;-)
• deleted 10mo ago
  [deleted]
• sunshine-o 10mo ago
  I was looking at the packages affected and there are some recognizable names. The ones that got my attentions are the @ensdomains/*, that are the legit packages and are probably in every Ethereum/EVM/blockchain related apps for the resolution of decentralized domain names. A quick search shows those Ledger hardware wallet use those libs too [0] So I guess they weren't just after API keys. - [0] https://github.com/search?q=org%3ALedgerHQ%20%40ensdomain&type=code https://github.com/search?q=org%3ALedgerHQ%20%40ensdomain&ty...
• 999900000999 10mo ago
  I remember when I was young... 12 years ago NPM went down due to a very issue and getting stuff working again wasn't easy. Someone got on GitHub and said something along the lines of "Get it together or get forked. " I asked my manager if this was real or just a random guy talking. My manager, correctly said, it's just talk. But it's different now. NPM is owned by Microsoft. One of the world's biggest companies should be able to sort things out. Ohh well. Can't fix it.
  • downrightmike 10mo ago
    MSFT can't even sort Windows out, if they can't charge for it in an Enterprise license, it gets left behind. Which is why W11 is a marketing grab bag of trash.
• throwaway984393 10mo ago
  [dead]
• jwpapi 10mo ago
  Why do the attackers publicly share the keys they found? Like what’s their mission?
  • theodorejb 10mo ago
    My guess would be so they don't have to embed an IP address or hostname in the malware to send secrets to, which could then be blocked or taken down.
    • jwpapi 10mo ago
      But they could encrypt it, its just double b64 encoded, everybody can read it.
      • twistedpair 10mo ago
        That one stumped me. Why not just encrypt with a hardcoded public key, then only the attacker can get the creds. The simple B64 encoding didn't hide these creds from anyone, so every vendor out there's security team can collect them (e.g. thinking big clouds, GitHub, etc) and disable them. If you did a simple encryption pass, no one but you would know what was stolen, or could abuse/sell it. My best guess is that calling node encryption libs might trigger code scanners, or EDRs, or maybe they just didn't care.
        • jwpapi 10mo ago
          Or they just wanted to prove a point. They surely seemed to be smart enough to choose encryption over encoding. Hard to believe encryption would be the one thing that would trigger code scanners. Also it’s not just every vendor, also every bad actor could’ve scraped the keys. I wonder if they’ve set up the infrastructure to handle all these thousands of keys… Like what do you even do with most of it on scale? Can you turn Cloud, AWS , AI api keys to money on a black market?
• plasma 10mo ago
  GitLab's write-up mentions a dead man's switch where "The malware continuously monitors its access to GitHub (for exfiltration) and npm (for propagation). If an infected system loses access to both channels simultaneously, it triggers immediate data destruction on the compromised machine. " https://about.gitlab.com/blog/gitlab-discovers-widespread-npm-supply-chain-attack/#the-dead-mans-switch https://about.gitlab.com/blog/gitlab-discovers-widespread-np...
• computersuck 10mo ago
  I cannot believe how long it's taking github to shut this down, it's still going, and all they need to do is block a 18 char alphanumeric repo name from creation for this specific wave. ([0-9a-z]{18})
• developerjhp 10mo ago
  I’ve been tracking these supply-chain incidents as well, so I built a small real-time scanner that looks for suspicious SHA-1 patterns inside repositories. It’s basically a lightweight CLI tool you can run directly inside any local project: npx sha1-hulud-scanner Repo is here: https://github.com/developerjhp/sha1-hulud-scanner https://github.com/developerjhp/sha1-hulud-scanner It’s not meant to be a full security product — just a simple “first-pass” detector that helps catch unexpected checksum strings or injected artifacts before they slip into CI. Feedback and contributions are welcome!
• sora2video 10mo ago
  [dead]
• deleted 10mo ago
  [deleted]
• Joeri 10mo ago
  I don’t feel confident there is a way to use npm safely. The basic problem is that of curation, and there not being any except for what you do yourself. Every day brings new surprises, and osv.dev’s npm feed is a continuous horror show. I would love to see the equivalent of a linux distro, a curated set of packages and package versions that are known to be compatible and safe. If someone offered this as a paid product businesses would pay for it.
  • cncjchsue7 10mo ago
    They'll use AI to do it and it will be no better than what we have today. You will pay for it anyway.
• willtemperley 10mo ago
  I just cannot believe what a cluster of a show this is. Microsoft, you own NPM, sort it out. It's ridiculous.
• nycalexander 10mo ago
  Made a package (that I needed personally), to easily reinstall all dependencies (using the same versions) in a project and check them using Aikido's safe chain for malware (supported npm, pnpm, bun, and yarn). It also easily switches a project's package manager to another. https://www.npmjs.com/package/eazypm https://www.npmjs.com/package/eazypm
• kevinslin 10mo ago
  as someone that likes the npm package ecosystem but is not fond of malware - ended up building a CLI wrapper around npm to only install packages older than a configurable amount of days. in case folks find it helpful: https://github.com/kevinslin/safe-npm https://github.com/kevinslin/safe-npm