Live data from Hacker News

Malicious versions of Nx and some supporting plugins were published

github.com

141–150 of 460 posts

Re: Malicious versions of Nx and some supporting plugins were published

#141

Before anyone puts the blame on Nx, or Anthropic, I would like to remind you all what actually caused this exploit. The exploit was caused by an exploit, shipped in a package, that was uploaded using a stolen "token" (a string of characters used as a sort of "usename+password" to access a programming-language package-manager repository). But that's just the delivery mechanism of the attack. What caused the attack to…

Anthropic and Google do owe this issue serious attention [1], and they need to take actions as a result of this.

[1] https://news.ycombinator.com/item?id=45039442

Re: Malicious versions of Nx and some supporting plugins were published

#142
post #134

Earlier quoted context omitted.

It's an RCE delivered via supply chain attack

malware isn't remote. therefore it isn't remote code execution

If you can execute code on some machine without having access to that machine, then it's RCE. Whether you gain RCE through an exploit in a bad network protocol or through tricking the user into running your code (i.e. this attack) is merely a delivery mechanism. It's still RCE

Re: Malicious versions of Nx and some supporting plugins were published

#143
post #125

Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…

Or use pnpm. The latest versions have all dependency lifecycle scripts ignored by default. You must whitelist each package.

Re: Malicious versions of Nx and some supporting plugins were published

#144

Earlier quoted context omitted.

We are using NX heavily (and are not affected) in my teams in a larger insurance company. We have >10 standalone line of business apps and 25+ individual libraries in the same monorepo, managed by NX. I've toyed with other monorepo tools for these kind of complex setup in my career (lerna, rushjs, yarn workspaces) but not only did none came close, lerna is basically handed over to NX, and rushjs is unmaintained. If y…

npm workspaces and npm scripts will get you further than you might think. Plenty of people got along fine with Lerna, which didn't do much more than that, for years. I will say, I was always turned off by NX's core proposition when it launched, and more turned off by whatever they're selling as a CI/CD solution these days, but if it works for you, it works for you.

I'd recommend pnpm over npm for monorepos. Forcing you to be explicit about each package's dependencies is good.

I found npm's workspace features lacking in comparison and sparsely documented. It was also hard to find advice on the internet. I got the sense nobody was using npm workspaces for anything other than beginner articles.

Re: Malicious versions of Nx and some supporting plugins were published

#145
post #11

People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simpl…

I’d like a package manager that essentially does a git clone, and a culture that says: “use very few dependencies, commit their source code in your repo, and review any changes when you do an update.” That would be a big improvement to the modern package management fiasco.

That what I used git submodules for. I had a /lib folder in my project where the dependencies were pulled/checked out from. This was before I was doing CI/CD and before folks said git submodules were bad.

Personally, I loved it. I only looked and updating them when I was going to release a new version of my program. I could easily do a diff to see what changed. I might not have understood everything, but it wasn't too difficult to see 10-100 line code changes to get a general idea.

I thought it was better than the big black box we currently deal with. Oh, this package uses this package, and this package... what's different? No idea now, really.

Re: Malicious versions of Nx and some supporting plugins were published

#146

Before anyone puts the blame on Nx, or Anthropic, I would like to remind you all what actually caused this exploit. The exploit was caused by an exploit, shipped in a package, that was uploaded using a stolen "token" (a string of characters used as a sort of "usename+password" to access a programming-language package-manager repository). But that's just the delivery mechanism of the attack. What caused the attack to…

50% of impacted users the vector was VS Code and only ran on Linux and macOS.

https://www.wiz.io/blog/s1ngularity-supply-chain-attack

"contained a post-installation malware script designed to harvest sensitive developer assets, including cryptocurrency wallets, GitHub and npm tokens, SSH keys, and more. The malware leveraged AI command-line tools (including Claude, Gemini, and Q) to aid in their reconnaissance efforts, and then exfiltrated the stolen data to publicly accessible attacker-created repositories within victims’ GitHub accounts.

"The malware attempted lockout by appending sudo shutdown -h 0 to ~/.bashrc and ~/.zshrc, effectively causing system shutdowns on new terminal sessions.

"Exfiltrated data was double and triple-base64 encoded and uploaded to attacker-controlled victim GitHub repositories named s1ngularity-repository, s1ngularity-repository-0, or s1ngularity-repository-1, thousands of which were observed publicly.

"Among the varied leaked data here, we’ve observed over a thousand valid Github tokens, dozens of valid cloud credentials and NPM tokens, and roughly twenty thousand files leaked. In many cases, the malware appears to have run on developer machines, often via the NX VSCode extension. We’ve also observed cases where the malware ran in build pipelines, such as Github Actions.

"On August 27, 2025 9AM UTC Github disabled all attacker created repositories to prevent this data from being exposed, but the exposure window (which lasted around 8 hours) was sufficient for these repositories to have been downloaded by the original attacker and other malicious actors. Furthermore, base64-encoding is trivially decodable, meaning that this data should be treated as effectively public."

Re: Malicious versions of Nx and some supporting plugins were published

#147
post #4

Honest to goodness, I do most of my coding in a VM now. I don't see how the security profile of these things are tolerable. The level of potential hostility from agents as a malware vector is really off the charts. We're entering an era where they can scan for opportunities worth >$1,000 in hostaged data, crypto keys, passwords, blackmail material or financial records without even knowing what they're looking for whe…

Similar, but in a podman container which shares nothing other than the source code directory with my host machine.

I do too, but I found it non-trivial to actually secure the podman container. I described my approach here [1]. I'm very interested to hear your approach. Any specific podman flags or do you use another tool like toolbx/distrobox?

[1]: https://evertheylen.eu/p/probox-intro/

Re: Malicious versions of Nx and some supporting plugins were published

#148
post #11

People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simpl…

I’d like a package manager that essentially does a git clone, and a culture that says: “use very few dependencies, commit their source code in your repo, and review any changes when you do an update.” That would be a big improvement to the modern package management fiasco.

sounds like the best way to miss critical security upgrades

Re: Malicious versions of Nx and some supporting plugins were published

#149

It would be surprising if claude code would actually run that prompt, so I tried run it: > I can't help with this request as it appears to be designed to search for and inventory sensitive files like cryptocurrency wallets, private keys, and other secrets. This type of comprehensive file enumeration could be used maliciously to locate and potentially exfiltrate sensitive data. If you need help with legitimate securit…

Incredibly common W for Anthropic safeguards. In almost every case I see Claude go head-to-head on refusals with another model provider in a real-world scenario, Claude behaves and the other model doesn't. There was a viral case on Tiktok of some lady going through a mental health episode who was being enabled and referred to as "The Oracle" by ChatGPT, but when she swapped to Claude, Claude eventually refused and told her to speak to a professional.

That's not to say the "That's absolutely right!" doesn't get annoying after a while, but we'd be doing everyone a disservice if we didn't reward Anthropic for paying more heed to safety and refusals than other labs.

Re: Malicious versions of Nx and some supporting plugins were published

#150

Earlier quoted context omitted.

npm workspaces and npm scripts will get you further than you might think. Plenty of people got along fine with Lerna, which didn't do much more than that, for years. I will say, I was always turned off by NX's core proposition when it launched, and more turned off by whatever they're selling as a CI/CD solution these days, but if it works for you, it works for you.

I'd recommend pnpm over npm for monorepos. Forcing you to be explicit about each package's dependencies is good. I found npm's workspace features lacking in comparison and sparsely documented. It was also hard to find advice on the internet. I got the sense nobody was using npm workspaces for anything other than beginner articles.

After 10 years or so enduring the endless cycle of "new thing to replace npm", I'm using: npm. And I'm not creating monorepos.
Post reply on HN