Summarizer

Can't speak for other devs but I like to read postinstall scripts or at least put them through an LLM if they're too hard to grok. It's also a little context dependent, for example if I was using Axios and I see a prompt to run the plain-crypto-js postinstall script, alarm bells would instantly ring, which would at least make me look up the changelog to see why this is happening. In most cases I don't even let them run unless something breaks/doesn't work as expected.

Was this an drive-by/auto-install attack?

I recommend everyone to use bwrap if you're on linux and alias all package managers / anything that has post build logic with it. I have bwrap configured to override: npm, pip, cargo, mvn, gradle, everything you can think of and I only give it the access it needs, strip anything that is useless to it anyway, deny dbus, sockets, everything. SSH is forwarded via socket (ssh-add). This limits the blast radius to your CWD and package manager caches and often won't even work since the malware usually expects some things to be available which are not in a permissionless sandbox. You can think of it as running a docker container, but without the requirement of having to have an image. It is the same thing flatpak is based on. As for server deployments, container hardening is your friend. Most supply chain attacks target build scripts so as long as you treat your CI/CD as an untrusted environment you should be good - there's quite a few resources on this so won't go into detail. Bonus points: use the same sandbox for AI. Stay safe out there.

> SSH is forwarded via socket Maybe I misunderstood this point. But the ssh socket also gives access to your private keys, so I see no security gain in that point. Better to have a password protected key.

The problem is that package managers are a distraction. You have to sandbox everything or else it doesn't work. These attacks use post-install hooks for convenience but nothing would have stopped them patching axios itself and just waiting for devs to run the app on their local workstation. So you end up needing to develop in a fully sandboxed environment.

Yeah the whole rush on "post-run hooks bad" isn't really adding all that much to security. Like congratulations, your dev was compromised whole 10 minutes later after he ran code.

# If you have a projects folder containing multiple projects on macOS, you can run this script to recursively scan all subfolders for vulnerable axios versions and the presence of plain-crypto-js, helping you quickly identify potentially affected projects: find . -name "package.json" -exec sh -c ' dir=$(dirname "{}") echo "==== $dir ====" cd "$dir" npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4" grep -A1 "\"axios\"" package-lock.json 2>/dev/null | grep -E "1\.14\.1|0\.30\.4" [ -d node_modules/plain-crypto-js ] && echo "POTENTIALLY AFFECTED" ' \;

Setting min-release age to 7 days is great, but the only true way to protect from supply chain attacks is restricting network access. This needs to be done (as we've seen from these recent attacks) in your devenv, ci/cd and prod environments. Not one, or two, but all of these environments. The easiest way is via using something like kubernetes network policies + a squid proxy to allow limited trusted domains through, and those domains must not be publicly controllable by attackers. ie. github.com is not safe to allow, but raw.githubusercontent.com would be as it doesn't allow data to be submitted to it. Network firewalls that perform SSL interception and restrict DNS queries are an option also, though more complicated or expensive than the above. This stops both DNS exfil and HTTP exfil. For your devenv, software like Little Snitch may protect your from these (I'm not 100% on DNS exfil here though). Otherwise run your devenv (ie vscode) as a web server, or containerised + vnc, a VM, etc, with the same restrictions.

Ran npm ci --ignore-scripts in our CI for months but never thought about local dev. Turns out that's the gap, your CI is safe but your laptop runs postinstall on every npm install. The anti-forensics here are much more complicated that I had imagined. Sahring after getting my hands burned. After the RAT deploys, setup.js deletes itself and swaps package.json with a clean stub. Your node_modules looks fine. Only way to know is checking for artifacts: /Library/Caches/com.apple.act.mond on mac, %PROGRAMDATA%\wt.exe on windows, /tmp/ld.py on linux. Or grep network logs for sfrclak.com. Somehow noboady is worried about how agentic coding tools run npm install autonomously. No human in the loop to notice a weird new transitive dep. That attack surface is just getting worsened day by day.

I am now migrating all my unencrypted secrets on my machines to encrypted ones. If a tool supports scripted credential providers (e.g. aws-cli or Ansible), I use that feature. Otherwise, I wrap the executable with a script that runs gpg --decrypt and injects an environment variable. That way, I can at least limit the blast radius when (not if) I catch an infostealer.

In light of these nonstop supply chain attacks: Tonight I created /supply-chain-audit -- A simple claude code skill that fetches info on the latest major package vulnerability, then scans your entire ~/ and gives you a report on all your projects. https://github.com/IsaacGemal/claude-skills It's a bit janky right now but I'd be interested to hear what people think about it.

That sounds terrifying. Stay out of my ~/ thank you very much.

I am not saying this is the reason for this compromise but the sudden explosion of coding assistant like claude code, and tools like openclaw is teaching entire crop of developers (and users) that it is ok to have sensitive credentials .env files.

Where would you suggest putting the sensitive credentials?

Not in .env files next to your code that is exposed to supply chain risks.

Do we have a way yet to tell if something on our system is compromised? There's plenty of end user software built on node, like Gemini CLI and LM Studio.

Running almost anything via npx will trigger this

yet another npm supply chain attack, these are becoming as ubiquitous as gun violence in the US. We have become numb to it. One of my tools, bruno, was impacted but seems to be limited to cli via npm install [1] [1] https://github.com/usebruno/bruno/security/advisories/GHSA-6...