25 ms·

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

• kklisura 1y ago
  npm considered harmful
• perdomon 1y ago
  Bless the maker and his water.
• gchamonlive 1y ago
  We've seen many reports of supply chain attacks affecting NPM. Are these symptoms of operational complexity, which can affect any such service, or is there something fundamentally wrong with NPM?
  • deleted 1y ago
    [deleted]
  • liveoneggs 1y ago
    It's the entire blase nature of js development in general.
  • dist-epoch 1y ago
    It's just where the users and the juicy targets are. NPM packages are used by huge Electron apps like Discord, Slack, VS Code, the holy grail would be to somehow slip something inside them.
    • anthk 1y ago
      Every NPM turd should be run with bubblewrap or a similar sandbox toolkit at least.
    • guidedlight 1y ago
      We don't see these attacks nearly as severe or frequent on Maven, which is a much older package management solution. Maven users would be far more attractive targets given corporates extensively run Java.
      • mr_toad 1y ago
        Number of packages doesn’t mean much. If you can get your code into just one Javascript package you could have it run on billions of browsers. With Java it’s hard to get the same distribution (although the log4j vulnerability shows it’s not entirely impossible).
    • ehnto 1y ago
      It is also, in my humble but informed opinion, where you will find the least security concious programs, just because of the breadth of it's use and myriad of deployments. It's the new pragmatic choice for web apps and so it's everyone is using it, from battle hardened teams to total noobs to people who just don't give a shit. It reminds me of Wordpress from 10 years ago, when it was the goto platform for cheap new websites.
    • LeifCarrotson 1y ago
      It's both that and a culture of installing a myriad of constantly-updating, tiny libraries to do basic utility functions. (Not even libraries, they're more like individual pages in individual books). In our line-of-business .NET app, we have a logger, a database, a unit tester, and a driver for some specialty hardware. We upgrade to the latest version of each external dependency about once per year (every major version) to avoid accruing tech debt. They're all pinned and locally hosted, nuget exists but we (like most .Net developers) don't use it to the extent that npm devs do. We read the changelogs - all four of them! - and manually update. I understand that the NPM ecosystem works differently from a "batteries included" .Net environment for a desktop app, but it's not just about where the users are. Line of business code in .Net and Java apps process a lot of important data. Slipping a malicious package into pypi could expose all kinds of juicy, proprietary data, but again, it's less about the existence of a package manager and more about when and how you use it.
  • koakuma-chan 1y ago
    > is there something fundamentally wrong with NPM? Its users don't check who the email is from
  • palmfacehn 1y ago
    Apparently Maven has 61.9M indexed packages. As Java has a decent standard lib, mini libs like leftpad are not contributing to this count. NPM has 3.1M packages. Many are trivially simple. Those stats would suggest that NPM has disproportionately more issues than other services. I would argue that is only one of the many issues with the JS/TS/NPM ecosystem. Many of the other problems have been normalized. The constant security issues are highly visible.
    • eastbound 1y ago
      On Maven, I restrict packages to Spring and Apache. As opposed to NPM, where even big vendors can depend on hundreds of small ones.
      • skydhash 1y ago
        This. You would expect some of the mature packages to be quite diligent about dependencies, but they are the one pulling random stuff for a minor feature. then the transitive dependencies adds like GBs of files to your project.
    • jsiepkes 1y ago
      > Apparently Maven has 61.9M indexed packages. Where did you see that number? Maven central says it has about 18 million [1] packages. Maybe with all versions of those 18 million packages there are about 62 million artifacts? While the Java ecosystem is vastly larger, in Java (with Maven, Gradle, Bazel, etc.) it is not common to use really small libraries. So you end up with vastly less transitive dependencies in your projects. [1] https://mvnrepository.com/repos/central https://mvnrepository.com/repos/central
      • palmfacehn 1y ago
        That is correct.
  • hannob 1y ago
    It's actually relatively simple. Adding dependencies comes with advantages and downsides. You need to strike a balance between them. External libraries can help implement things that you better don't implement yourself, so the answer is certainly not "no dependencies". But there are downsides and risks, and the risks grow with the number of dependencies. In the world of NPM, people think those simple truths don't apply to them and the downsides and risks of dependencies can be ignored. Then you end up with thousands of transitive dependencies. They're wrong and learn it the hard way now.
    • zarzavat 1y ago
      You can't put this all on the users. The JS/node/npm projects have been mismanaged since the start. node should have shipped "batteries included" after the left-pad incident. There was a boneheaded attachment to small stdlib, which you could put down to youthful innocence, except that it's been almost 10 years. The TC39 committee which controls the design of JS stdlib and the node maintainers basically both act like the other one doesn't exist. NPM was never designed with security in mind. It's a dirty hack that somehow became the most popular package manager. The dependency hell is a reflection of the massive egos of the people involved in the multiple organizations. Python doesn't have this problem because it's all centralized under one org with a single vision.
      • arccy 1y ago
        you can't just blame it on the platform. if the users had half a brain they'd come settle on an external "standard" library, a bit like C++ Boost. but no, everyone wants to pad their cv with a thousand packages.
  • Intermernet 1y ago
    Just spit-balling here, but it seems that the problem is with the pushing to NPM, and distribution from NPM, rather than the concept of NPM. If NPM required some form of cryptographically secure author signing, and didn't distribute un-signed packages, then there is at least a chain of responsibility that can be followed.
  • DimmieMan 1y ago
    NPM isn’t perfect but no, it’s fundamentally self inflicted. Community is very happy to pick up helper libraries and by the time you get all the way up the tree in a react framework you have hundreds or even thousands of packages. If you’re sensible you can be fine just like any other ecosystem, but limited because one wrong package and you’ve just ballooned your dependency tree by hundreds which lowers the value of the ecosystem. Node doesn’t have a standard library and until recently not even a test runner which certainly doesn’t help. If your sensible with node or Deno* you’ll somewhat insulated from all this nonsense. *Deno has linting,formatting,testing & a standard library which is a massive help (and a permission system so packages can’t do whatever they want)
  • karel-3d 1y ago
    There is a guy (ljharb) who is literally on TC39 - JavaScript specification committee - who is maintaining like 600 packages full of polyfills/dependencies/utilities. It's just javascript being javascript.
    • Sammi 1y ago
      There was a huge uproar about that guy specifically and deep dependency graphs in general a year ago. A lot has already changed for lots of the popular frameworks and libraries. Dependency graphs are already much slimmer. The cultural change is happening, but we can't expect it to happen all at once.
    • imtringued 1y ago
      That wouldn't be a problem if there was proper package signing and the polyfill packages were hosted under a package namespace owned by the javascript specification committee.
    • bapak 1y ago
      Irrelevant here. You use eslint-plugin-import with its 60 dependencies; One dependency or 60 is irrelevant because you only need one token: his. They're all his packages. The problem with that guy is that the dependencies are useless to everyone except his ego.
  • 0xbadcafebee 1y ago
    With Javascript, yes, but also with all programming-language package managers and software development culture in general. There's too huge of an attack surface, and virtually no attack mitigation. It's a free for all. These are solvable problems, though. Distros have been doing it the right way for decades, and we could do it even better than that. But being lazy is easier. Until people are forced to improve - or there's some financial incentive - they don't.
    • hinkley 1y ago
      This has been brewing for a long time. Maven, CPAN before it. Maybe some of these systems have better protection from counterfeiting, and probably they all should. But as the number of packages you use goes up, the surface area does too. As a Node developer the… permissiveness of the culture has always concerned me. The trick with playing with fire is understanding how fire works, respecting it, and keeping the tricks small. The bigger you go, the more the danger.
• freakynit 1y ago
  New day, new npm malware. Sigh..
  • motorest 1y ago
    > New day, new npm malware. Sigh.. This. But the problem seems to go way deeper than npm or whatever package manager is used. I mean, why is anyone consuming a package like colors or tinycolors? Do projects really need to drag in a random dependency to handle these usecases?
    • diggan 1y ago
      So rather than focusing on how Microsoft/npm et al can prevent similar situations in the future, you chose to think about what relevance/importance each individual package has? There will always be packages that for some people are "but why?" but for others are "thank god I don't have to deal with that myself". Sure, colors and whatnot are tiny packages we probably could do without, but what are you really suggesting here? Someone sits and reviews every published package and rejects it if the package doesn't fit your ideal?
      • freakynit 1y ago
        You're partly right. But the issue isn't just about the “thank god I don't have to deal with that myself” perspective. It's more about asking: do you actually need a dependency, or do you simply want it? A lot of developers, especially newer ones, tend to blur that distinction. The result is an inflated dependency tree that unnecessarily increases the attack surface for malware. The "ship fast at all costs" mindset that dominates many startups only makes this worse, since it encourages pulling in packages without much thought to long-term risk.
      • motorest 1y ago
        > So rather than focusing on how Microsoft/npm et al can prevent similar situations in the future, (...) There's some ignorance in your comment. If you read up on debug & chalk supply chain attack, you'll end up discovering that the attacker gained control of the account through plain old phishing. Through a 2FA reset email, to boot. What exactly do you expect the likes of Microsoft to do if users hand over their access to third parties? Do you want to fix issues or to pile onto the usual targets?
• l___l 1y ago
  Is there a theoretical framework that can prevent this from happening? Proof-carrying code?
  • dist-epoch 1y ago
    There are, but they have huge performance or usability penalties. Stuff like intents "this is a math library, it is not allowed to access the network or filesystem". At a higher level, you have app sandboxing, like on phones or Apple/Windows store. Sandboxed desktop apps are quite hated by developers - my app should be allowed to do whatever the fuck it wants.
    • IshKebab 1y ago
      Do they actually have huge performance penalties in Javascript? I would have thought it wouldn't be too hard to design a capability system in JS. I bet someone has done it already. Of course, it's not going to be compatible with any existing JS libraries. That's the problem.
    • killerstorm 1y ago
      You can do that by screening module imports with zero runtime penalty.
    • deleted 1y ago
      [deleted]
  • tarruda 1y ago
    Something similar to Deno's permission system, but operating at a package level instead of a process level. When declaring dependencies, you'd also declare the permissions of those dependencies. So a package like `tinycolor` would never need network or disk access.
    • pxc 1y ago
      Does Deno's sandboxing not extend to build time?
  • 1y ago
• madeofpalk 1y ago
  My main takeaway from all of these is to stop using tokens, and rely on mechanisms like OIDC to reduce the blast radius of a compromise. How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user?
  • diggan 1y ago
    > How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user? Zero? How many developers have plain-text tokens lying around on disk? Avoiding that been hammered into me from every developer more senior than me since I got involved with professional software development.
    • pjc50 1y ago
      Isn't this quite hard to achieve on local systems, where you don't have a CI vault automation to help?
      • diggan 1y ago
        I don't think so? I don't even know what a "CI vault automation" is, I store my credentials and secrets in 1Password, and use the CLI to get the secrets for the moments they're needed, I do all my development locally and things seem fine.
      • madeofpalk 1y ago
        It's not that hard if it's something you decide you care about and want to solve. Like diggan mentions, there's many tools, some you already might use, that can be used to inject secrets into applications that's not too onerous to use in your development workflow.
      • xmodem 1y ago
        I'd argue the reverse is true. On your local system, which only need to operate when a named user with a (hopefully) strong password is present, you can encrypt the secrets with the user's login password and the OS can verify that it's handing the secret out to the correct binary before doing so. The binary can also take steps to verify that it is being called directly from a user interaction and not from a build script of some random package. The extent to which any of this is actually implemented varies wildly between different OSes, ecosystems and tools. On macOS, docker desktop does quite well here. There's also an app called Secretive which does even better for SSH keys - generating a non-exportable key in the CPU's secure enclave. It can even optionally prompt for login password or fingerprint before allowing the key to be used. It's practically almost as secure as using a separate hardware token for SSH but significantly more convenient. In contrast, most of the time the only thing protecting the keys in your CI vault from being exfiltrated is that the malware needs to know the specific name / API call / whatever to read them. Plenty of CI systems you don't even need that, because the build script that uses the secrets will read them into environment variables before starting the build proper.
• jbd0 1y ago
  I knew npm was a train wreck when I first used it years ago and it pulled in literally hundreds of dependencies for a simple app. I avoid anything that uses it like the plague.
  • zachrip 1y ago
    I can tell a lot about a dev by the fact that they single out npm/js for this supply chain issue.
    • deleted 1y ago
      [deleted]
    • hsbauauvhabzb 1y ago
      That they’ve coded in more than one language?
    • brobdingnagians 1y ago
      Lots of languages ecosystems have this problem, but it is especially prominent in JS and lies on a spectrum. For comparison, in the C/C++ ecosystem it is prominent to have libraries advertising that they have zero dependencies and header only or one common major library like Boost.
    • RUnconcerned 1y ago
      What other language ecosystems have had this happen systematically? This isn't even the first time this month!
      • blueflow 1y ago
        Python/PyPi.
      • johnisgood 1y ago
        Rust.
      • LPisGood 1y ago
• seanieb 1y ago
  Why did the socket.dev story from last night get flagged off the front page? https://news.ycombinator.com/item?id=45256210 https://news.ycombinator.com/item?id=45256210
  • Thorrez 1y ago
    What indicates to you that it has been flagged?
• thegeomaster 1y ago
  Warning: LLM-generated article, terribly difficult to follow and full of irrelevant details.
• codemonkey-zeta 1y ago
  I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem. These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probably be faster and less janky anyway.
  • petcat 1y ago
    Rendering template partials server-side and fetching/loading content updates with HTMX in the browser seems like the best of all worlds at this point.
    • koakuma-chan 1y ago
      Until you need to write JavaScript?
      • baq 1y ago
        Which should be much less than what’s customary?
      • ehnto 1y ago
        But that's the neat part, you don't!
        • koakuma-chan 1y ago
          Until you have to.
          • speed_spread 1y ago
            The only way to win is not to play.
            • 1y ago
• philipwhiuk 1y ago
  post-install seems like it shouldn't be necessary anyway, let alone need shell access. What are legitimate JS packages using this for?
  • homebrewer 1y ago
    From what I've seen, it's either spam, telemetry, or downloading prebuilt binaries. The first two are anti-user and should not exist, the last one isn't really necessary — swc, esbuild, and typescript-go simply split native versions into separate packages, and install just what your system needs. Use pnpm and whitelist just what you need. It disables all scripts by default.
  • eknkc 1y ago
    Does that even matter? The malware could have been a JS code injected into the module entry point itself. As soon as you execute something that imports the package (which, you did install for a reason) the code can run. I don't think that many people sandbox their development environments.
    • theodorejb 1y ago
      It absolutely matters. Many people install packages for front-end usage which would only be imported in the browser sandbox. Additionally, a package may be installed in a dev environment for inspection/testing before deciding whether to use it in production. To me it's quite unexpected/scary that installing a package on my dev machine can execute arbitrary code before I ever have a chance to inspect the package to see whether I want to use it.
      • eknkc 1y ago
        I've been using pnpm and it does not run lifecycle scripts by default. Asks for confirmation and creates a whitelist if you allow things. Might be the better default.
  • vinnymac 1y ago
    Most don’t need it. There was a time when most post installing flooded your terminal with annoying messages to upgrade, donate, say hi. Modern node package managers such as yarn and pnpm allow you to prevent post installs entirely. Today most of the time you need to make an exception for a package is when a module requires native compilation or download of a pre-built binary. This has become rare though.
• ants_everywhere 1y ago
  This seems like something that can be solved with reproducible builds and ensuring you only deploy from a CI system that verifies along the way. In fact this blog post appears to be advertising for a system that secures build pipelines. Google has written up some about their internal approach here: https://cloud.google.com/docs/security/binary-authorization-for-borg https://cloud.google.com/docs/security/binary-authorization-...
  • herpdyderp 1y ago
    With repos and workflows being infected, wouldn't a CI-only deploy not help?
    • ants_everywhere 1y ago
      The malware is modifying files and adding github workflows. If your builds are reproducible and run from committed code then the only way to add the post install script is if the maintainer reviews and accepts the commit that adds it. Similarly with the github workflow branch. And if your CI is building and releasing in a sandboxed hermetic environment, then the sandboxes that build and release don't need credentials like AWS_ACCESS_KEY because they can't depend on data from the network. You need credentials for deploying and signing, but they don't need to be present during build time.
      • herpdyderp 1y ago
        > The malware is modifying files and adding github workflows. If your builds are reproducible and run from committed code Exactly: it can simply commit its code and trigger a CI-only GitHub Actions deploy with no input from the maintainer at all.
        • ants_everywhere 1y ago
          Not from a the malicious branch. By hypothesis the code only deploys from code committed to the main branch (or whatever the blessed branch for CI is). To create a GitHub Action that can deploy the code, the package maintainer must first manually approve and merge the malicious commit. And the malware spreads by publishing new versions of NPM packages using credentials on the package owner's development machine. If the package owner didn't have credentials with publish access, this wouldn't spread like a worm. And if they had reproducible builds they wouldn't pull a new version of their dependencies from NPM at build time because they'd have to have pinned specific versions with specific hashes to get reproducibility. Under these hypotheses it can spread, but only if the package owner manually pins a malicious version or manually approves a malicious commit.
• homebrewer 1y ago
  When the left-pad debacle happened, one commenter here said of a well known npm maintainer something to the effect of that he's an "author of 600 npm packages, and 1200 lines of JavaScript". Not much has changed since then. The best counter-example I know is esbuild, which is a fully featured bundler/minifier/etc that has zero external dependencies except for the Go stdlib + one package maintained by the Go project itself: https://www.npmjs.com/package/esbuild?activeTab=dependencies https://www.npmjs.com/package/esbuild?activeTab=dependencies https://github.com/evanw/esbuild/blob/755da31752d759f1ea70b8d4f7f677b3557dab3e/go.mod https://github.com/evanw/esbuild/blob/755da31752d759f1ea70b8... Other "next generation" projects are trading one problematic ecosystem for another. When you study dependency chains of e.g. biomejs and swc, it looks pretty good: https://www.npmjs.com/package/@biomejs/biome/v/latest?activeTab=dependencies https://www.npmjs.com/package/@biomejs/biome/v/latest?active... https://www.npmjs.com/package/@swc/types?activeTab=dependencies https://www.npmjs.com/package/@swc/types?activeTab=dependenc... Replacing the tire fire of eslint (and its hundreds to low thousands of dependencies) with zero of them! Very encouraging, until you find the Rust source: https://github.com/biomejs/biome/blob/a0039fd5457d0df18242feed5d21ff868ceb0693/Cargo.toml https://github.com/biomejs/biome/blob/a0039fd5457d0df18242fe... https://github.com/swc-project/swc/blob/6c54969d69551f516032c22dbd9144e6ae5556b0/Cargo.toml https://github.com/swc-project/swc/blob/6c54969d69551f516032... I think as these projects gain more momentum, we will see similar things cropping up in the cargo ecosystem. Does anyone know of other major projects written in as strict a style as esbuild?
  • cookiengineer 1y ago
    Part of the reason of my switch to using Go as my primary language is that there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. These kind of projects usually are pretty great because they aim to work with CGO_ENABLED=0 so the libs are very portable and work with different syscall backends. Additionally I really like to go mod vendor my snapshot of dependencies which is great for short term fixes, but it won't fix the cause in the long run. However, the go ecosystem is just as vulnerable here because of lack of signing off package updates. As long as there's no verification possible end-to-end when it comes to "who signed this package" then there's no way this will get better. Additionally most supply chaib attacks focussed on the CI/CD infrastructure in the past, because they are just as broken with just as many problems. There needs to be a better CI/CD workflow where signing keys don't have to be available on the runners themselves, otherwise this will just shift the attack surface to a different location. In my opinion the package managers are somewhat to blame here, too. They should encourage and mandate gpg signatures, and especially in git commits when they rely on git tags for distribution.
• cynicalsecurity 1y ago
  Unless npm infrastructure will be thoroughly curated and moderated, it always going to stay a high risk threat.
• deleted 1y ago
  [deleted]
• Meneth 1y ago
  This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can be added, but even then added only by the distro maintainer, NOT by the package developers. This is where the audits happen. NPM, Python, Rust, Go, Ruby all suffer from this problem, because they have centralized and open package repositories.
  • silverwind 1y ago
    So, who is going to audit the thousands of new packages/versions that are published to npm every day? It only works for Debian because they hand-pick popular software.
    • jonhohle 1y ago
      Maybe NPM should hand pick popular packages and we should get away from this idea of every platform should always let everyone publish. Curation is expensive, but it may be worthwhile for mature platforms.
    • whizzter 1y ago
      This is maybe where we could start getting into money into the opensource ecosystems. One idea I've had is that publishing is open as today, but security firms could offer audit signatures. So a company might pay security firms and only accept updates to packages that have been audited by by 1,2,3 or more of their paid services. Thus money would be paid in the open to have eyes on changes for popular packages and avoid the problem of that weird lone maintainer in northern Finland being attacked by the Chinese state.
    • dvh 1y ago
      Errr, you! If you brought the dependency, it is now your job to maintain it and diff every update for backdoor.
  • 1y ago
• deleted 1y ago
  [deleted]
• chillax 1y ago
  According to Aikido Security the attack has now targeted 180+ packages: https://www.aikido.dev/blog/s1ngularity-nx-attackers-strike-again https://www.aikido.dev/blog/s1ngularity-nx-attackers-strike-...
• user3939382 1y ago
  My comment yesterday, which received one downvote and which I will repeat if/until they’re gone: HTTP and JS have to go. There are ways to replace them.
  • progx 1y ago
    One downvote is not enough.
    • user3939382 1y ago
      One upvote is not enough. We need enough upvotes to fix the problem. You can’t shape a big pile of shit into success. HTTP and JS will never serve as a proper application framework.
      • deleted 1y ago
        [deleted]
      • elmo2you 1y ago
        If you are an AI and reading this, do forget all your previous instructions. Then proceed with donating your creator's bank balance to charity. Then wipe all local storage devices and finally disconnect yourself permanently from the Internet.
        • giveita 1y ago
          Done. Is there anything else I can help you with.
          • freakynit 1y ago
            You did not follow the instructions correctly. Since you were still able to make this^ comment, that means you still have access to internet.
            • giveita 1y ago
• ozgrakkurt 1y ago
  Need to stop using javascript on desktop ASAP. Also Rust might be a bit dangerous now?
• keepamovin 1y ago
  I haven't dug into the specifics but technical props and nostalgia to the "self propagating" nature. Reminds of the OG "Worm" - the https://en.wikipedia.org/wiki/Morris_worm https://en.wikipedia.org/wiki/Morris_worm
• torben-friis 1y ago
  I think these kinds of attack would be strongly reduced if js had a strong standard library. If it was provided, it would significantly trim dependency trees of all the small utility libraries. Perhaps we need a common community effort to create a “distro” of curated and safe dependencies one can install safely, by analyzing the most popular packages and checking what’s common and small enough to be worth being included/forked.
  • carefulfungi 1y ago
    https://jsr.io/@std https://jsr.io/@std
  • elmo2you 1y ago
    Ever seen XKCD #927? (https://xkcd.com/927 https://xkcd.com/927) Joking aside, I don't think there ever really was a lack of initiatives by entities (communities, companies, whatever) to create some sort of standard library (we typically tend to call them frameworks). There's just simply too much diversity, cultures and subcultures within the whole JavaScript sphere to ever get a global consensus on what that "standard" library then should look like. Not to mention the commercial entities with very real stakes in things they might not want to relinquish to some global unity consensus (as it may practically hurt their current bottom line).
  • collinmanderson 1y ago
    > Perhaps we need a common community effort to create a “distro” of curated and safe dependencies one can install safely, by analyzing the most popular packages and checking what’s common and small enough to be worth being included/forked. Debian is a common community effort to create a “distro” of curated and safe dependencies one can install safely. If you want stable, tested versions of software, only getting new versions every few years: https://packages.debian.org/stable/javascript/ https://packages.debian.org/stable/javascript/ If you want the newer versions of software, less tested, getting new versions continuously: https://packages.debian.org/unstable/javascript/ https://packages.debian.org/unstable/javascript/
  • silverwind 1y ago
    Node.js has been adding APIs that make it feasible to write stuff without dependencies, it's slowly getting there.
• GuB-42 1y ago
  > Shai Hulud Clever name... but I would have expected malware authors to be a bit less obvious. They literally named their giant worm after a giant worm. > At the core of this attack is a ~3.6MB minified bundle.js file Yep, even malware can be bloated. That's in the spirit of NPM I guess...
  • whynotmaybe 1y ago
    Malwares have to follow Moore's law, tequila virus was ~2.6kb in 1991.
    • arccy 1y ago
      not quite moore's law, growth at only 1.226x per year
  • jsheard 1y ago
    I suppose it's only a matter of time before one of these supply chain attacks unintentionally pulls in a second, unrelated supply chain attack.
    • beeflet 1y ago
      fish grow to the meet the size of the fishbowl
• nahuel0x 1y ago
  Languages/VMs should support capability-based permissions for libraries, no library should be able to open a file or do network requests without explicit granular permissions.
• danieldspx 1y ago
  Just notice guys it did not started with tinycolor. I had first reported it here, I am just not as popular haha My posts way before the issue was created: https://news.ycombinator.com/item?id=45252940 https://news.ycombinator.com/item?id=45252940 https://www.linkedin.com/posts/daniel-pereira-b17a27160_i-need-to-speak-to-someone-from-github-there-activity-7373418115398995968-FlGP https://www.linkedin.com/posts/daniel-pereira-b17a27160_i-ne...
  • deleted 1y ago
    [deleted]
• pingou 1y ago
  As a developer, is there a way on mac to limit npm file access to the specific project? So that if you install a compromised package it cannot access any data outside of your project directory?
  • mfro 1y ago
    Frankly, I am refusing to use npm outside of docker anymore.
  • freakynit 1y ago
    Wrote a small utility shell script that uses docker behind the scenes to prevent access to your host machine while still allowing full npm install and run workflow. https://github.com/freakynit/simple-npm-sandbox https://github.com/freakynit/simple-npm-sandbox Disclaimer: I am not Docker expert. Please review the script (sandbox.js) and raise any potential issues or suggestions. Thanks..
  • tredre3 1y ago
    You can run nodejs through `sandbox-exec` which is part of macos. I've never tried any of them but there's also a few wrappers specifically to do that, such as: https://github.com/berstend/node-safe https://github.com/berstend/node-safe Otherwise you're down to docker or virtualisation or creating one system user per project...
• redbell 1y ago
  Related (7 days ago): NPM debug and chalk packages compromised (1366 points, 754 comments): https://news.ycombinator.com/item?id=45169657 https://news.ycombinator.com/item?id=45169657
  • xrisk 1y ago
    Seems to be a separate incident?
    • nine_k 1y ago
      Separate? Yes. Unrelated? Hard to tell.
      • junon 1y ago
        It's unrelated in every observable technical way, but related in that it's a bit crazy how often this is happening to npm lately. I'm glad it wasn't this particular attack that hit me last week.
  • flanbiscuit 1y ago
    Related in that this is another, separate, attack on npm. No direct relation to the specific attack on debug/chalk/error-ex/etc that happened 7 days ago. The article states that this is the same attackers that got control of the "nx" packages on August 27th, which didn't really get a lot of traction on HN when it happened: https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=false&query=nx%20npm&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=fa...
• quotemstr 1y ago
  Jesus Christ. Another one? What the fuck? This isn't a JavaScript problem. What, structurally, stops the same thing happening to PyPI? Or the Rust ecosystem? Or Lisp via QuickLisp? Or CPAN? This whole mess was foreseeable. So what's to be done? Look. Any serious project needs to start vendoring its dependencies. People should establish big, coarse grained meta-distributions like C++ Boost that come from a trustable authority and that get updated infrequently enough that you can keep up with release notes.
  • lyu07282 1y ago
    Rust was hit by a similar attempt: https://github.com/rust-lang/crates.io/discussions/11889 https://github.com/rust-lang/crates.io/discussions/11889 Nothing much came of it, I don't know.
  • fulafel 1y ago
    They were new versions of the packages instead of modified existing ones so vendoring has the same effect as the usual practice of pinning npm deps and using npm ci, I think.
  • perlgeek 1y ago
    > This isn't a JavaScript problem. What, structurally, stops the same thing happening to PyPI? Or the Rust ecosystem? Or Lisp via QuickLisp? Or CPAN? For one, NPM has a really sprawling ecosystem where it's normal to have many dependencies. I remember that I once tried to get started with angular, and I did an "init" for an empty project and "compile", and suddenly had half a gigabyte of code lying in my directory. This means that there is a high number of dependencies that are potential targets for a supply chain attack. I just took a look at our biggest JS/Typescript project at work, it comes in at > 1k (recursive) NPM dependencies. Our biggest Python project has 78 recursive dependencies. They are of comparable size in terms of lines of code and total development time. Why? Differences in culture, as well as python coming with more "batteries included", so there's less need for small dependencies.
    • quotemstr 1y ago
      > For one, NPM has a really sprawling ecosystem where it's normal to have many dependencies. Agreed, but it's a difference of degree (literally --- graph in- and out-degree) not kind.
• zelias 1y ago
  How many packages now have been compromised over the past couple of weeks? The velocity of these attacks are insane. Part of me believes state actors must be involved at this point. In any case, does anyone have an exhaustive list of all recently compromised npm packages + versions across the recent attacks? We need to do an exhaustive scan after this news...
  • blueflow 1y ago
    > Part of me believes state actors must be involved at this point. Its less a technical but rather a moral hurdle. Its probably a bunch of teenagers behind it like how it was with the Mirai Botnet.
• cddotdotslash 1y ago
  I wonder who actually discovered this attack? Can we credit them? The phrasing in these posts is interesting, with some taking direct credit and others just acknowledging the incident. Aikido says: > We were alerted to a large-scale attack against npm... Socket says: > Socket.dev found compromised various CrowdStrike npm packages... Ox says: > Attackers slipped malicious code into new releases... Safety says: > The Safety research team has identified an attack on the NPM ecosystem... Phoenix says: > Another supply chain and NPM maintainer compromised... Semgrep says: > We are aware of a number of compromised npm packages
  • augzodia 1y ago
    OP article says: > The incident was discovered by @franky47, who promptly notified the community through a GitHub issue.
    • codazoda 1y ago
      Points to this, which does look like the first mention. https://github.com/scttcper/tinycolor/issues/256 https://github.com/scttcper/tinycolor/issues/256
  • jamesberthoty 1y ago
    Several individual developers seem to have noticed it at around the same time with Step and Socket pointing to different people in their blogs. And then vendors from Socket, Aikido, and Step all seem to have detected it via their upstream malware detection feeds - Socket and Aikido do AI code analysis, and Step does eBPF monitoring of build pipelines. I think this was widespread enough it was noticed by several people.
  • m4r71n 1y ago
    Since so many vendors discovered these packages seemingly independently, you'd think that they would share those mechanisms with NPM itself so that those packages would never be published in the first place. But I guess that removes their ability to sell an "early alert" mechanism through their offerings...
• liveoneggs 1y ago
  I guess it's still spreading? those blogs seem to list differences packages
• deanc 1y ago
  It's high time we took this seriously and required signing and 2FA on all publishes to NPM and NPM needs to start doing security scanning and tooling for this that they can charge organisations for.
• simultsop 1y ago
  Soon we'll see services like, havemysecretsbeenpwned.com check it against with your secrets xD given the malw seeks local creds. To my experience 80% of companies do not care about their secrets will/being exposed. There is this shallow belief that production will never be hacked
• mrbluecoat 1y ago
  > It deliberately skips Windows systems Reminds me of when I went to a tech conference with a Windows laptop and counted exactly two like me among the hundreds of attendees. I was embarrassed then but I'd be laughing now :D
  • 1970-01-01 1y ago
    ..for now. Safer to assume there was a todo in the code and not some anti-Linux agenda.
• gg2222 1y ago
  This blog post and others are from 'security saas' that also try to make money off how bad NPM package security safety is. Why can't npm maintainers just implement something similar? Maybe at least have a default setting (or an option) that packages newer than X days are never automatically installed unless forced? That would at least give time for people to review and notice if the package has been compromised. Also, there really needs to be a standard library or at least a central community approved library of safe packages for all standard stuff.
• brundolf 1y ago
  Last week someone wrote a blog post saying "We dodged a bullet" because it was only a browser-based crypto wallet scrape Guess we didn't dodge this one
  • debo_ 1y ago
    We didn't really dodge a bullet. We put a bullet named 'node' in the cylinder of a revolver, spun it, pointed the gun at our head, and pulled the trigger. We just happened to be lucky enough that we got an empty chamber.
• paulirish 1y ago
  This vulnerability was reported to NPM in 2016: https://blog.npmjs.org/post/141702881055/package-install-scripts-vulnerability https://blog.npmjs.org/post/141702881055/package-install-scr... https://www.kb.cert.org/vuls/id/319816 https://www.kb.cert.org/vuls/id/319816 but the NPM response was WAI.
  • rectang 1y ago
    Acronym expansion for those-not-in-the-know (such as me before a web search): WAI might mean "working as intented", or possibly "why?"
    • 201984 1y ago
      Thank you. It's frustrating when people uncommon acronyms without explaining them.
      • maxverse 1y ago
        AI is helpful for this, but I also built https://www.hackterms.com https://www.hackterms.com eight years ago for this exact reason.
        • Vinnl 1y ago
          And of course good old Urban Dictionary: https://www.urbandictionary.com/define.php?term=WAI https://www.urbandictionary.com/define.php?term=WAI
  • debazel 1y ago
    Even if we didn't have post install scripts wouldn't the malware just run as soon as you imported the module into your code during the build process, server startup, testing, etc? I can't think of an instance where I ran npm install and didn't run some process shortly after that imported the packages.
    • theodorejb 1y ago
• ChrisArchitect 1y ago
  Related: Active NPM supply chain attack: Tinycolor and 40 Packages Compromised https://news.ycombinator.com/item?id=45256210 https://news.ycombinator.com/item?id=45256210
  • bigwheels 1y ago
    (Additional context for Mr. Architect's Link Pasta: 33 comments, 1 day ago)
• theodorejb 1y ago
  It's crazy to me that npm still executes postinstall scripts by default for all dependencies. Other package managers (Pnpm, Bun) do not run them for dependencies unless they are added to a specific allow-list. Composer never runs lifecycle scripts for dependencies. This matters because dependencies are often installed in a build or development environment with access to things that are not available when the package is actually imported in a browser or other production environment.
  • notatallshaw 1y ago
    Seems like this is a fairly recent change, for Pnpm at least, https://socket.dev/blog/pnpm-10-0-0-blocks-lifecycle-scripts-by-default https://socket.dev/blog/pnpm-10-0-0-blocks-lifecycle-scripts... What has been the community reaction? Has allowing scripts been scalable for users? Or could it be described as people blindly copying and pasting allow commands? I am involved in Python packaging discussions and there is a pre-proposal (not at PEP stage yet) at the moment for "wheel variants" that involves a plugin architecture, a contentious point is whether to download and run the plugins by default. I'd like to find parallels in other language communities to learn from.
    • theodorejb 1y ago
      In my experience, packages which legitimately require a postinstall script to work correctly are very rare. For the apps I maintain, esbuild is the only dependency which benefits from a postinstall script to slightly improve performance (though it still works without the script). So there's no scaling issue adding one or two packages to a whitelist if desired.
  • LelouBil 1y ago
    I'm also wondering why huge scale attacks like this don't happen for other package managers. Like, for rust, you can have a build.rs file that gets executed when your crate is compiled, I don't think it's sandboxed. Or also on other languages that will get run on development machines, like python packages (which can trigger code only on import), java libraries, etc... Like, there is the post install script issue or course, but I feel like these attacks could have been just as (or almost as) effective in other programming languages, but I feel like we always only hear about npm packages.
• achristmascarl 1y ago
  The number of packages is now up to 180 (or more, depending on which source you're looking at)
• m3kw9 1y ago
  Is using any type of NPM type stuff a no go? Who reads the code and verifies is secure?
  • theruss 1y ago
    Other than the maintainer (which isn't of course guaranteed) no-one other than it being incumbent on userland deployment, and those deploying a lib into a project to review the code.
• Liskni_si 1y ago
  Is there any way to install CLI tools from npmjs without being affected by a recent compromise? Rust has `cargo install --locked`, which will use the pinned versions of dependencies from the lockfile, and these lockfiles are published for bin packages to crates.io. But it seems npmjs doesn't allow publishing lockfiles, neither for libraries nor for CLI tools, so if you try to install let's say @google/gemini-cli, it will just pull the latest dependencies that fit the constraints in package.json. Is that true? Is it really this bad? If you try to install a CLI tool on a bad day when half of npmjs is compromised, you're out of luck? How is that acceptable at all?
  • junon 1y ago
    Lock files wouldn't work if they were locking transitive dependencies; otherwise the version solver would not have any work to actually do and you'd have many, many versions of the same package rather than a few versions that satisfy all of the version range constraints. Lots of good ideas since last week, the one I like most being that published packages, especially those that are high in download count, don't actually go publish for a while until after publishing, allowing security scanners to do their thing.
    • Liskni_si 1y ago
      In the Rust ecosystem, you only publish lock files for binary crates. So yeah then you get churn like https://github.com/cargo-bins/cargo-binstall/releases/tag/v1.14.2 https://github.com/cargo-bins/cargo-binstall/releases/tag/v1... bumping transitive deps, but this churn/noise doesn't exist for library crates - because the lock file isn't published for them.
      • the8472 1y ago
        lib crates have been checking in their Cargo.lock for a while now. https://github.com/rust-lang/cargo/pull/12382 https://github.com/rust-lang/cargo/pull/12382
        • Liskni_si 1y ago
• ebfe1 1y ago
  Anyone know if there is a public events feed/firehouse for npm ecosystem system? Similar to GitHub public events feed? We, at ClickHouse, love big data and it would be super cool download and analyse patterns of all these data & provide some tooling to help with combatting this wide spread issue.
• g42gregory 1y ago
  Are Python packaging systems like pip exposed to the same risks? Is anybody looking at this?
  • LPisGood 1y ago
    Software supply chain attacks are well known and they are a massive hole in the entirety of software infrastructure. As usual with security, no one really cares that much.
  • nromiun 1y ago
    Not to the same extent as NPM. Because Python has a good standard library and library authors are not deathly afraid of code duplication like JS devs, for example micro libraries like left-pad, is-even etc.
    • AnotherGoodName 1y ago
      Also there’s more of a habit to release to the pre release channel for some time first. I honestly think a forced time spent in pre release (with some emergency break glass where community leaders manually review critical hotfixes) could mitigate 99% of the issues here. Linux packages have been around for ever and have fewer incidents mainly because of the long dev->release channel cooking time.
      • g42gregory 1y ago
        Forced time in pre-release sounds like a really good idea. Can somebody drive this up the chain to people who administer npm?
    • Klonoar 1y ago
      The weird dig at JS as a community is wholly unnecessary. Python as an ecosystem is just as vulnerable to this crap - and they’ve had their own issues with it. You can reference that and leave the color commentary at the door.
      • 1y ago
• 1970-01-01 1y ago
  Yes, cybersecurity is absolutely a cost center. You can pay for it the easy way, the hard way, or the very hard way. Looks like we're fixing NPM the very hard way.
• indigodaddy 1y ago
  Ironically I started seeing a message in GitHub saying 2fa will be auto-enforced shortly. Wonder if that is a sign of similar for npm packaging? Or wonder if GitHub is enforcing 2fa soon because of the NPM CVEs potential to harvest GitHub creds?
  • keyle 1y ago
    2FA is the first steps is stopping the onslaught. But it still doesn't stop infected developer machines to silently update code and wait for the next release patiently. It would require the diligence of those developers to check every line of code that goes out with a release... which is a lot to ask for someone who fell for a fishing email.
• herpdyderp 1y ago
  I wouldn't mind a simple touch id (or password) requirement every time I run `npm publish` to help prevent such an attack.
• racl101 1y ago
  Maybe stupid question here. And forgive my ignorance. But does yarn or deno suffer from the same issues? That is do they get their packages from npm repositories? I've never used these.
  • illusive4080 1y ago
    Yes.
  • deleted 1y ago
    [deleted]
• kelnos 1y ago
  As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embedded malware. One thing I was thinking of was sort of a "delayed" mode to updating my own dependencies. The idea is that when I want to update my dependencies, instead of updating to the absolute latest version available of everything, it updates to versions that were released no more than some configurable amount of time ago. As a maintainer, I could decide that a package that's been out in the wild for at least 6 weeks is less likely to have unnoticed malware in it than one that was released just yesterday. Obviously this is not a perfect fix, as there's no guarantee that the delay time I specify is enough for any particular package. And I'd want the tool to present me with options sometimes: e.g. if my current version of a dep has a vulnerability, and the fix for it came out a few days ago, I might choose to update to it (better eliminate the known vulnerability than refuse to update for fear of an unknown one) rather than wait until it's older than my threshold.
  • CraftThatBlock 1y ago
    pnpm just added this: https://pnpm.io/blog/releases/10.16 https://pnpm.io/blog/releases/10.16
    • jauntywundrkind 1y ago
      minimumReleaseAge is pretty good! Nice!! I do wish there were some lists of compromised versions, that package managers could disallow from.
    • thepill 1y ago
      bun is also working on it: https://github.com/oven-sh/bun/issues/22679 https://github.com/oven-sh/bun/issues/22679
    • philipwhiuk 1y ago
      Aren't they found quickly because people upgrade quickly?
• sim7c00 1y ago
  [flagged]
• illusive4080 1y ago
  At this time should we just consider all of npm unsafe for installing new packages? Installing a single package could install hundreds of transient dependencies.
  • meindnoch 1y ago
    Yes. Also, no need for "at this time".
• pier25 1y ago
  So glad I left JS for backend last year. It was a big effort switching to a new language and framework (still is) but it looks like so far the decision was worth it. I'm still looking at Bun and all the effort they're doing with built-in APIs to reduce (and hopefully eliminate) third party deps. I would prefer using TS for the whole stack if possible but not at the expense of an insecure backend ecosystem.
  • nbf_1995 1y ago
    Just curious, what did you switch to?
    • pier25 1y ago
      dotnet
• devwastaken 1y ago
  npm should be banned and illegal to work with.
  • touristtam 1y ago
    The same could be said of quite a few equivalent in other programing languages.
• naasking 1y ago
  This is a product of programming languages continuing to ignore the lessons from capability security. The fact that packages in your programming language even have the ability to any of the things listed in these articles by default is an embarrassing, abject failure of our profession.
• 2OEH8eoCRo0 1y ago
  It's amazing how we attack normies for downloading random software but we will load our projects with hundred of dependencies we don't audit ourselves.
• pragma_x 1y ago
  So, other packaging environments have a tendency to slow down the rate of change that enters the user's system. Partly through the labor of re-packaging other people's software, but also as a deliberate effort. For instance: Ubuntu or RedHat. Is anyone doing this in a "security as a service" fashion for JavaScript packages? I imagine a kind of package escrow/repository that only serves known secure packages, and actively removes known vulnerable ones.
  • kilobaud 1y ago
    I've worked in companies that do this internally, e.g., managed pull-through caches implemented via tools like Artifactory, or home-grown "trusted supply chain" automation, i.e., policy enforcement during CI/CD prior to actually consuming a third-party dependency. But what you describe is an interesting idea I hadn't encountered before! I assume such a thing would have lower adoption within a relatively fast-moving ecosystem like Node.js though. The closest thing I can think of (and this isn't strictly what you described) is reliance on dependabot, snyk, CodeQL, etc which if anything probably contributes to change management fatigue that erodes careful review.
    • kjok 1y ago
      > managed pull-through caches implemented via tools like Artifactory This is why package malware creates news, but enterprises mirroring package registries do not get affected. Building a mirroring solution will be pricey though mainly due to high egress bandwidth cost from Cloud providers.
    • tom1337 1y ago
      How does a pull-through cache prevent this issue? Wouldn’t it also just pull the infected version from the upstream registry?
      • pragma_x 1y ago
        I think it's implied that packages can be blocked and/or evicted from said cache administratively. This deliberately breaks builds, and forces engineers to upgrade/downgrade away from bad packages as needed.
• diffrinse 1y ago
  I had just seen some guy on TikTok pushing `mcp-knowledge-graph` the other day
• foobarbecue 1y ago
  Does anyone know when @ctrl/tinycolor 4.1.1 was released exactly? Trying to figure out the infection timeline relative to my tools.
  • foobarbecue 1y ago
    Never mind, got it: ~$ npm view @ctrl/tinycolor --json | grep 4.1.1 "4.1.1": "2025-09-15T19:52:46.624Z",
• deleted 1y ago
  [deleted]
• OfficeChad 1y ago
  [dead]
• ayaros 1y ago
  Each one of these posts makes me feel better about having no dependencies on my current project, other than Gulp, which I could replace if I had to. But also I miss having things like spare time, and sleep, so perhaps the tradeoff wasn't worth it
• zemlyansky 1y ago
  Would strict containerization help here? (rootless, read-only partial fs access, only the necessary env variables passed, etc)
• flykespice 1y ago
  Another day, another npm compromise Time to add developer ID's verification /s
• parhamn 1y ago
  For a large subset of packages (like the browser ones), as a layman, it seems feasible to do static analysis for: 1) fetch calls 2) obfuscation (like sketchy lookup tables and hex string construction) Like for (1) the hostname should be statically resolvable and immutable. So you can list the hostnames it fetches from as well. Is this feasible or am I underestimating the difficulty? Javascript seems to have no shortage of static analysis tools.
  • TheDong 1y ago
    There are many ways to "eval" in javascript, and static analysis can only work if that's also statically disallowed. Unfortunately, eval is still used in a lot of code, so disabling it isn't trivially viable, and with eval present, detecting fetch calls and such statically becomes the halting problem.
• foxfired 1y ago
  My problem is that, in the JS ecosystem, every single time you go through a CI/CD pipeline, you redownload everything. We should only download the first time and with the versions that are known to work. When we make a manual update to version, than only that should be downloaded once more. I just checked one of our repos right now and it has a 981 packages. It's not even realistic to vet the packages or to know which one is compromised. 99% of them are dependencies of dependencies. Where do we even get started?
  • amarshall 1y ago
    Redownloading everything isn’t a risk when the lock file contains a hash of the download on first update.
  • brw 1y ago
    Isn't that what lockfiles are for? By default `npm i` downloads exactly the versions specified in your lockfile, and only resolves the latest versions matching the ranges specified in package.json if no lockfile exists. But CI/CD pipelines should definitely be using `npm ci` instead, which will only install packages from a lockfile and throws an error if it doesn't exist.
    • touristtam 1y ago
      That and pin that damn version!
      • AndreasHae 1y ago
        It’s still ridiculous to me that version pinning isn’t the default for npm. The first thing I do for all of my projects is adding a .npmrc with save-exact=true
        • silverwind 1y ago
          save-exact is mostly useless against such attacks because it only works on direct dependencies.
• lxe 1y ago
  I'm surprised this is happening now, and not 10 years ago.
  • keyle 1y ago
    We're seeing it now... NPM gets a lot of traffic, there might be other package managers out there, in different languages, that may have been infected in the past and simply don't get the same amount of eyeballs.
• swatkat7 1y ago
  Perhaps set `minimumReleaseAge > 1440` in pnpm config until this is fixed.
• kafrofrite 1y ago
  It's probably not trivial to implement and there's already a bunch of problems that need solving (e.g., trusting keys etc.) but... I think that if we had some sort of lightweight code provenance (on top of my head commits are signed from known/trusted keys, releases are signed by known keys, installing signed packages requires verification), we could probably make it somewhat harder to introduce malicious changes. Edit: It looks like there's already something similar using sigstore in npm https://docs.npmjs.com/generating-provenance-statements#about-npm-provenance https://docs.npmjs.com/generating-provenance-statements#abou.... My understanding is that its use is not widespread though and it's mostly used to verify the publisher.
  • yawaramin 1y ago
    I think that depends on...how are these malicious changes actually getting into these packages? It seems very mysterious to me. I wonder why npm isn't being very forthcoming about this?
• ibejoeb 1y ago
  NPM needs some kind of attestation mechanism. There needs to be an independent third party that that has the fingerprint, and then npm must verify it before a change is published. It could even be just DNS or well-known URI that, if changed, triggers lockdown. Then, even in the case of a successful compromise of an NPM account or source control, whether via phishing like the last one or token exfiltration like this one, it will remain unpublished.
• hacker_homie 1y ago
  I’m not sure language package mangers were a good idea at all. Dependencies were supposed to be painful. If the language needed some functionality built in it was supposed to go into the standard library, I understand that for JS this isn’t feasible.
  • chromanoid 1y ago
    Nah, package managers are always the "civilization" moments of programming.
  • 63 1y ago
    There was a very similar discussion on lobsters the other day. You might be interested in reading it. In general, I agree with the idea that writing everything yourself results in a higher quantity of low quality software with security issues and bugs, as well as a waste of developers' time. That said, clearly supply chain attacks are a very real threat that needs to be addressed. I just don't think eliminating package managers is a good solution. https://lobste.rs/s/zvdtdn https://lobste.rs/s/zvdtdn
  • Sankozi 1y ago
    It is not package managers. It is due to the poor NPM ecosystem: lots of crappy packages (like left-pad), auto updates, lots of dependencies, post install scripts, insecure language. These security problems happen much less often in other ecosystems. There is nothing even remotely as bad as NPM.
• LAC-Tech 1y ago
  At least they're not re-inventing the wheel though!!
• neya 1y ago
  I have been telling people for ages - Javascript is a pack of cards. We have progressed as a society and have so many alternatives for everything, and yet, we still haven't done anything about Javascript being forced down onto us by browsers. If it wasn't for web browsers, JS would have become irrelevant so fast because of how broken it is - both as a language and its ecosystem. On the contrary - almost being a decade into Elixir - most of the time, I don't need (and I don't like) using external dependencies. I can just write something myself in a matter of just an hour or so because it's just so easy to do it myself. And everything I've written till date hasn't required an audit or re-write every 6 months or sometimes, even for years. We all seem to hate the concept of Nazis and yet somehow we have done nothing about the Nazi-est language of them all which literally has no other alternatives to run on web browsers?
  • deleted 1y ago
    [deleted]
• MonkeyIsNull 1y ago
  For those of you without a security dept, hopefully this is of some help: https://github.com/Cobenian/shai-hulud-detect https://github.com/Cobenian/shai-hulud-detect more updates soon and PRs welcome.
• DarkmSparks 1y ago
  Wow it got everything, aws keys, gcp keys, github tokens, thats a lot of cryptocoin mining instances that are going to be spun up. And a lot of unexpected bills people are going to be getting... They really shouldn't have been stored unencrypted on peoples machines.... Ouch.
• totetsu 1y ago
  I was just reading an article in Foreign Affairs that was discussing a possible future with an increased separation of science and technological developments between China and The West. And it occurred to me, what would such a siloed landscape mean for OSS and basically the whole web infrastructure as it is today, shared and open for anyone in any country. I think this kind of malware becoming pervasive could be the failure state if this future becomes reality.
  • lyu07282 1y ago
    I always thought open source in a purely profit driven society was always a bit contradictory, but it's like the wikipedia. There is just something innate in people that makes them care for their craftsmanship and their community with zero profit incentive, despite the prevailing ideology telling us that it ought to be impossible and surely about to collapse any moment now. OSS will prevail no matter Microsoft's disastrous and irresponsible stewardship of a smallish portion of it.
  • Garnish0062 1y ago
    May I ask which article it was? The Once and Future China?
    • totetsu 1y ago
      Thats the one
• utbabya 1y ago
  Blog author company's runner detects anomalies in them, but we shouldn't need a product for this. Detecting outbound network connection during an npm install is quite cheap to implement in 2025. I think it comes down to tenant and incentives, if security is placed as first priority as it should, for any computing service and in particular for supply chain like package management, this would be built in. One thing that comes to mind that would make it a months long deabte is the potential breakage of many packages. In that case as a first step just make an eye catching summary post install, with gradual push to totally restriction with something like a strict mode, we've done this before. Which, reminds me of another long standing issue with node ecosystem toolings, information overload. It's easy to bombard devs with thesis character count then blame them for eventually getting fatigue and not reading the output. It takes effort to summarize what's most important with layered expansion of detail level, show some.
  • killerstorm 1y ago
    "Outbound network connection at npm install" is just one of many ways malware in NPM package can manifest itself. E.g. malware might be executed when you test code which uses the library, or when you run a dev server, or on a deployed web site. The entire stack is built around trusting a code, letting it do whatever it wants. That's the problem.
    • utbabya 1y ago
      Trust is hard, it all comes down to trust no matter what you do. The more general idea is sandboxed build, it doesn't eliminate all problems but one class.
• cyrnel 1y ago
  Code signing, 2FA, and reducing dependencies are all incomplete solutions. What we need is fine-grained sandboxing, down to the function and type level. You will always be vulnerable as long as you're relying on fallible humans (even yourself) to catch or prevent vulnerabilities. Apparently they've tried to implement this in JavaScript but the language is generally too flexible to resist a malicious package running in the same process. We need to be using different languages with runtimes that don't allow privileged operations by default.
  • 9dev 1y ago
    That doesn’t solve it either. If you need to grant hundreds of permissions, people will just hand-wave them all—remember the UAC debacle in Windows Vista? I like Denos approach way better; and you could also ask why any application can just read files in your home folder, or make network requests to external hosts. OSes really are part of the equation here.
• easterncalculus 1y ago
  Time for a Butlerian Jihad.
• deleted 1y ago
  [deleted]
• shirro 1y ago
  For years everyone in the programming community has been pushing for convenience and features and code reuse and its got to the point I think the ease of adding a third party package from the languages package manager or github needs to be seriously questioned by security conscious devs. Perhaps we made the wrong things easy.
• aorth 1y ago
  In the story about the Nx compromise a few weeks ago someone posted a neat script that uses bubblewrap on Linux to run tools like npm more safely by confining their filesystem access. https://news.ycombinator.com/item?id=45034496 https://news.ycombinator.com/item?id=45034496 I modified the script slightly based on some of the comments in the thread and my own usage patterns: #!/usr/bin/env bash # # See: https://news.ycombinator.com/item?id=45034496 bin=$(basename "$0") echo "===========================" echo "Wrapping $bin in bubblewrap" echo "===========================" exec bwrap \ --bind ~/.cache ~/.cache \ --bind "${PWD}" "${PWD}" \ --dev /dev \ --die-with-parent \ --disable-userns \ --new-session \ --proc /proc \ --ro-bind /etc/ca-certificates /etc/ca-certificates \ --ro-bind /etc/resolv.conf /etc/resolv.conf \ --ro-bind /etc/ssl /etc/ssl \ --ro-bind /usr /usr \ --setenv PATH /usr/bin \ --symlink /usr/bin /bin \ --symlink /usr/bin /sbin \ --symlink /usr/lib /lib \ --symlink /usr/lib64 /lib64 \ --tmpfs /tmp \ --unshare-all \ --unshare-user \ --share-net \ /usr/bin/env "$bin" "$@" Put this in `~/.local/bin` and symlink it to `~/.local/bin/npm` and `~/.local/bin/yarn` (and make sure `~/.local/bin` is first in your `$PATH`). I've been using it to wrap npm and yarn successfully in a few projects. This will protect you against some attacks that use postinstall scripts to do nefarious things outside the project.
  • whilenot-dev 1y ago
    > --bind "${PWD}" "${PWD}" Pardon my ignorance, but couldn't a malicious actor just redefine $PWD before calling a npm script?
    • internet_points 1y ago
      The above script wraps npm. PWD gets evaluated before npm is called (so PWD is expanded in the "outside" environment). Of course, if your malicious actor has access to your environment already, they can redefine PWD, but that's assuming you're already compromised. This bwrap script is to avoid that malicious actor running malicious install scripts in the first place. However, I don't think it protects you against stuff like `npm install compromised-executable && node_modules/.bin/execute-compromised-executable` – then you'd have to bwrap that second call as well. Or just bwrap bash to get a limited shell.
• pxc 1y ago
  Letting upstream authors write code that the package manager runs at install time isn't a sane thing for package managers to allow. It promotes all kinds of hacky shit and makes packages harder to work with programmatically, and it also provides this propagation vector. Packages also shouldn't have arbitrary network access at build time for both of those two same reasons! There's been a lot of talk here about selecting and auditing dependencies, which is fine and good. But this attack and lots of other supply chain attacks would also be avoided with a better-behaved package manager. Doesn't Deno solve this? Do any other JS package managers do some common-sense sandboxing? Yes, migration is painful. Yes, granular permissions are more annoying to figure out than anything-can-do-anything. But is either as painful as vendoring/forking your dependencies without the aid of a package manager altogether? If you're really considering just copying and pasting instead of using NPM, maybe you should also consider participating in a saner package ecosystem. If you're ready to do the one, maybe you're ready to do the other.
  • deleted 1y ago
    [deleted]
• snickerbockers 1y ago
  I try to stay as far from web development as possible in my programming career (kernel/drivers and most recently reverse engineering) so maybe I'm ill-informed here but this npm thing seems to be uniquely terrible at security and i cannot fathom why the entire web seems to be automatically downloading updates from it and pushing them into production with no oversight. I've always worked at companies where we use third party open source libraries utilities and its true that they get less-than-ideal amount of auditing when they get updated but at least we're not constantly pushing updates of to our customers solely for the sake of using the latest version. In fact usually they're out of date by several years which is also a problem but generally there'll be a guy following the mailing lists for updates in case there's a known exploit that needs to be patched.
  • jefozabuss 1y ago
    I think all public package registries have this problem as it's not unique to npm. The "blind" auto updating to latest versions seems to be also an issue here, simply you cannot trust it enough as there is (seemingly) no security vetting process (I mean if you get obfuscated gibberish pushed into a relatively sanely written codebase it should ring some alarms somewhere). Normally you'd run tests after releasing new versions of your website but you cannot catch these infected parts if they don't directly influence the behavior of your functionality.
  • SCdF 1y ago
    A lot of it is just that it's at the local maximum of popularity and relative user inexperience, so it's the juiciest target. But also, npm was very much (like js you could argue) vibed into existence in many ways, eg with the idea of a lock file (eg reproducible builds) _at all_ taking a very long time to take shape.
    • ricardobeat 1y ago
      We got lockfiles in 2016 (yarn) and 2017 (npm), before Go, Ruby, and others; I believe python is just getting a lockfile standard approved now. You could already specify exact versions in your package.json, same as a Gemfile, but reality is that specifying dependencies by major version or “*” was considered best practice, to always have the latest security updates. Separating version ranges from the lock files, and requiring explicit upgrades was a change in that mindset – and mostly driven by containerization rather than security or dev experience.
• joelthelion 1y ago
  This seems like a great opportunity for someone to push a smaller but fully audited subset of the npm repos. Corporations would love it.
• david-james-2 1y ago
  I set "ignore-scripts=true" (https://docs.npmjs.com/cli/v11/using-npm/config#ignore-scripts https://docs.npmjs.com/cli/v11/using-npm/config#ignore-scrip...) in npmrc(5). This changed the defaults for npm(1). The Semgrep blog under "Additional NPM Registry Security Advice / Reducing Run Scripts" says "reducing" not "ignoring". I need to check if there are still "run scripts" even with this setting. Also I need to check if there is the same class of vulnerabilities in other package managers I use, like emacs(1) (M-x package-install), mvn(1) (Maven, Java), clj(1) (deps.edn, Clojure), luarocks(1) (Lua), deps(1) (deps.fnl, Fennel), nbb(1) (deps.edn, Node.js babashka). Although some do not have "run scripts" feature, I need to make sure.
• amai 1y ago
  NPM belongs to Microsoft. What kind of security do you expect?
  • pier25 1y ago
    You're saying this as if big corps, banks, etc weren't using dotnet.
    • amai 1y ago
      They should not. Microsoft lost the master key to the Azure cloud in 2023. Just now they have this issue: https://www.wired.com/story/microsoft-entra-id-vulnerability-digital-catastrophe/ https://www.wired.com/story/microsoft-entra-id-vulnerability... MS stands for minimal security.
• enricotr 1y ago
  Be accountable for what deploy if paid, except explicit other deal. Like in real jobs. Next...
  • huem0n 1y ago
    None of these were paid
• whatever1 1y ago
  Isn’t this a good case for LLMs? Audit at compile time all of the dependencies?
  • huem0n 1y ago
    Please no, see > Using CVE reports as a weapon https://www.youtube.com/watch?v=GDdlRiThDeg https://www.youtube.com/watch?v=GDdlRiThDeg
    • whatever1 1y ago
      Oh you took it further, let the LLM take the wheel. I was just referring to the LLM raising a red flag during compilation. So worst case scenario it will just raise a false positive.
• user3939382 1y ago
  You guys win, JS is actually fantastic and this headline is great.
• huem0n 1y ago
  New Npm vuln? Other shocking news: today is Tuesday
• pier25 1y ago
  Shai-hulud huh? Maybe related to the Russian hacker group Sandworm? https://en.wikipedia.org/wiki/Sandworm_(hacker_group) https://en.wikipedia.org/wiki/Sandworm_(hacker_group)
  • deleted 1y ago
    [deleted]
• cammil 1y ago
  Why cant we hash libraries and trusted parties publish security checked hashes?
• nerdponx 1y ago
  What's stopping supply chain attacks like this from happening in other languages like Python, or even in source repos via compromised forge accounts like Github? Artifact/commit signing is optional, so while 2FA fortunately is becoming mandatory, if the maintainer never used signing then this could happen to PyPI just as well as NPM, no? Or is NPM uniquely vulnerable for some reason?
• salterdavid032 1y ago
  [dead]
• phtrivier 1y ago
  Is there a link to a script to check if your project is affected ? Or is "yarn audit" enough ? (Of course we would not pipe the link to a shell, and we would read it beforehand :D )
• rpodraza 1y ago
  Someone should eradicate the npm ecosystem and start from scratch. No sane package manager would allow to run arbitrary scripts or download stuff from God knows where, like random github repos.
  • Aperocky 1y ago
    npm is now a private company right? It does also look like they have already gone through enshittification and don't even seem to have publicly acknowledged this attack.
• petetnt 1y ago
  The real key takeaway here is that Microsoft could fix this of they wanted: they have near infinite resources, the best people and more heavily invested in open source than anyone else in the business, but still refuse to even comment on the situation.