29 ms·

NPM debug and chalk packages compromised

• fareesh 1y ago
  i use node/npm moderately is there a runnable command to determine if the package list has a compromised version of anything?
• alaintno 1y ago
  How is it possible that this code (line 9 of the index.js) isn't present in the source github repo, but can be seen in the beta feature of npmjs.com? Also, the package 1.3.3 has been downloaded 0 times according to npmjs.com, how can the writer of this article has been able to detect this and not increment the download counter?
  • DDerTyp 1y ago
    The discrepancy comes from how npm packages are published. What you see on GitHub is whatever the maintainer pushed to the repo, but what actually gets published to the npm registry doesn’t have to match the GitHub source. A maintainer (or someone with access) can publish a tarball that includes additional or modified files, even if those changes never appear in the GitHub repo. That’s why the obfuscated code shows up when inspecting the package on npmjs.com. As for the “0 downloads” count: npm’s stats are not real-time. There’s usually a delay before download numbers update, and in some cases the beta UI shows incomplete data. Our pipeline picked up the malicious version because npm install resolved to it based on semver rules, even before the download stats reflected it. Running the build locally reproduced the same issue, which is how we detected it without necessarily incrementing the public counter immediately.
    • alaintno 1y ago
      I see, thanks for the explanations, and thanks for warning us about this!
    • Jenk 1y ago
      It can also be that the repo was modified after a release.
  • behindsight 1y ago
    > How is it possible that this code (line 9 of the index.js) isn't present in the source github repo, but can be seen in the beta feature of npmjs.com You may also be interested in npm package provenance [1] which lets you sign your npm published builds to prove it is built directly from the source being displayed. This is something ALL projects should strive to setup, especially if they have a lot of dependent projects. 1: https://github.blog/security/supply-chain-security/introducing-npm-package-provenance/ https://github.blog/security/supply-chain-security/introduci...
• DDerTyp 1y ago
  Update: It seems like all packages of the author got hacked.
• artooro 1y ago
  This looks pretty bad. Even if this only affects crypto wallets, I can't help but imagine how much worse this could be. Another good read is at https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...
  • dang 1y ago
    (This was originally posted to https://news.ycombinator.com/item?id=45168413 https://news.ycombinator.com/item?id=45168413 but we merged the threads)
• DDerTyp 1y ago
  It looks like a lot of packages of the author have been compromised (in total over 1 billion downloads). I've updated the title an added information to the blog post.
• junon 1y ago
  Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3266885191 https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-convert@3.1.1 - color-name@2.0.1 - is-arrayish@0.3.3 - slice-ansi@7.1.1 - color@5.0.1 - color-string@2.1.1 - simple-swizzle@0.2.3 - supports-hyperlinks@4.1.1 - has-ansi@6.0.1 - chalk-template@1.1.1 - backslash@0.2.1 It looks and feels a bit like a targeted attack. Will try to keep this comment updated as long as I can before the edit expires. --- Chalk has been published over. The others remain compromised (8 Sep 17:50 CEST). NPM has yet to get back to me. My NPM account is entirely unreachable; forgot password system does not work. I have no recourse right now but to wait. Email came from support at npmjs dot help. Looked legitimate at first glance. Not making excuses, just had a long week and a panicky morning and was just trying to knock something off my list of to-dos. Made the mistake of clicking the link instead of going directly to the site like I normally would (since I was mobile). Just NPM is affected. Updates to be posted to the `/debug-js` link above. Again, I'm so sorry.
  • jap 1y ago
    Could happen to anyone, many thanks for addressing this quickly.
  • dboreham 1y ago
    Sorry to be dumb, but can you expand a bit on "2FA reset email..." so the rest of us know what not to do?
    • junon 1y ago
      Ignore anything coming from npm you didn't expect. Don't click links, go to the website directly and address it there. That's what I should have done, and didn't because I was in a rush. Don't do security things when you're not fully awake, too. Lesson learned. The email was a "2FA update" email telling me it's been 12 months since I updated 2FA. That should have been a red flag but I've seen similarly dumb things coming from well-intentioned sites before. Since npm has historically been in contact about new security enhancements, this didn't smell particularly unbelievable to my nose. The email went to the npm-specific inbox, which is another way I can verify them. That address can be queried publicly but I don't generally count on spammers to find that one but instead look at git addresses etc The domain name was `npmjs dot help` which obviously should have caught my eye, and would have if I was a bit more awake. The actual in-email link matched what I'd expect on npm's actual site, too. I'm still trying to work out exactly how they got access. They didn't technically get a real 2FA code from the actual, I don't believe. EDIT: Yeah they did, nevermind. Was a TOTP proxy attack, or whatever you'd call it. Will post a post-mortem when everything is said and done.
• diggan 1y ago
  > Yes, I've been pwned. First time for everything, I suppose. It was a 2FA reset email that looked shockingly authentic. I should have paid better attention, but it slipped past me. Sincerely sorry, this is embarrassing. My worst nightmare is to wake up, see an email like that and hastily try to recover it while still 90% asleep, compromising my account in the process. However, I think I can still sleep safe considering I'm using a password manager that only shows up when I'm on the right domain. A 2FA phishing email sending me to some unknown domain wouldn't show my password manager on the site, and would hence give me a moment to consider what's happening. I'm wondering if the author here wasn't using any sort of password manager, or something slipped through anyways? Regardless, fucking sucks to end up there, at least it ends up being a learned lesson for more than just one person, hopefully. I sure get more careful every time it happens in the ecosystem.
  • hunter2_ 1y ago
    I agree, and this is arguably the best reason to use a password manager (with the next being lack of reuse which automatically occurs if you use generated passwords, and then the next being strength if you use generated passwords). I generally recommend Google's to any Android users, since it suggests your saved password not only based on domain in Chrome browser, but also based on registered appID for native apps, to extend your point. I'm not sure if third party password managers do this, although perhaps it's possible for anti-monopoly reasons?
    • tracker1 1y ago
      I'm a pretty big fan of BitWarden/VaultWarden myself... though relatively recently something changed on my Android phone in that the password fills aren't working from inside my browser, I have to copy/paste from the app, which is not only irritating but potentially less safe.
      • Dayshine 1y ago
        Consider adding the widget/action to your quick actions: then to don't need to copy paste at least
• nodesocket 1y ago
  This is terrifying. Reminder to store your crypto in a hardware based wallet like Ledger not browser based. Stay frosty when making transfers from exchanges.
  • artooro 1y ago
    While true, this is also an eye opening event of how much worse it could be if it was more generic and not limited to crypto wallet addresses.
    • nodesocket 1y ago
      Seems like exchanges should have a confirmation screen that shows the destination addresses from XHR requests before processing, though I suppose the malicious script could just change the DOM showing the address you entered instead of the modified address it injected.
  • nixosbestos 1y ago
    How is it terrifying? They clicked through a 2FA reset email, a process that I have never, and will never need to go through, and seemingly one that they didn't even initiate.
    • nodesocket 1y ago
      Like you’ve never made a mistake before. Blatantly blaming the maintainer is unfair. They made a mistake, it happens.
      • nixosbestos 1y ago
        No, I have never, ever responded to an explicit ask to reset the most important security feature of my accounts, without me initiating it, and I use a password manager (lol) so, no, I will never, ever encounter this problem. Because I care about my data, safety, and integrity, and my users'. There's literally no reason ever why I would or will do a 2FA reset. It does happen, yes, it's not terrifying.
• andrewmcwatters 1y ago
  @junon, if it makes you feel any better, I once had a Chinese hacking group target my router and hijack my DNS configuration specifically to make "amazon.com" point to 1:1 replica of the site just to steal my Amazon credentials. There was no way to quickly visualize that the site was fake, because it was in fact, "actually" amazon.com. Phishing sucks. Sorry to read about this. Edit: To other readers, yes, the exploit failed to use an additional TLS attack, which was how I noticed something was wrong. Otherwise, the site was identical. This was many years ago before browsers were as vocal as they are now about unsecured connections.
  • nixosbestos 1y ago
    That's not... how that works, unless you clicked through a very loud, obvious TLS warning.
    • jowea 1y ago
      Yeah that sounds weird. Certificate pinning and HSTS should protect from that, right?
  • thehamkercat 1y ago
    What about SSL?
  • bix6 1y ago
    Any write up? I would like to learn more to avoid.
    • dns_snek 1y ago
      The exact attack they described is less of an issue these days due to HSTS and preloading, but: - make sure you're connected to the expected official domain (though many companies are desensitizing us to this threat by using distinct domains instead of subdomains for official business) - make sure you're connected over HTTPS (this was most likely their issue) - use a password manager which remembers official domains for you and won't offer to auto-fill on phishing sites - use a 2FA method that's immune to phishing, like passkeys or security keys (if you do this, you get a lot of leniency to mistakes everywhere else)
• stathibus 1y ago
  As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?
  • dist-epoch 1y ago
    This is spreading everywhere, Rust, Python, ...
    • grishka 1y ago
      Not Java, thankfully! Libraries containing 1-2 trivial classes do exist, but they're an exception rather than a rule. Might be that the process of publishing to Maven Central is just convoluted enough to deter the kinds of people who would publish such libraries.
      • Deukhoofd 1y ago
        Also because Java, .NET, etc. all have very expansive standard libraries. You don't need to import most stuff, as it's already built-in.
        • tracker1 1y ago
          Very true... I'm more experienced with .Net, but usually when you bring in something, it's much more of a compositional library or framework for doing something... like a testing harness (XUnit), web framework (FastEndpoints), etc. No so much in terms of basic utilities, where the std library and extensions for LINQ cover a lot of ground, even if you aren't using LINQ expressions themselves.
        • szatkus 1y ago
          I mean, Apache Commons are still widely used. But it's just a handful of libraries maintaned by one organisation.
        • kelvinjps10 1y ago
• pavlov 1y ago
  The malware steals crypto in end-user browsers. Another one for “web3 is going great”…
  • goku12 1y ago
    I dislike web3 and the overuse of crypto as much as you do. But look at the nature of the exploit. It isn't limited to crypto or web3. There are other secrets and sensitive information that browsers regularly hold in their memory. What about them?
    • jowea 1y ago
      Yeah cryptoassets are probably just the easiest thing to monetize.
• paulddraper 1y ago
  Maintainer phished. Was caught quickly (hours? hard to be sure, the versions have been removed/overwritten). Attacker owns npmjs.help domain.
  • DDerTyp 1y ago
    Noticed that after ten mins, contacted author immediatly and he seems to be working on it / restoring his account / removing malware on published packages. Kinda "proud" on it haha :D
    • jbverschoor 1y ago
      Doesn’t npmjs do things like signing, pinning, and yanking packages, like rubygems?
      • paulddraper 1y ago
        Yes
• dist-epoch 1y ago
  Given that most of these kind of attacks are detected relatively quickly, NPM should implement a feature where it doesn't install/upgrade packages newer than 3 days, and just use the previous version.
  • mcintyre1994 1y ago
    Would it be spotted quickly if nobody got the update though? It'd probably just go undetected for 3 days instead. In this case one team spotted it because their CI picked up the new version (https://jdstaerk.substack.com/p/we-just-found-malicious-code-in-the https://jdstaerk.substack.com/p/we-just-found-malicious-code...).
    • skybrian 1y ago
      The question is who picks up the vulnerable version first. With minimal version selection (like Go has), the people with a direct dependency on the vulnerable library go first, after running a command to update their direct dependencies. People with indirect dependencies don’t get the new version until a direct dependency does a release pointing at the vulnerable version, passing it on. Not sure if that would be a better result in the end. It seems like it depends on who has direct dependencies and how much testing they do. Do they pass it on or not?
  • jowea 1y ago
    What if the latest patch is (claiming to be) a security fix? Then that's 3 days of more insecurity.
  • deleted 1y ago
    [deleted]
• bstsb 1y ago
  looks like it won't affect you if you just downloaded the packages locally. the actual code only runs in a browser context - it replaces all crypto addresses in many places with the attacker's. a list of the attacker's wallet addresses: https://gist.github.com/sindresorhus/2b7466b1ec36376b8742dc711c24db20#file-npm-vulnerability-deobfusicated-js-L103 https://gist.github.com/sindresorhus/2b7466b1ec36376b8742dc7...
  • pingou 1y ago
    I wonder why they didn't add something more nefarious that can run on developers machines while they were at it, would it have been too easy to see? It was caught very quickly anyway.
  • keepamovin 1y ago
    that will still affect users of your website that uses these packages, tho.
  • smoovb 1y ago
    Etherscan has tagged these addresses already. As of this check, none of the other block explorers have. Etherscan - yes - https://etherscan.io/address/0x4Cb4c0E7057829c378Eb7A9b174B004873b9D769 https://etherscan.io/address/0x4Cb4c0E7057829c378Eb7A9b174B0... Mempool.space - no Blockchair - no Tronscan - no Blockcypher.com - no Blockread.io - no
• goku12 1y ago
  Developer account got hijacked through phishing. @junon acknowledged this readily and is trying to get it sorted. Meanwhile, this is a mistake that can happen to anyone, especially under pressure. So no point in discussing the personal oversight. So let me raise a different concern. This looks like an exploit for web browsers, where an average user (and most above average users) have no clue as to what's running underneath. And cryptocurrency and web3 aren't the only sensitive information that browsers handle. Meaning that similar exploits could arise targeting any of those. With millions of developers, someone is bound to repeat the same mistake sooner or later. And with some packages downloaded thousands of times per day, some CI/CD system will pull it in and publish it in production. This is a bigger problem than just a developer's oversight. - How do the end user protect themselves at this point? Especially the average user? - How do you prevent supply chain compromises like this? - What about other language registries? - What about other platforms? (binaries, JVM, etc?) This isn't a rhetorical question. Please discuss the solutions that you use or are aware of.
  • hansott 1y ago
    > How do you prevent supply chain compromises like this? Take a look at https://github.com/AikidoSec/safe-chain https://github.com/AikidoSec/safe-chain and https://intel.aikido.dev/?tab=malware https://intel.aikido.dev/?tab=malware! Disclaimer: I work at Aikido Security :)
  • ashishbijlani 1y ago
    Packj [1] detects malicious PyPI/NPM/Ruby/PHP/etc. dependencies using behavioral analysis. It uses static+dynamic code analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect bad actors (e.g., typo squatting). 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj
  • eviks 1y ago
    > Meanwhile, this is a mistake that can happen to anyone, especially under pressure. So no point in discussing the personal oversight. Unless this is a situation that could've been easily avoided with a password manager since the link was from a website not in your manager's database, so can't happen to anyone following security basics, and the point of discussing the oversight instead of just giving up is to increase the share of people who follow the basics?
• martypitt 1y ago
  A super quick script to check the deps in your package-lock.json file is here[0]. [0]: https://gist.github.com/martypitt/0d50c350aa7f0fc733547543438d7df3 https://gist.github.com/martypitt/0d50c350aa7f0fc73354754343...
  • krona 1y ago
    how about: grep -r "_0x112fa8"
    • 9dev 1y ago
      Irritatingly, this doesn't turn up anything, despite having a theoretically-compromised project as per the package-lock.json… At least on my end
      • mewpmewp2 1y ago
        What do you mean irritatingly? Do you mean that you think 'grep -r "_0x112fa8"' is not enough or are you irritated that npm audit is flagging as if it was compromised?
        • 9dev 1y ago
          I'm irritated because I expected to find at least one compromised file, but there were none. It may be, though, that we only use the affected packages as transitive development dependencies, in which case they are not installed locally. But a sliver of doubt remains that I missed something.
      • AgentME 1y ago
        If you had the dependency installed before this attack, then you would still be pinned to an old safe version.
  • patates 1y ago
    aren't these already nuked and show up in the "npm audit" command?
• andrewmcwatters 1y ago
  Luckily this seems to be browser-specific, and not cryptocurrency malware that runs in Node.js environments, so it might be wise for us all to do some hardening on our software, and make sure we're doing things like version pinning. Edit: As of this morning, `npm audit` will catch this.
  • jbverschoor 1y ago
    Run anything in some sort of container or sandbox
• DDerTyp 1y ago
  One of the most insidious parts of this malware's payload, which isn't getting enough attention, is how it chooses the replacement wallet address. It doesn't just pick one at random from its list. It actually calculates the Levenshtein distance between the legitimate address and every address in its own list. It then selects the attacker's address that is visually most similar to the original one. This is a brilliant piece of social engineering baked right into the code. It's designed to specifically defeat the common security habit of only checking the first and last few characters of an address before confirming a transaction. We did a full deobfuscation of the payload and analyzed this specific function. Wrote up the details here for anyone interested: https://jdstaerk.substack.com/p/we-just-found-malicious-code-in-the https://jdstaerk.substack.com/p/we-just-found-malicious-code... Stay safe!
  • oasisbob 1y ago
    > This is a brilliant piece of social engineering baked right into the code. It's designed to specifically defeat the common security habit ... I don't agree that the exuberance over the brilliance of this attack is warranted if you give this a moment's thought. The web has been fighting lookalike attacks for decades. This is just a more dynamic version of the same. To be honest, this whole post has the ring of AI writing, not careful analysis.
    • NoahZuniga 1y ago
      > To be honest, this whole post has the ring of AI writing, not careful analysis. No it doesn't?
    • withinboredom 1y ago
      > To be honest, this whole post has the ring of AI writing, not careful analysis. It has been what, hours? since the discovery? Are you expecting them to spend time analysing it instead of announcing it? Also, nearly everyone has AI editing content these days. It doesn’t mean it wasn’t written by a human.
      • b112 1y ago
• nromiun 1y ago
  I have nothing to do with this but still I am getting second hand embarrassment. Here is an example, is-arrayish package, 73.8 MILLION downloads per week. The code? 3 lines to check if an object can be used like an array. I am sorry, but this is not due to not having a good standard library, this is just bad programming. Just pure laziness. At this point just blacklist every package starting with is-.
  • zahlman 1y ago
    Meanwhile in Python: 134 million weekly downloads, seemingly slowly trending upward over time, for https://pypistats.org/packages/six https://pypistats.org/packages/six which provides third-party compatibility for a version of Python that dropped support over five years ago.
    • nromiun 1y ago
      The code is 813 lines [0]. Not saying everyone should use it but these two are not directly comparable. [0] https://github.com/benjaminp/six/blob/main/six.py https://github.com/benjaminp/six/blob/main/six.py
      • zahlman 1y ago
        It is much more code, but it should be even more useless. (No slight intended to Benjamin Peterson.) The 2.7 window was already extended to give everyone a chance to migrate.
    • sega_sai 1y ago
      Most of these downloads, I would bet, are from CI
      • zahlman 1y ago
        Oh, I don't doubt it at all. But that doesn't make it any less depressing to me. Nor does it matter to Fastly's bandwidth burden.
    • 1y ago
• deleted 1y ago
  [deleted]
• marifjeren 1y ago
  Definitely sounds like spear phishing targeting you specifically. Kudos to you for owning up to it. As others have said, it's the kind of thing that could happen to anyone, unfortunately.
  • mcjiggerlog 1y ago
    I also received the same phishing email and I only have packages with a few thousand downloads per week.
• 15155 1y ago
  BTW: the NPM logo is blurry in that phishing email.
• maxloh 1y ago
  For everyone wondering: the code looks this way: https://web.archive.org/web/20250908162250/https://cdn.jsdelivr.net/npm/simple-swizzle@0.2.3/index.js https://web.archive.org/web/20250908162250/https://cdn.jsdel... Got it from the "simple-swizzle" package that hasn't been taken down by NPM.
• wch 1y ago
  When I run `npm audit`, it points me to a security advisory at GitHub. For example, for debug, it is https://github.com/advisories/GHSA-8mgj-vmr8-frr6 https://github.com/advisories/GHSA-8mgj-vmr8-frr6 . That page says that the affected versions are ">=0". Does that seem right? That page also says: > Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it. Is this information accurate?
  • andrewmcwatters 1y ago
    No. A now unavailable version, `debug@4.4.2` was unpublished by npm, which is the only vulnerable version in question. Edit: However, I think the reason the security advisory marks the entire package at the moment, is because there is no mechanism in npm to notify users a version with an exploit is currently installed. `npm audit` looks at the versions configured, not installed. The security advisory triggering this warning forces everyone to reinstall packages today, in case 4.4.2 was installed.
  • herpdyderp 1y ago
    I also see: - https://github.com/advisories/GHSA-hfm8-9jrf-7g9w https://github.com/advisories/GHSA-hfm8-9jrf-7g9w - https://github.com/advisories/GHSA-5g7q-qh7p-jjvm https://github.com/advisories/GHSA-5g7q-qh7p-jjvm - https://github.com/advisories/GHSA-8mgj-vmr8-frr6 https://github.com/advisories/GHSA-8mgj-vmr8-frr6 - https://github.com/advisories/GHSA-m99c-cfww-cxqx https://github.com/advisories/GHSA-m99c-cfww-cxqx I wonder if they're all from the same thing, they all popped up at the same time. edit: they do appear to all be the same thing, and the advisory version wildcard is wrong: https://github.com/github/advisory-database/issues/6099 https://github.com/github/advisory-database/issues/6099
    • deleted 1y ago
      [deleted]
• numpad0 1y ago
  I thought it stupid that there were some old established electro-mechanical manufacturing companies that would just block github.com and Internet downloads in general, only allowing codes from internal repos that took months to get approved, breaking npm dependent workflows. Now? Why aren't everyone setting up own GitHub mirrors is beyond me, almost. They were 100% right.
• anticristi 1y ago
  This is really scary. It could have totally happened to me too. How can we design security which works even when people are tired or stressed? Once upon a time, I used a software called passwordmaker. Essentially, it computed a password like hash(domain+username+master password). Genius idea, but it was a nightmare to use. Why? Because amazon.se and amazon.com share the same username/password database. Similarly, the "domain" for Amazon's app was "com.amazon.something". Perhaps it's time for browser vendors to strongly bind credentials to the domain, the whole domain and nothing but the domain, so help me Codd.
  • samhh 1y ago
    Passkeys already solve for this, we just have to get past the FUD.
    • odie5533 1y ago
      In this case, how is the Passkey safer than 2FA?
      • samhh 1y ago
        It’s cryptographically bound to the domain.
• simpaticoder 1y ago
  I've come to the conclusion that avoiding the npm registry is a great benefit. The alternative is to import packages directly from the (git) repository. Apart from being a major vector for supply-chain attacks like this one, it is also true that there is little or no coupling between the source of a project and its published code. The 'npm publish' step takes pushes local contents into the registry, meaning that a malefactor can easily make changes to code before publishing.
  • komali2 1y ago
    Do you do this in your CI as well? E.g. if you have a server somewhere that most would run `npm install` on builds, you just `git clone` into your node_modules or what?
  • HexDecOctBin 1y ago
    As a C developer, having being told for a decade that minimising dependencies and vendoring stuff straight from release is obsolete and regressive, and now seeing people have the novel realisation that it's not, is so so surreal. Although I'll still be told that using single-header libraries and avoiding the C standard library are regressive and obsolete, so gotta wait 10 more years I guess.
    • dboon 1y ago
      Yeah lol I’m making a C package manager for exactly this. No transitive dependencies, no binaries served. Just pulling source code, building, and being smart about avoiding rebuilds.
      • eviks 1y ago
        Being smart about avoiding rebuilds is serving prebuilds
    • dpc_01234 1y ago
      NPM dev gets hacked, packages compromised, it's detected within couple of hours. XZ got hacked, it reached development versions of major distributions undetected, right inside an _ssh_, and it only got detected due to someone luckily noticing and investigated slow ssh connections. Still some C devs will think it's a great time to come out and boast about their practices and tooling. :shrug:
• Vincenius 1y ago
  Wow, I also received the same phishing email even though my packages only have a few hundred downloads a week (eg. bsky-embed). So I guess a lot more accounts/packages might be affected than the ones stated in the article
  • gaudystead 1y ago
    Did you receive the email in a similar time window? I'm trying to think of ways to scan other repositories for signs of compromise.
    • Vincenius 1y ago
      Yeah, I received the email on the 8th a little earlier at 2:50am (utc +2)
• joaomoreno 1y ago
  From sindresorhus: You can run the following to check if you have the malware in your dependency tree: `rg -u --max-columns=80 _0x112fa8` Requires ripgrep: `brew install rg` https://github.com/chalk/chalk/issues/656#issuecomment-3266880534 https://github.com/chalk/chalk/issues/656#issuecomment-32668...
  • koolba 1y ago
    Try the same recursive grep on ~/.npm to see if you have it cached too. Not just the latest in the current project.
    • tripplyons 1y ago
      Haven't installed any modules today, but I ran these commands to clear caches for npm and pnpm just to be safe. npm cache clean --force pnpm cache delete
      • PokestarFan 1y ago
        You probably want to check before you clear cache
  • cgijoe 1y ago
    Sorry, I am unfamiliar with ripgrep. Is this simply scanning for the string `_0x112fa8`? Could we do the same thing with normal grep -r?
    • skrebbel 1y ago
      yes. ripgrep just does it faster, is all.
      • hinkley 1y ago
        Make it work, make it right, make it fast. For security checks, the first 2 out of 3 is just fine.
• deleted 1y ago
  [deleted]
• deleted 1y ago
  [deleted]
• mmis1000 1y ago
  Seems a quite targeted attack though, the phishing domain is registered just 4 days ago.
• phkahler 1y ago
  >> which silently intercepts crypto and web3 activity in the browser, manipulates wallet interactions, and rewrites payment destinations so that funds and approvals are redirected to attacker-controlled accounts without any obvious signs to the user. If you're doing financial transactions using a big pile of NPM dependencies, you should IMHO be financially liable for this kind of thing when your users get scammed.
  • bpavuk 1y ago
    using NPM at all must be treated as a liability at this point. it's not the first and definitely not the last time NPM got pwned this hard.
    • pixl97 1y ago
      Lots of very big financial originations and other F100 companies use a whole lot more node than you'd be comfortable with. Luckily some of them actually import the packages to a local distribution point and check them first.
  • palmfacehn 1y ago
    It isn't uncommon in crypto ecosystems for the core foundation to shovel slop libraries on application developers.
• cddotdotslash 1y ago
  NPM deserves some blame here, IMO. Countless third party intel feeds and security startups can apparently detect this malicious activity, yet NPM, the single source of truth for these packages, with access to literally every data event and security signal, can't seem to stop falling victim to this type of attack? It's practically willful ignorance at this point.
  • PokestarFan 1y ago
    NPM is owned by GitHub and therefore Microsoft, who is too busy putting in Copilot into apps that have 0 reason to have any form of generative AI in them
    • Cthulhu_ 1y ago
      But Github does loads of things with security, including reporting compromised NPM packages. I didn't know NPM is owned by Microsoft these days though, now that I think about it, Microsoft of all parties should be right on top of this supply chain attack vector - they've been burned hard by security issues for decades, especially in the mid to late 90's, early 2000s as hundreds of millions of devices were connected to the internet, but their OS wasn't ready for it yet.
    • bnchrch 1y ago
      Good god. Not everything has to be about your opinion on AI.
      • jay_kyburz 1y ago
        Actually, they could probably use AI to see if each update to a package looks malicious or obfuscated.
      • PokestarFan 1y ago
        GitHub was folded into Microsoft's "CoreAI" team. Not very confidence-inspiring.
    • wutbrodo 1y ago
• bpavuk 1y ago
  I'll come back to this thread when someone asks me why I hate JavaScr*pt yet again. this will be one of a thousand links.
• tomxor 1y ago
  Finally validated for writing my own damn ANSI escape codes.
  • jmull 1y ago
    Yeah, I get that learning the codes is a little annoying, but not actually harder than finding, incorporating, and learning one of the APIs here. Also one is standard while the other is not. Seems a bit nuts to use a package for this.
    • junon 1y ago
      Hi, missing a lot of history here. When Chalk was written, colors in the terminal wasn't a flashy thing people tried to do very often, at least not in the JS world. Coming from browsers and wanting to make CLI apps using the flashy new Node.js 0.10/0.12 at the time saw a lot of designers and other aesthetically-oriented folks with it. Chalk filled a hole for people to do that without needing to understand how TTYs worked. Node.js proper has floated the idea of including chalk into the standard libraries, FWIW.
      • herpdyderp 1y ago
        > Node.js proper has floated the idea of including chalk into the standard libraries, FWIW. Oh my word please no! Every time I run into an issue where a dependency suddenly isn’t logging colors like it’s supposed to, it always boils down to chalk trying to do something fancy to handle an edge case that doesn’t actually exist. Just log the dang colors!
        • junon 1y ago
          I'd be curious what those edge cases are, as a maintainer of chalk.
      • jmull 1y ago
        I doubt we'll ever see eye-to-eye on this. Some people try to think about how to write less code, and some people try to think about how to write more code.
• tadamcz 1y ago
  Using a security key instead of TOTP would have prevented this.
• a022311 1y ago
  After all these incidents, I still can't understand why package registries don't require cryptographic signatures on every package. It introduces a bit more friction (developers downloading CI artifacts and manually signing and uploading them), but it prevents most security incidents. Of course, this can fail if it's automated by some CI/CD system, as those are apparently easily compromised.
  • parliament32 1y ago
    Real registries do[1], npm is just amateur-hour which is why its usage is typically forbidden in enterprise contexts. [1] https://www.debian.org/doc/manuals/securing-debian-manual/deb-pack-sign.en.html https://www.debian.org/doc/manuals/securing-debian-manual/de...
    • anonfordays 1y ago
      [flagged]
    • 9dev 1y ago
      In all fairness—npm belongs to GitHub, which belongs to Microsoft. Amateur-hour is both not a valid excuse anymore, and also a boring explanation. GitHub is going to great lengths to enable SLSA attestations for secure tool chains; there must be systemic issues in the JS ecosystem that make an implementation of proper attestations infeasible right now, everything else wouldn't really make sense. So if we're discussing anything here, why not what this reason is, instead of everyone praising their favourite package registry?
      • parliament32 1y ago
        The NPM team has repeatedly commented that it's "too hard", effectively, and would discourage new developers from publishing packages. See: https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://news.ycombinator.com/item?id=38645969 https://news.ycombinator.com/item?id=38645969 https://github.com/npm/cli/commit/5a3b345d6d5d175ea9ec967364b948c662a2ef16#commitcomment-36817791 https://github.com/npm/cli/commit/5a3b345d6d5d175ea9ec967364...
• albi05 1y ago
  "B-b-but passkeys are inconvenient"
  • herpdyderp 1y ago
    I must admit I was wary of them at first but now I use them on everything I can and it's more convenient.
• koolba 1y ago
  Another great example of why things like dependabot or renovate for automatically bumping dependencies to the latest versions is not a good idea. If it's not a critical update, better to let the world be your guinea pig and only update after there's been a while of real world usage and analysis. If it is a critical enough update that you have to update right away, then you take the time to manually research what's in the package, what changed, and why it is being updated.
  • chuckadams 1y ago
    If the update isn't from a security alert, I let most dependabot PRs marinate for about a week precisely for this reason. Not the most scientific approach, but less stressful for sure.
  • jakub_g 1y ago
    Dependabot now supports "cooldown" config for this case: https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/ https://github.blog/changelog/2025-07-01-dependabot-supports...
• deleted 1y ago
  [deleted]
• adudethatgolfs 1y ago
  Scoket was all over this - https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack https://socket.dev/blog/npm-author-qix-compromised-in-major-...
  • cddotdotslash 1y ago
    Nathan, do you work for Socket? I think you should at least disclose that when sharing posts here.
    • whatamidoingyo 1y ago
      I've never heard of Socket before this thread. They could be taking advantage of this news and promoting the company, as it's mentioned quite a few times in this thread. Or it's just a good service that I should probably be using.
• zubilent 1y ago
  Is the npm package ecosystem fixable at this point? It seems to be flawed by design. Is there a way to not accept any package version less than X months old? It's not ideal because malicious changes may still have gone undetected in that time span. Time to deploy AI to automatically inspect packages for suspect changes.
  • mattstir 1y ago
    It's a tricky thing because what if the update fixes a critical vulnerability? Then you'd be stuck on the exploitable version for X months longer
• hnquestion10987 1y ago
  I'm a little confused after reading everything. I have an Expo app and if I run `npm audit`, I get the notification about `simple-swizzle`. The GitHub page (https://github.com/advisories/GHSA-hfm8-9jrf-7g9w https://github.com/advisories/GHSA-hfm8-9jrf-7g9w) says to treat the computer as compromised. What does this mean? Do I have to do a full reset to be sure? Should I avoid running the app until the version is updated?
  • pixl97 1y ago
    I mean the statement is pretty clear >Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it. It sounds like the package then somehow executes and invites other software onto the machine. If something else has executed then anything the executing user has access to is now compromised.
    • mirekrusin 1y ago
      Confusing as hell. From code analysis shared malicious code replaces ethereum and other crypto wallet addresses in browser context. You can install malicious package, run it, run it in browser context (ie. in your playwright tests), then update package to not compromised version and you're fine - your system is clean. This incident would be much more severe if the code would actually steal envs etc. because a lot of packages have dependency on debug as wildcard.
  • herpdyderp 1y ago
    The advisories on GitHub were/are weird for several reasons: 1. The version matching was wrong (now fixed). 2. The warning message is (still) exaggerated, imo, though I understand why they’d pass the liability downstream by doing so.
• gslepak 1y ago
  Tips to protect yourself from supply-chain attacks in the JavaScript ecosystem: - Don't update dependencies unless necessary - Don't use `npm` to install NPM packages, use Deno with appropriate sandboxing flags - Sign up for https://socket.dev https://socket.dev and/or https://www.aikido.dev https://www.aikido.dev - Work inside a VM
  • butshouldyou 1y ago
    Can you expand on "use Deno" for installing dependencies? I assume you don't mean to use Deno as the runtime, just for dependency management.
    • gslepak 1y ago
      I do mean use Deno as the runtime. Details and examples of how to switch are here: https://crib.social/notice/AwQqG9gm365uat93Nw https://crib.social/notice/AwQqG9gm365uat93Nw
      • selfmodruntime 1y ago
        How would this have prevented anything?
        • gslepak 1y ago
          In this case it would not have prevented anything, but I never claimed that it would. Using Deno with appropriate sandboxing flags can protect developers against many classes of supply-chain attacks. The reason it doesn't help in this instance is because the attack targets the generated bundle and runs on client devices, whereas other attacks will target developer machines themselves (and possibly also client devices). Those types of attacks can be mitigated by using Deno.
  • egorfine 1y ago
    > Don't update dependencies unless necessary And get yourself drowning in insurmountable technical debt in about two months. JS ecosystems moves at an extremely fast pace and if you don't upgrade packages (semi) daily you might inflict a lot of pain on you once a certain count of packages start to contain incompatible version dependencies. It sucks a lot, I know.
• hoppp 1y ago
  Damn, I use chalk... did they remove the malicious versions?
• 0xbadcafebee 1y ago
  Here we are again. 12 days ago (https://news.ycombinator.com/item?id=45039764 https://news.ycombinator.com/item?id=45039764) I commented how a similar compromise of Nx was totally preventable. Again, this is not the failure of a single person. This is a failure of the software industry. Supply chain attacks have gigantic impacts. Yet these are all solved problems. Somebody has to just implement the standard security measures that prevents these compromises. We're software developers... we're the ones to implement them. Every software packaging platform on the planet should already require code signing, artifact signing, user account attacker access detection heuristics, 2FA, etc. If they don't, it's not because they can't, it's because nobody has forced them to. These attacks will not stop. With AI (and continuous proof that they work) they will now get worse. Mandate software building codes now.
  • ivape 1y ago
    People focus on attacking windows because there are more windows users. What if I told you the world now has a lot more people involved in programming with JavaScript and Python? You’re right, this will only get a lot worse.
  • imiric 1y ago
    > Somebody has to just implement the standard security measures that prevents these compromises. It's not that simple. You can implement the most stringent security measures, and ultimately a human error will compromise the system. A secure system doesn't exist because humans are the weakest link. So while we can probably improve some of the processes within npm, phishing attacks like the ones used in this case will always be a vulnerability. You're right that AI tools will make these attacks more common. That phishing email was indistinguishable from the real thing. But AI tools can also be used to scan and detect such sophisticated attacks. We can't expect to fight bad actors with superhuman tools at their disposal without using superhuman tools ourselves. Fighting fire with fire is the only reasonable strategy.
  • const_cast 1y ago
    A lot of these security measures have trade offs, particularly when we start looking at heuristics or attestation-like controls. These can exclude a lot of common systems and software, including automations. If your heuristic is quite naive like "is using Linux" or "is using Firefox" or "has an IP not in the US" you run into huge issues. These sound stupid, because they are, but they're actually pretty common across a lot of software. Similar thing with 2FA. Sms isn't very secure, email primes you to phishing, TOTP is good... but it needs to be open standard otherwise we're just doing the "exclude users" thing again. TOTP is still phishable, though. Only hardware attestation isn't, but that's a huge red flag and I don't think NPM could do that.
• alex_suzuki 1y ago
  Also reported here: https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack https://socket.dev/blog/npm-author-qix-compromised-in-major-...
• WesolyKubeczek 1y ago
  Ugh, I almost had my github compromised two years ago with a phishing email from circleci dot net. Almost. The github login page still under that domain made me stop in my tracks.
• heipei 1y ago
  If you want to see what the phishing site (npmjs[.]help) looks like: https://urlscan.io/result/01992a3e-4f8c-72bb-90a9-c13826f2d8da https://urlscan.io/result/01992a3e-4f8c-72bb-90a9-c13826f2d8... - Was still up and running 2 hours ago.
  • mdaniel 1y ago
    > Size: 3124 kB Hey, that's a pretty good reproduction of npmjs
• xrd 1y ago
  It wouldn't be a perfect solution, but I wonder why browsers don't indicate the registration date for a domain in the URL bar somehow? I bet junon would have seen that and gotten suspicious.
  • gaudystead 1y ago
    I like this idea and could see it being visually represented as a faint red/green bar behind the URL text in the address bar, with a greater amount of the bar being red when the domain is less trusted. As for developers trusting a plugin that reaches out to an external location to determine the reputation of every website they visit seems like a harder sell though.
  • webdev1234568 1y ago
    that's a good one not perfect for sure, hackers would just start buying domains earlier but still...
    • xrd 1y ago
      Yeah, but there is a takedown process when a spam site is detected (the server provider can shut off access, etc), so it is a game that is somewhat winnable.
  • AtNightWeCode 1y ago
    There are curated lists over newly registered domain names that some security software uses so it should be easy to add without any privacy issues.
• dafelst 1y ago
  I'm curious if anyone is tracking transactions against the wallet addresses in the malicious code - I assume that is essentially the attackers' return on investment here.
  • eiiot 1y ago
    Just ran a script to do this – doesn't seem like there's much going in, other than one test transaction.
• molsson 1y ago
  I maintain a package on npm with >1M weekly downloads. I also got the same phishing e-mail, although I didn't click it.. here are the e-mail headers in the phishing e-mail I got: Return-Path: <ndr-6be2b1e0-8c4b-11f0-0040-f184d6629049@mt86.npmjs.help> X-Original-To: martin@minimum.se Delivered-To: martin@minimum.se Received: from mail-storage-03.fbg1.glesys.net (unknown [10.1.8.3]) by mail-storage-04.fbg1.glesys.net (Postfix) with ESMTPS id 596B855C0082 for <martin@minimum.se>; Mon, 8 Sep 2025 06:47:25 +0200 (CEST) Received: from mail-halon-02.fbg1.glesys.net (37-152-59-100.static.glesys.net [37.152.59.100]) by mail-storage-03.fbg1.glesys.net (Postfix) with ESMTPS id 493F2209A568 for <martin@minimum.se>; Mon, 8 Sep 2025 06:47:25 +0200 (CEST) X-SA-Rules: DATE_IN_PAST_03_06,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FROM_FMBLA_NEWDOM,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MIME_HTML_ONLY,SPF_HELO_NONE,SPF_PASS X-RPD-Score: 0 X-SA-Score: 1.1 X-Halon-ID: e9093e1f-8c6e-11f0-b535-1932b48ae8a8 Received: from smtp-83-4.mailtrap.live (smtp-83-4.mailtrap.live [45.158.83.4]) by mail-halon-02.fbg1.glesys.net (Halon) with ESMTPS id e9093e1f-8c6e-11f0-b535-1932b48ae8a8; Mon, 08 Sep 2025 06:47:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; x=1757637200; d=smtp.mailtrap.live; s=rwmt1; h=content-transfer-encoding:content-type:from:to:subject:date:mime-version: message-id:feedback-id:cfbl-address:from; bh=46LbKElKI+JjrZc6EccpLxY7G+BazRijag+UbPv0J3Y=; b=Dc1BbAc9maHeyNKed/X7iAPabcuvlgAUP6xm5te6kkvGIJlame8Ti+ErH8yhFuRy/xhvQTSj8ETtV f3AElmzHDWcU3HoD/oiagTH9JbacmElSvwtCylHLriVeYbgwhZVzTm4rY7hw/TVqNE5xIZqWWCMrVG wi+k9uY+FUIQAh7Ta2WiPk/A4TPh04h3PzA50zathvYcIsPC0iSf7BBE+IIjdLXzDzNZwRmjgv2ZHW GAx/FRCPFgg0PbVvhJw98vSHnKmjPO/mmcotKFG+MUWkCtTu28Mm46t7MI7z5PrdCXZDA7L1nVnIwE ffIf0zED32Z6tFSJFNmYgFZlD6g+DnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; x=1757637200; d=npmjs.help; s=rwmt1; h=content-transfer-encoding:content-type:from:to:subject:date:mime-version: message-id:feedback-id:cfbl-address:from; bh=46LbKElKI+JjrZc6EccpLxY7G+BazRijag+UbPv0J3Y=; b=DyWvxSOjMf7WfCVtmch+zw63kZ/OOBjcWnh1kIYs/hozgemb9mBIQCMqAdb4vSZChoW5uReVH5+k5 Jaz7UodbPJksVkYWqJOVg6nyx5EaYMYdgcw1+BCct/Sf2ceFwWurhupa6y3FBTFWBYLhcsAXERlx2l IuxWlpZoMDEBqDxjs8yvx/rkBrcd/2SNTcI+ooKJkrBIGBKuELOd3A5C6jlup6JNA4bE7vzP3FUfKw y0357UMnn45zWHm9HvudO4269FRlNjpiJaW7XF1/ANVrnDlNWfUGNQ5yxLZqmQDTtxFI7HcOrF3bTQ O/nrmVOvN9ywMvk/cJU4qGHqD9lT32A== CFBL-Address: fbl@smtp.mailtrap.live; report=arf X-Report-Abuse-To: abuse@mailtrap.io Received: from npmjs.help by smtp.mailtrap.live with ESMTPSA 6aee9fff-8c4b-11f0-87bb-0e939677d2a1; Mon, Sep 08 2025 00:33:20 GMT Feedback-ID: ss:770486:transactional:mailtrap.io Message-ID: <6be2b1e0-8c4b-11f0-0040-f184d6629049@npmjs.help> X-Mt-Data: bAX0GlwcNW6Dl_Qnkf3OnU.GLCSjw_4H01v67cuDIh2Jkf52mzsVFT_ZEVEe0W6Lf3qzW2LP_TCy93I46MCsoT0pB9HozQkvCw22ORSCt3JBma1G3v9aDEypT1DLmyqlb6hYLF3H7tJCgcxTU5pbijyNaOFtoUMdiTA6jxaONeZbBj.SKUa5CLT5TMpeNHG6oGIiY_jqlU.nQkxGPY3v9E34.Nz4ga8p9Pd_BplftaE~--2CLrluJMY65S5xFl--IISg0olYJu6DVyVDEcJ.AQ~~ MIME-Version: 1.0 Date: Mon, 08 Sep 2025 00:33:20 +0000 Subject: Two-Factor Authentication Update Required To: "molsson" <martin@minimum.se> From: "npm" <support@npmjs.help> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
• vladkens 1y ago
  Actually, my problem is not really with NPM itself or the fact that it can be hacked, but with the damn auto-update policy of software – as users we usually have no idea which versions are installed, and there is even no way to roll back to a safe version. All these Chrome, VSCode, Discord, Electron-apps, browser extensions, etc – they all update ± every week, and I can't even tell what features are being added. For comparison, Sublime updates once a YEAR and I'm totally fine with that.
• vplex 1y ago
  [dead]
• l0rdkr0n0s 1y ago
  Did someone wrote a script to check if the attacker wallets really did get any transactions? I checked a few bitcoin portfolios balance manually but nothing in there but the first ETH portfolio had a few cents. I would be curious about the total financial impact so far
• deleted 1y ago
  [deleted]
• nixosbestos 1y ago
  Cough passkeys would've prevented this.
  • deleted 1y ago
    [deleted]
• zabil 1y ago
  Does anybody have tips on how to invalidate a wallet address response if it's intercepted and modified like this?
  • Mattwmaster58 1y ago
    Off the top of my head, you could include your own checksum in the payload. Their code only modifies the address. Nothing would prevent them from reverse engineering checksum, too. There are ways to detect a replaced/proxied global window function too, and that's another arms race.
• Imustaskforhelp 1y ago
  I can't imagine all the struggle the author must feel like. Like the need to constantly explain himself because of one single blunder. It shows how much so many open source projects rely on dependencies which are owned by one person and they can be pwned and (maybe hacked too) Everyone can get pwned I suppose. From a more technical perspective though, from the amounts of times I am listening AI,AI & AI BS, Couldn't something like deno / node / bun etc. just give a slight warning on if they think that the code might be malware or, maybe the idea could be that we could have a stable release that lets say could be on things like debian etc. which could be verified by external contributors and then instead of this node world moving towards @latest, we move towards something like @verified which can take builds / source from something like debian maintained or something along that way... I hope people can understand that author is a human too and we should all treat him as such and lets treat him with kindness because I can't imagine what he might be going as I said. Woud love a more technical breakdown once things settle and we can postmortem this whole situation.
• paxys 1y ago
  Yeah I know "everyone can be pwned" etc. but at this point if you are not using a password manager and still entering passwords on random websites whose domains don't match the official one then you have no business doing anything of value on the internet.
  • djkoolaide 1y ago
    Yeah, a password manager/autofill would have set off some alarms and likely prevented this, because the browser autofill would have detected a mismatch for the domain npmjs.help.
  • const_cast 1y ago
    This is true, but I've also run into legitimate password fields on different domains. Multiple times. The absolute worst offender is mobile app vs browser. Why does the mobile app use a completely different domain? Who designed this thing?
  • Drblessing 1y ago
    How does someone intelligent with 2FA get pwned? Serious question.
    • odie5533 1y ago
      Numbers game. Plenty of people got the email and deleted it. Only takes one person distracted and thinking "oh yeah my 2FA is pretty old" for them to get pwned.
      • pier25 1y ago
        It's more than that. You need to log in, manually, into a new domain you've never used your password before.
      • CGamesPlay 1y ago
        (I think everyone in this comment chain already knows this, but) PSA: your 2FA does not "get old" and does not need to be rotated (unless the device YOU stored it on was compromised). "Rotate your 2FA periodically" is NOT recommended security advice.
• codedokode 1y ago
  I wanted to remind once again that hardware keys are immune to fishing because they check website domain unlike humans.
• dismalaf 1y ago
  The irony of this post's reception a few hours ago: https://news.ycombinator.com/item?id=45167394 https://news.ycombinator.com/item?id=45167394
• andix 1y ago
  I've posted this idea already last time with the nx incident: we need some mechanism for package managers to ignore new packages for a defined time. Skip all packages that were published less than 24 hours ago. Most of those attacks are detected and fixed quickly, because a lot of people check newly published packages. Also the owners and contributors notice it quickly. But a lot of consumers of the package just install the newest release. With some grace period those attacks would be less critical.
• thedougd 1y ago
  It was a pain in the ass but I always appreciated that Maven central required packages to be signed with a public key pre-associated with the package name.
• duffpkg 1y ago
  Managed large health groups for a long time, we actually care about security, billion of patient interactions, never a compromise. I managed the modernization of the payment platform for the largest restaurant in the world. Billions of dollars a year. Early thing we did was freeze versions, maintain local package repos, carefully update. It is very concerning how rare these things are done. Tens of thousands of random people are in the core supply chain of most node projects and there seems to be a lot of carelessness of that fact.
• stevage 1y ago
  I'm really surprised that NPM does not have better means to detect and respond to events like this. Since all the affected packages were by the same author, it would seem straightforward to have a mitigation event that rolls back all recent changes to some recent milestone. Then it's just a question of knowing when to hit the button.
• hofrogs 1y ago
  This attack could have been so, so much worse. We were saved by the attacker's lack of creativity and competence.
  • carwyn 1y ago
    And the author's prompt response.
• baloki 1y ago
  A package on the list called ‘simple-swizzle’ turns out to be used in OpenNext which is an unexpected attack vector for sure.
  • yread 1y ago
    > DO. NOT. USE. THIS. PACKAGE > Used by 9.9m https://github.com/qix-/node-simple-swizzle https://github.com/qix-/node-simple-swizzle
• ndhandala 1y ago
  I think Passkeys fixes this
• progx 1y ago
  One reason why i run everything on my development machine in a docker container, you can't trust any package. I use bun, but similar could be done with npm Add to .bashrc: alias bun='docker run --rm -it -u $(id -u):$(id -g) -p 8080:8080 -v "$PWD":/app -w /app my-bun bun "$@"' then you can use `bun` command as usual. Dockerfile: FROM oven/bun:1 AS base VOLUME [ "/app" ] EXPOSE 8080/tcp WORKDIR /app # Add your custom libs # RUN DEBIAN_FRONTEND=noninteractive apt-get update && apt-get -y install \ # ... \ Create once the container: $ docker build -t "my-bun" -f "Dockerfile" .
• mattbilson 1y ago
  Completely understand people getting phished. How long before npm mandates using phishing resistant mfa? At least for accounts that can publish packages with this may downloads.
• lifeinthevoid 1y ago
  DuckDB pwned by same attack: https://github.com/duckdb/duckdb-node/security/advisories/GHSA-w62p-hx95-gf2c https://github.com/duckdb/duckdb-node/security/advisories/GH...
• naugtur 1y ago
  You too can run malware from NPM (I mean without consequences) https://github.com/naugtur/running-qix-malware?tab=readme-ov-file#you-too-can-run-malware-from-npm-i-mean-without-consequences https://github.com/naugtur/running-qix-malware?tab=readme-ov...
• deleted 1y ago
  [deleted]
• MrContent04 1y ago
  Incidents like this show how fragile the supply chain really is. One compromised maintainer account can affect thousands of projects. We need better defaults for package signing + automated trust checks, otherwise we’ll just keep repeating the same cycle.”
• Phelinofist 1y ago
  Maybe it's time to declare the JS package world broken?
• ikekkdcjkfke 1y ago
  What a ss email is
• verhoff_noah 1y ago
  [flagged]
• deleted 1y ago
  [deleted]
• glitchnik 1y ago
  [flagged]