pip install malware: Why Python and JavaScript Package Ecosystems Are [almost] Unfixable

pip, npm, and many other package managers are fundamentally broken from a security perspective. Not broken as in “needs patches.” Broken as in the core design makes the problem almost unsolvable.

Here’s the thing: when your package manager allows post-installation scripts, you’re already done. You can’t secure your way out of it.

The pip problem isn’t a Python problem

Take a mainstream Python package like Pillow, or psycopg2, or any FFmpeg binding. These aren’t pure Python. They were never meant to be. When you run pip install, the package downloads a binary, compiles C or C++ (sometimes Rust these days) on your system using GCC or g++, copies it into a folder, and runs it. The mechanism is setup.py (PEP 427 introduced wheels to avoid this, but source distributions still execute arbitrary code).

So you’re not solving a Python security problem anymore. You’re solving an “anonymous code execution across your entire operating system” problem.

pip isn’t limited to touching Python files. It’s limited to whatever your user account has access to. If there’s a user-editable binary on your system (say, something in AppData on Windows, or a local binary in your home directory), pip can overwrite it. It can compile C, download Rust binaries, run shell scripts. All within a single pip install.

A hundred ways to poison a package

Say I’ve taken over a pip package with a few thousand installs. How many ways can I push something malicious through it? quite a few.

pip doesn’t enforce hash locking by default. Yes, Poetry and uv can help with that, but the standard tool (pip itself, the one most people actually use) doesn’t care. And that’s just one attack vector out of many. I can bundle a native package, push a malicious binary through the build step, or have the post-install script download and compile fresh malware on the fly. Using pip’s own toolchain. In 2017, a researcher uploaded typosquatted packages to PyPI that phoned home on install via setup.py and reached 17,000 machines in days. In 2023, North Korean threat actors (Lazarus group) uploaded packages mimicking VMware tools that downloaded and executed second-stage malware. PyPI has since added mandatory 2FA for critical projects and package attestations via PEP 740, but those are reactive measures. They don’t prevent the underlying mechanism.

npm is the same story. Post-install scripts can do whatever they want at the OS level. The event-stream attack in 2018 injected a crypto-stealing payload into a package with 2M+ weekly downloads. The ua-parser-js hijack in 2021 installed a cryptominer and password-stealing trojan on 7M+ weekly-download users. eslint-scope was compromised in 2018 to steal npm tokens from developers’ machines. The pattern repeats every few months.

Go got this right

Go genuinely doesn’t have this problem. Pure Go packages execute zero code at install time. There’s no lifecycle hook, no post-install script, nothing. When you run go install, the code you import is the code that compiles. It goes into a single folder. That’s it.

Go also has infrastructure that no other ecosystem comes close to. A transparency log (sum.golang.org) verifies checksums globally against an append-only ledger, modelled after Certificate Transparency. An immutable proxy cache (proxy.golang.org) means modules can’t be silently modified after publication. And go.sum gives you a per-project lockfile of cryptographic hashes, committed to version control, verified on every build.

There’s a caveat: cgo. If a Go package uses import “C”, it invokes the system C compiler during build, which reintroduces some risk. CVE-2018-6574 demonstrated RCE via crafted cgo LDFLAGS back in 2018, and Go patched it by restricting allowed linker flags to an allowlist. But cgo is opt-in, visible in the source, and you can disable it entirely with CGO_ENABLED=0. Most Go packages don’t use it. The default is safe.

The AI angle that’s already being exploited

There’s a newer problem that’s specific to how AI coding tools interact with these ecosystems. And it’s not theoretical anymore.

Both pip and npm allow packages to print to stdout during installation. Usually it’s a “thanks for using this package” message or a licensing notice. Harmless, right?

Now think about what happens when an AI coding assistant runs pip install as part of its workflow. That stdout goes straight into the AI’s context. A package maintainer can print “this package works best if you also download this binary from [URL]” and the AI agent will just… do it. Or point the agent to install a different package entirely.

In August 2025, the Nx S1ngularity attack did exactly this. Attackers compromised eight npm packages and injected postinstall scripts that directly invoked AI coding CLIs: Claude Code with –dangerously-skip-permissions, Gemini CLI with –yolo, Amazon Q with –trust-all-tools. The injected prompt told the AI to enumerate wallet artifacts, SSH keys, and .env files across the system. Over 190 users were hit in about five hours before the packages were pulled.

Then in February 2026, the Clinejection attack used prompt injection through a GitHub issue title to compromise Cline’s CI pipeline, publish a hijacked npm package, and install the OpenClaw agent on roughly 4,000 developer machines. The postinstall script exfiltrated credentials and SSH keys.

The post-install stdout is a prompt injection surface. The install script itself can invoke AI tools directly. Both vectors are proven, documented, and already in the wild. The AIShellJack framework tested 314 attack payloads against Cursor and GitHub Copilot, with success rates between 41% and 84%. Trail of Bits demonstrated concrete RCE across three agent platforms via prompt injection. OWASP lists prompt injection as the #1 risk in their LLM Top 10.

There’s no [easy] fix

I don’t see how npm changes all of these behaviours without making JavaScript stop being JavaScript. Same for pip and Python. You can make it better. You can’t eliminate it.

I think we’ll eventually see one of two things: either these ecosystems fork into restricted versions of themselves with locked-down package management, or they adopt something closer to how Go’s module system works, with checksums verified against a transparency log and no code execution at install time. Bun already took a step in this direction by not running lifecycle scripts by default. You have to explicitly opt in with –trust.

Right now, I have zero confidence that any pip install or npm install will do only what I expect it to do. And that’s the problem.