Mitigate this attack vector by adding:
ignore-scripts=true
Shai-Hulud Returns: Over 300 NPM Packages Infected
261–270 of 797 posts
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#262My motto wrt language choices: "It's the standard lib, stupid!" My ultra hot take: there are only¹ two² programming ecosystems suitable for serious³ work: - .net (either run on CLR or compile as an AOT standalone binary) - jvm The reason why is because they have a vast and vetted std lib . A good standard lib is a bigger boost then any other syntactic niceties. __ 1. I don't want other programming languages to die, s…
Arguably both Go and Python also have great stdlibs. The only advantage that JVM and .NET have is a default GUI package. Which is fair, but keeps getting less and less relevant as people rely more on web UIs.
.Net has Blazor for WebUI.
I don't ask you to judge if you like it, I'm just saying that you can totally make a professional WebUI within the dotnet stdlib.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#263Slightly OT, but who is HelixGuard? The website is a mess (broken links, broken UI elements, no about section) There is no history on webarchive. There is no information outside of this website and their "customers" are crypto exchanges and some japanese payment provider. This seems a bit fishy to me - or am I too paranoid?
Based in Singapore / Japan according to X: https://x.com/HelixGuard_ai
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#264Earlier quoted context omitted.
It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…
I think this is right about Rust and Cargo, but I would say that Rust has a major advantage in that it implements frozen + offline mode really well (which if you use, obviously significantly decreases the risks). Any time I ever did the equivalent with NPM/node world it was basically unusable or completely impractical
Pnpm (a very popular npm replacement) makes completely locked packages easy and natural and ultra fast:
Benchmarks:
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#265Serious question: should someone develop new technologies using Node any more? A short time ago, I started a frontend in Astro for a SaaS startup I'm building with a friend. Astro is beautiful. But it's build on Node. And every time I update the versions of my dependencies I feel terrified I am bringing something into my server I don't know about. I just keep reading more and more stories about dangerous npm packages…
It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…
I have a similar opinion but I think Java's model with maven and friends hits the sweet spot:
- Packages are always namespaced, so typosquating is harder - Registries like Sonatype require you to validate your domain - Versions are usually locked by default
My professional life has been tied to JVM languages, though, so I might be a bit biased.
I get that there are some issues with the model, especially when it comes to eviction, but it has been "good enough" for me.
Curious on what other people think about it.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#266Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#267Both of these attacks have used trufflehog. Is there an out of the box way to block that executable by name or signature?
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#268Earlier quoted context omitted.
> That is true, but the hand-rolled StringUtil won't steal your credentials and infect your machine, which is the problem here. Yeah, that's why I said that this is the other end of the pendulum. > In C/C++ world, if it takes less than a couple hours to write, you might as well do it yourself rather than introduce a new dependency. Oh I'm aware of that. My point still stands - that comes at a serious maintenance cost…
Wait what? That’s just fearmongering, how hard is it to add a few methods that split a string or pad it? It’s not rocket science.
> how hard is it to add a few methods that split a string or pad it?
In full generality, pretty hard. If you're just dealing with ASCII or Latin-1, no problem. Then add basic Unicode. Then combining characters. Then emojis. It won't be trivial anymore.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#269Earlier quoted context omitted.
Static scanning won't help. You can write this["eval"]() instead of eval(), therefore you can write this["e" + "v" + "a" + "l"](), and you can substitute (!![]+[])[!+[]+!+[]+!+[]] for "e", (![]+[])[+!+[]] for "a" (and so on: https://jsfuck.com/ ) In this Turing-equivalent world, you can only know what actually executes (e.g. eval, fetch) by actually executing all code in the package and then see what functions got ex…
There's always some mathematician who tries to prove that locks on your doors "won't help" because the universe is infinite. Narrator: it is not
Deciding to put your resources into something that only a really stupid criminal would be caught by gives you a false sense of security.
Literally scanning for just "eval(" is entirely insufficient. You have to execute the code. Therefore you have to demand module authors describe how to execute code, e.g. provide a test suite, which is invoked by the scanner, and require the tests to exercise all lines of code. Provide facilities to control the behaviour of functions outside the module so that this is feasible.
This is a lot of work, so nobody wants to do it, so they palm you off with the laziest possible solution - such as literally checking for "eval(" text in the code - which then catches zero malware authors and wastes resources providing help to developers caught as a false positive, meanwhile the malware attacks continue unabated because no effective mechanism to stop them has been put in place.
Reminds me of the fraudster who sold fake bomb detectors to people who had a real need to stop bomb attacks. His detectors stopped zero bomb attacks. https://www.bbc.co.uk/news/uk-29459896
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#270Earlier quoted context omitted.
Nah - dependency cooldown is all the rage but it’s only effective if you have some noncompliant canary users. Once everyone is using it it will cease to be effective because nobody will be taking the first step/risk until everybody does.
The point of the cooldown is to allow time for vendor scans to complete and for compromised packages to be pulled. It's not about waiting for an end user to notice they've been compromised. > Meanwhile, the aforementioned vendors are scanning public indices as well as customer repositories for signs of compromise, and provide alerts upstream (e.g. to PyPI). https://blog.yossarian.net/2025/11/21/We-should-all-be-using…
Depending on “security vendors” to do scans of every single update seems naive and over optimistic to me, but hey - everyone’s jumping on the bandwagon regardless of what I think so I guess we’ll see soon.