GitLab discovers widespread NPM supply chain attack

No thats not what i want, that whats i need when i use something like npm.

Which can't be the right way.

Here I go again: Plan9 had per-process namespaces in 1995. The namespace for any process could be manipulated to see (or not see) any parts of the machine that you wanted or needed.

I really wish people had paid more attention to that operating system.

That can only go so far. Assuming there is no container/VM escape, most software is built to get used. You can protect yourself from malicious dependencies in the build step. But at some point, you are going to do a production build, that needs to run on a production system, with access to production data. If you do not trust your supply chain; you need to fix that.

If you excuse me, I have a list of 1000 artifacts I need to audit before importing into our dependency store.

Absolutely, good old VMs can really provide the needed isolation while still having good UX. I just published a post on setting up dev VMs with Lima: https://www.metachris.dev/2025/11/sandbox-your-ai-dev-tools-...

Containers don't help much when you deploy malware into your systems, containers are not and never will be security tools on Linux, they lack many needed primitives to be able and pull off that type of functionality.

Why think about the consequences of your actions when you can use docker?

Why distro do you run? Python is a part of the os in many cases ?

It’s a fair angle your taking here, but I would only expect to see it on hardend servers.

Ok, but if you distrust the library so much it needs to go in a VM, what the hell are you doing shipping it to your customers?

...but the github runners already are virtualized; you'd need to virtualize the secrets they have access to instead.

nixos solves this without vms

But.. but... we're all friends here!

Very few packages published on npm include polyfills, especially packages you'd use when doing local scripting.

“Whenever you find yourself on the side of the majority, it is time to pause and reflect." — Mark Twain (supposedly)

Yes. KeePassXC is all you need on Linux to have a compatible secret store.

The defacto install of github CLI on ubuntu systems appears to be snap which is owned by some random dude...

Plan9 had per-process namespaces in 1995.

One could easily allow or restrict visibility of almost anything to any program. There were/are some definite usability concerns with how it is done today (the OS was not designed to be friendly, but to try new things) and those could easily be solved. The core of this existed in the Plan9 kernel and the Plan9 kernel is small enough to be understood by one person.

I’m kinda angry that other operating systems don’t do this today. How much malware would be stopped in its tracks and made impotent if every program launched was inherently and natively walled off from everything else by default?

> But protecting specific directories is just whack-a-mole. The real fix is to properly sandbox code - an access whitelist rather than blacklist

I believe Wayland (don't quote me on this because I know exactly zero technical details) as opposed to x is a big step in this direction. Correct me if I am wrong but I believe this effort alone has been ongoing for a decade. A proper sandbox will take longer and risks being coopted by corporate drones trying to take away our right to use our computers as we see fit.

What is a proper solution for this? I don't imagine gpg can help if you encrypt it but decrypt it when you login to gnome, right? However, it would be too much of a hassle to have to authenticate each time you need a token. I imagine macOS people have access to the secure enclave using touch ID but then even that is not available on all devices.

I feel like we are barking up the wrong tree here. The plain text token thing can't be fixed. We have to protect our computers from malware to begin with. Maybe Microsoft was right to use secure admin workstations (saw) for privileged access but then again it is too much of a hassle.

> And worst thing, afaik there is no way do do it correctly in MacOS for example. I'd like to be corrected though.

https://developer.apple.com/documentation/security/keychain-...

And similar services exist on Linux desktops. There are libraries that will automatically pick the right backend.

For what it’s worth, the recommended way of getting credentials for AWS would be either:

1. Piggyback of your existing auth infra (eg: ActiveDirectory or whatever you already have going on for user auth) 2. Failing that use identity center to create user auth in AWS itself

Either way means that your machine gets temporary credentials only

Alternatively, we could write an AWS CLI helper to store the stuff into the keychain (maybe someone has)

Not to take away from your more general point

We need flatpak for CLI tools

This doesn't sound like a technical problem to me. Even my throw-away bash scripts call to `secret-tool lookup`, since that is actually easier than implementing your own configuration.

Also this is a complete non-issue on Unix(-like) systems, because everything is designed around passing small strings between programs. Getting a secret from another program is the same amount of code, as reading it from a text file, since everything is a file.

> no way do do it correctly in MacOS

What? The MacOS Keychain is designed exactly for this. Every application that wants to access a given keychain entry triggers a prompt from the OS and you must enter your password to grant access.

Also badly named commands, `npm install` updates your packages to the latest version allowed by package.json and updates the lock file, `npm ci` is what people usually want to do: install the versions according to the lock file.

IMO, `ci` should be `install`, `install` should be `update`.

Plus the install command is reused to add dependencies, that should be a separate command.

> The culture with using version ranges for dependency resolution

Yep, auto-updating dependencies are the main culprit why malware can spread so fast. I strongly recommend the use `save-exact` in npm and only update your dependencies when you actually need to.

To add a few:

* NPM has a culture of "many small dependencies", so there's a very long tail of small projects that are mostly below the radar that wouldn't stand out initially if they get a patch update. People don't look critically into updated versions because there's so many of them.

* Developers have developed a culture of staying up-to-date as much as possible, so any patch release is applied as soon as possible, often automated. This is mainly sold as a security feature, so that a vulnerability gets patched and released before disclosure is done. But it was (is?) also a thing where if you wait too long to update, updating takes more time and effort because things keep breaking.

This is my take as well. I've never come accross a JS project where the built-in datastructures were exclusively used.

One package for lists, one for sorting, and down the rabbit hole you go.

This is the main reason. Pythons ecosystem also has silly trends and package churn, and plenty of untrained developers. It’s the lack of a proper standard library. As bad a language as it may be, Java shows how to get this right.

Also: a culture of constant churn in libraries which in combination with the potential for security bugs to be fixed in any new release leads to a common practice of ingesting a continual stream of mystery meat. That makes filtering out malware very hard. Too much noise to see the signal. None of the above cultural factors is present in the other ecosystems.

Unfortunately, blindly installing dependencies at compile-time is something that many projects will do by default nowadays. It's not just "more amateur developers" who are at risk here.

I've even seen "setup scripts" for projects that will use root (with your permission) to install software. Such scripts are less common now with containers, but unfortunately containers aren't everything.

Python absolutely can run scripts in installation. Before pyproject.toml, arbitrary scripts were the only way to install a package. It's the reason PyPi.org doesn't show a dependency graph, as dependencies are declared in the Turing-complete setup.py.

Deno has tackled some of these issues with their permission system, but afaik it can only be applied to apps, not to dependencies.

What we really need is a system to restrict packages in what they can do (for example, many packages don't need network access).

Python wheels don't run arbitrary code on install, but source distributions do. And you can upload both to pypy. So you would have to run

pip install <package> --only-binary :all:

to only install wheels and fail otherwise.

The article has some indicators of compromise, the main one locally would be .truffler-cache/ in the home directory. It’s more obvious for package maintainers with exposed credentials, who will have a wormed version of their own packages deployed.

From what I’ve read so far (and this definitely could change), it doesn’t install persistent malware, it relies on a postinstall script. So new tokens wouldn’t be automatically exfiltrated, but if you npm install any of an increasing number of packages then it will happen to you again.

> Is this true? God I hope not, if developers don't even follow basic security practices then all hope is lost.

"Basic security practices" is an ever expanding set of hoops to jump through, that if properly followed, stop all work in its tracks. Few are following them diligently, or at all, if given any choice.

Places that care about this - like actually care, because of contractual or regulatory reasons - don't even let you use the same machine for different projects or customers. I know someone who often has to carry 3+ laptops on them because of this.

Point being, there's a cost to all these "basic security practices", cost that security practitioners pretend doesn't exist, but in fact it does exist, and it's quite substantial. Until security world acknowledges this fact openly, they'll always be surprised by how people "stubbornly" don't follow "basic practices".

I think so. I know too many developers who cannot be bothered to have a password-manager, beyond the chrome/firefox default one. Anything else, and even those, are usually "the standard 2-3 passwords" they use.

How do you do this in practice?

If I just need to `fly secrets set KEY=hunter2` one time for production I can copy it from a paper pad even but if it's a key I need to use every time I run a program that I'm developing on, it's likely going to end up at least being in my program's shell environment (and thus readable from its /proc/pid/environ). So if I `npm install compromised-package` – even from some other terminal – can't it just `grep -a KEY= /proc/*/environ`?

Or are you saying the programs we hack on should use some kind of locker api to fetch secrets and do away with env vars?

That's the collective choice of the authors of those packages. A go module path is literally just the canonical URL where you can download the module.

The golang modules core to the language are hosted at golang.org

Module authors have always been free to have their own prefix rather than github.com, even if they host their module on Github. If they say their module is example.com/foo and then set their webserver to respond to https://example.com/foo?go-get=1 with <meta name="go-import" content="example.com/foo mod https://github.com/the_real_repository/foo"> then they will leave no hint that it's really hosted at github, and they could host it somewhere else in future (including at https://example.com directly if they want)

https://go.dev/ref/mod#vcs

Another feature is that go uses a default proxy, https://proxy.golang.org/, if you don't set one yourself. This means that Google, who control that proxy, can choose to make a request for a package like github.com/foo/bar go to some place else, if for whatever reason Microsoft won't honour it any more.

Golang builds pulling a github.com/foo/bar/baz module don't rely on any GitHub "build workflow", so unless you mean they're going to start restricting or charging for git clones for public repos (before you mention Docker Hub, yes I know), nothing's gonna change. And even if they're crazy enough to do that, Go module downloads default to a proxy (proxy.golang.org by default, can be configured and/or self-hosted) and only fall back to vcs if the module's not available, so a module only needs to be downloaded once from GitHub anyway. Oh and once a module is cached in the proxy, the proxy will keep serving it even if the repo/tag is removed from GitHub.

"The original Java platform" had no package management though, that came with Maven and later Gradle, that have similar vectors for supply chain attacks (that is, nobody reviews anything before it's made available on package repositories).

And (to put on my Go defender hat), the Go ecosystem doesn't like having many dependencies, in part because of supply chain attack vectors and the fact that Node's ecosystem went a bit overboard with libraries.

Sure, but until the malware spreads quickly you don't know you need the rule.

IDK. I usually notice it when it breaks the install

Yes, it can break deps, some will not install. Puppeteer is a good example because it installs binaries. But it also shows an error with the cmd needed to complete the installation.

Why it is allowed by default?

> it’s npm’s belief that the utility of having installation scripts is greater than the risk of worms.

NPM co-founder Laurie Voss

https://blog.npmjs.org/post/141702881055/package-install-scr...

fs and net can be mitigated with `--permission`

https://nodejs.org/api/permissions.html

Regardless, it’s worth using `--ignore-scripts=true` because that’s the common vector these supply chain attacks target. Consider that when automating the attack, adding it to the application code is more difficult than injecting it into life-cycle scripts, which have well-known config lines.

Nothing, but at least you'll have time to see the audit if it's aware.

To delay updates, you mean?

I'm curious though: how do you avoid being stuck on the _vulnerable_ versions, delaying updates?

Because bias and incentives matter.

There's a reason disclosures are obligatory in academic papers.

It didn’t make it less insightful, but it recontextualized what was, in hindsight, a pretty strong bias towards fearmongering.

> Our internal monitoring system has uncovered multiple infected packages containing what appears to be an evolved version of the "Shai-Hulud" malware.

Although it's not entirely new, it's something else.

Like an egregious comment?

C (actually POSIX) has a hashmap implementation: https://man7.org/linux/man-pages/man3/hsearch.3.html

What it doesn't have is a hashmap type, but in C types are cheap and are created on an ad-hoc basis. As long as it corresponds to the correct interface, you can declare the type anyway you like.

Often yes, specialized to the specific thing I am doing. Eg: for a JIT translator one often needs a combo hash-map + LRU, where each node is a member of both structures.

    char * 
    left_pad (const char * string, unsigned int pad)
    {
        char tmp[strlen (string)+pad+1];
        memset (tmp, ' ', pad);
        strcpy (tmp+pad, string);
        return strdup (tmp);
    } 

Doesn't sound too hard in my opinion. This only works for strings, that fit on the stack, so if you want to make it robust, you should check for the string size. It (like everything in C) can of course fail. Also it is a quite naive implementation, since it calculates the string size three times.

snprintf(buf, bufsize, "%*s", padwidth, str)?

While it can happen to anyone npm does preselect the users most likely to unknowingly amplify such an attack. Just today I was working on a simple JS script while disconnected from the Internet, Qwen Coder suggested I “npm install glob” which I couldn’t because there was no internet, so I asked for an alternative and sure enough the alternative solution was two lines of vanilla JS. This is just one example but it is the modus operandi of the NPM ecosystem.

> it' wasn't some magical property of windows

no, it really was windows

right, npm users. The extreme demand for simple packages and the absent consideration creates an opportunity for attackers to insert "free" solutions. The problem are the 'npm install' happy developers no doubt.

Both of those have over >400 dependencies each [0] [1] but just in Rust instead - there hasn't been a Rust supply chain attack yet but is this any better? [2]

Admittedly you're not normally downloading the dependencies to your machine as you're often using pre-built binaries, but a malicious package could still run if a version was shipped with it.

[0]: https://github.com/biomejs/biome/blob/93182ea8e9d479fd0187ce...

[1]: https://github.com/oxc-project/oxc/blob/65bd5584bfce0c7da90f...

[2]: https://users.rust-lang.org/t/yet-another-npm-supply-chain-a...

How would the homeless chap have the creds or gravitas for people to trust him or her?

You don’t need certificates , just use PGP keys like Maven.

This was largely the reason I rejected "real name verification" ideas at GitHub after the xz attack. (Especially if they are state sponsored) it's not that hard for a dedicated actor (which xz certainly was) to get a quality stolen identity.

The inevitable evolution of such a feature is a button on your repo saying" block all contributors from China, Russia, and N other countries". I personally think that's the antithesis of OSS and therefore couldn't find the value in such a thing.

As I understand it, this attack works because the worm looks for improperly stored secrets/keys/credentials. Once it find them it publishes malicious versions of those packages. It hits NPM because it’s an easy target… but I could easily imagine it hitting pip or the repo of some other popular language.

In principle, what’s stopping the technique from targeting macos CI runners which improperly store keys used for Notorization signing? Or… is it impossible to automate a publishing step for macos? Does that always require a human to do a manual thing from their account to get a project published?

Well they clearly lacked marketing? Pretty sure a red text in npm every time that package was installed that says "hey we have a better way to do this with node alone" would have made a dent in the library usage, but they didn't do anything of the sort.

Pretty sure Microsoft is exponentially bigger than 99% of the library authors out there, and add to that the giant communication channel that GitHub gives it over developers, so the analogy breaks pretty fast.

Or anti-virus companies selling more of their wares.

This kind of large scale attack is perfect advertising for anyone selling protection against such attacks.

Spy agencies have no interest in selling protection.

A one or two off can be a false flag, thousand upon thousands is not going to be a false flag.

SBOMs exist. You can get them generated for most software via package managers in standard forms like cyclonedx.

It's just not that effective when the SBOM becomes unmanageable. For example, our JS project at $work has 2.3k dependencies just from npm. I can give you that SBOM (and even include the system deps with nix) but that won't really help you.

They are only really effective when the size is reasonable.

SBOM really doesn't do much when compromise happens before or while you are building it. It really is orthogonal to these types of attacks. Best you can do is to find that you were compromise afterwards.