‘No way to prevent this’, Says Only Development Community Where This Regularly Happens
— <https://itnext.io/no-way-to-prevent-this-says-only-developme...>
At this point I would very much like to get off Mr Bones' Wild Ride but I fear this is going to continue to happen because, from my own exploration at least, a large number of commercial detection strategies are directed at the repo/device/developer level when loading/using a package.
This seems analogous to how we tackle email spam and general malware. It means that there is almost always a target valuable enough for bad actors to continue trying. However, unlike email (mostly...), package managers are centralised authorities (and anything out-of-band is surely the developers problem?).
My ill-informed feeling is that we might need to change the culture of lazy versioning with rapid releases and focus on stable, deeply scanned versions at registries. There will be some effect of volume and scale so I could be off, but it still seems telling that this impacts high-churn languages more often.
I don't know, I would love a comprehensive article that explores the landscape right now.
Wondering about Mr Bones' Wild Ride and suspecting it might be a reference to the 1991 movie Nothing But Trouble I took a look, and found I had remembered it wrong.
The roller coaster in that movie was called Mr Bonestripper, https://www.youtube.com/watch?v=NEZEgd8GjJc .
Instead it comes from Roller Coaster Tycoon 2, https://knowyourmeme.com/memes/mr-bones-wild-ride .
As for the comparison with spam, there we kind of settled on making people accept spam by vacuuming up their email addresses in pretty much every commercial and social computer network setting, giving it a veneer of legitimacy. I think it is likely to happen in this area too, perhaps some combination of Oracle licensing surveillance agent style software and automated dependency management, i.e. 'solving' supply chain malware by whitelisting some other malware.
There's also Mr. Toad's Wild Ride at Disney parks, https://en.wikipedia.org/wiki/Mr._Toad%27s_Wild_Ride
> Docker Container Escape
> The payload checks for the Docker socket and, if present, attempts container escape through three sequential methods:
So even if you're running devcontainers / VMs, these worms are already trying to escape.
Make sure you're running a rootless VM engine (e.g. podman instead of docker) !
Despite what some people will tell you (including many in the security indistry), Docker is not a strong security boundary, and it should not be treated as one. It shares a kernel with the running system.
It reminds me of the good old days when people would hand out low privilege Linux accounts and rely on the kernel to prevent privilige escalation. Docker is literally the same thing, just with extra steps. Especially today with new kernel LPE'S dropping every 5 minutes.
Yes, Podman is a bit better because you arent handing the attacker root, but... why hand them an account at all? Just use a grown up VM.
Or don't mount the Docker socket into containers
I really wish we would’ve gotten something more like jails or zones. Or better yet put the containers in a jail or zone. Is there a comprehensive sandbox for Linux like the bsds have?
Unprivileged LXCs get pretty close. Less unified design wise but on some aspects better - kernel escape doesn’t land you on a 0 UID
Why not run a proper virtual machine?
That's the direction container runtimes are trending
Amazon has been doing it with Firecracker for a while and Kata containers is another popular one
I dunno, why own a car when you could ride your bike instead? They’re just different things and people may choose to use one over the other for a variety of reasons.
> Make sure you're running a rootless VM engine (e.g. podman instead of docker) !
Aren't most people running docker rootless (at least on Linux)? Does podman do more?
The docker CLI tool is normally executed with user privileges, but there's dockerd, a daemon running as root that actually does the container execution.
Installing docker doesn't require root.
"Rootless mode lets you run the Docker daemon and containers as a non-root user."
https://docs.docker.com/engine/security/rootless/
This is how docker is best installed on Linux, and there's a convenience script for it as well (https://get.docker.com/rootless). I am surprised that's not how people are using docker.
im not sure people understand the security vectors. a user with docker permissions effectively has root permissions.
often, docker in docker is used to manage docker orchestration. putinng a user in a docker and peoviding docker access is security through obscurity.
on the flip side, i see people blindly installing tools and skills not understanding they are pushing context and capabilities without any significant security features.
Imagine mythos is actually exceptional hacker. if you give it a well crafted malicious prompt, its going to even more insecure.
the double edged sword is really fascinating to think about
Docker has not required root for a long time, at least on Linux. There's even a convenience script for it: https://get.docker.com/rootless
Almost everyone I know installs docker rootless.
docker service that sets up containers runs as root. podman does away with that service.
You may run
> podman info --format '{{.Host.Security.Rootless}}'
to ensure podman is rootless in your config.
i wish opencode would have a protocol that puts real guardrails around its agents. rather that gaving to try and transplant weve had ssh for decades, surely you can wire a xomms pathway that cant deciate.
The situation is getting crazy ... personally I have already uninstalled node, python and all package managers from my machine and instead only use them in devcontainers / VMs.
But even if the dev community comes up with super hardened security, I fear in at least a year the models will be good enough in social engineering that we are still running a losing game.
how do containers solve the problem? if they are connected to the internet (and they are) you have got the same problem, if the credentials can be read by the container, at least to my understanding
On my personal machine, I run OpenSnitch. Much better defense against data exfil if you reject outbound connections to unexpected/unwanted hosts.
For credential stealing, that is true, but at least it would protect your local machine. But I just read these worms also try container escape ...
We need to prevent direct connections to internet for containers... once you have a proxy, predefined credentials (api keys) can maybe be added there (per container/target).
the model most people are talking about is in the cloud. for the harness to do useful work, it needs to talk to the cloud
the trouble is, we need protocols that are software determined that force AI interaxtions into limited scope but currently theyre all just bash adjacent and inherit your tools.
You need to use full isolated VM with its own kernel. But then again, I've read somewhere that this malware is also trying to escape the VM isolation as well...
One solution I haven’t seen recommended much is to have a Claude instruction/skill that explicitly audits the diff of every upgrade, and force this manual audit as part of your upgrade workflow. This seems like it would work pretty reliably.
This is what many AI supply-chain security startups (like the one that posted the article) are already doing with all NPM packages, so save yourself the Claude tokens. All of these compromises were detected within minutes, but it takes some time (<1 hour) for NPM to unpublish all of the affected packages.
And this is partly why my development machine is a Raspberry Pi that I can image any time by removing the SD card: https://blog.jgc.org/2026/04/raspberry-pi-as-isolated-ai-cod...
Vendor your dependencies, clone or port them where needed, and freeze them. Most good packages these days do not have a deep dependency tree, and we should stop using the ones that do.
I spent a week with claude and codex re-implementing several packages which had dependency trees deeper than I would like.
Most of these packages are trivial to clone.
"But now you're not getting the upstream fixes" they will say.
"So what?" I reply
Wouldn't just having devs pin/not upgrade packages accomplish about as much, have the added benefit that if a package is discovered malicious it would auto get removed but if get already vendored you’d still have the vulnerability on your vendored copy, and pinning versions seems like it would be more likely for devs to do than vendoring?
Pretty wary of the entire JS/nodejs ecosystem at this stage.
Given general software quality of the js ecosystem, the proliferation of supply chain attacks was just matter of time. I’m curious how other ecosystems will hold (eg Rust)
Same. At this point I just started using virtual machines for any project that pulls in packages from outside Linux distribution repositories.
aube (npm/yarn/pnpm drop-in alternative) now has a "jailBuilds" flag that restricts access to network/filesystem access.
https://aube.en.dev/package-manager/jailed-builds.html
But this feels like a cat/mouse game.
dino was wired with security in mind, but you can see developers dont tend towards aecurity
Because there is a time and effort cost to swap over to another framework/runtime even if it brings benefits, and security is always considered "good for now" unfortunately.
That is what made Bun popular, and tools like uv/pip, oxlint/eslint, orbstack/docker desktop, and the list goes on. Drop-in replacements where we get 10x with little effort.
Another day, another pre/postinstall script executed that could have easily have been prevented by any sane package manager. NPM really desperately needs an 'allowBuilds' style allowlist [1] and 'approve-builds' command [2].
After I upgraded pnpm to v11, I set all allowBuilds to false and have not observed any failures. Made me wonder why the packages even need build scripts. My guess is for obscure or old platforms, but for most users running on Linux or Darwin build scripts seem to be unnecessary.
> Made me wonder why the packages even need build scripts
As the name implies it's for building stuff. Most (all?) packages that use C++ FFI with node-gyp need it. A popular package that needs it is re2.
Many newer packages bundle prebuilt native code as transitive dependencies, so build scripts are less needed than before.
> Made me wonder why the packages even need build scripts.
Historically it was to accommodate packages like the original SASS compiler:
https://sass-lang.com/ruby-sass/
Other times it was to avoid shipping binaries due to, erm, safety concerns. The package would include code in a different language, which in turn would compile into a binary library or executable.
If you think about it, this is actually a new kind of security. Security by numbers. Overwhelm the attackers with so many compromised services and devices that they get a reverse denial of service. It's inspired by nature in herd animals.
Security by giving up
Node is the Visual Basic of our day, if Visual Basic had the ability to update itself from a thousand strangers, any minute of the day, without the user-developer having any clue what is going on behind the scenes unless they apply the very skills that would have precluded their use of Node/Visual Basic in the first place.
All that ease-of-development is being paid for by ease-of-rooting.
Another supply chain attack found and blocked in a day. Everyone regularly using npm to install new packages should be using npm's min-release-age setting to avoid package versions that are newer than a few days old to avoid most attacks in practice like this. You can set it to two days with `npm config set min-release-age=2` for example. https://cooldowns.dev/ has info about equivalent settings in other dependency managers like PyPI and Cargo.
Or just use dependencies from 6 years ago and never update them like most companies i ever worked for.
As similar to 1st wave of Shai Hulud, this also got it through opentionalDependency. intresting
i run all my stuff in vm's built with nix
not as easy as docker, but i have a few bash scripts that simplify things for me a lot
i hope that this protects me from the sweep attacks at least
Because of course it’s npm
Does npm stand for "newly packaged malware"?
Akshully, "Node Packaged Malware."
Needs more recursion.
NPM - NPM Packaged Malware
should be a meme
Every programming language package manager is affected. Any random person can sign up and push packages. They are all equivalent to the Arch Linux User Repository and have the exact same caveats.
I’m honestly at a point where I’m afraid to update any of my project’s dependencies, and I’m also afraid to run the locally without some locked down VM
I use Tanstack in my projects. Last week when Tanstack got compromised, it was only my laziness that saved me -- was thinking about doing pnpm upgrade but got lazy and played some dota... Finished game was just going to pnpm upgrade, opened hacker news and boom! news hit.
Since then, I had set up libvirt/qemu based VM with another Linux running in it specifically for development. Now I run all of docker, kubernetes, IDE, pnpm, uv, etc in that VM and removed them from host. The only write capable secret VM has access to, is my passphrase protected ssh key, which I can quickly revoke from my Github account in case of compromise. Feels much safer now.
I also was at this point, and I decided to add cooldowns to every project.
Yeah, I agree, but then you are at the mercy of whatever vulnerability is found in the current version(s). It just feels like a lose-lose situation no matter what you do.
You can still update to new versions even if the new release is still in cooldown phase. You just have to be explicit that you want the new release.
pnpm audit —fix for example will whitelist releases in cooldown phase when theres a known security issue for a version you currently use.
So long as we insist on everything from a light switch, the vacuum cleaner, security camera, clothes dryer, TV, car, and mobile phone being an always on, always online, Universal Turing Machine we’re not going to find a solution.
In the fictional universe of William Gibson's Sprawl trilogy, it is legal and normal for defenders to go kinetic on cyberattackers. How long until it is simply easier for governments and big business in the countries victimised by these criminal groups, to find the path of least resistance and go after them personally?
We can’t even prevent shop lifting.
Shoplifting isn't a national security matter.
When you have AI models finding vulnerabilities by themselves in a for-loop, it isn't long before there is no human to go kinetic on.
Attackers are just having fun due to abysmal state of npm and some of the insecure design choices by GitHub and GitHub Actions. Every attack gives them credentials which in turn used to stage more attacks.
perfect capitalism writ technology
What they do is already illegal. The problem is finding out who they are and where they live to go and arrest them.
are these fixed removed now?
Seems like it is fixed/removed: https://github.com/antvis/.github/commit/cb641113703e531ee43...
Some are still on npm but marked "deprecated":
https://www.npmjs.com/package/size-sensor/v/1.0.4?activeTab=...
As the article states, you can see in the package.json that the optionalDependencies references "@antv/setup": "github:antvis/G2#7cb42f57561c321ecb09b4552802ae0ac55b3a7a"
I'm pretty sure those commits have been removed from github:
https://github.com/antvis/G2/issues/7401#issuecomment-448480...
another day, another npm hack.