How I Built PipCanary: A Scanner for Malicious PyPI Packages

sebastian-kuebeck — Thu, 07 May 2026 14:27:43 +0000

When the LiteLLM incident hit the news in March 2026, the vulnerability of the Python ecosystem became personal. A threat actor had hijacked a popular project to exfiltrate SSH keys and AWS credentials. While the official advice was to "delay updates," I knew that wasn't enough.

We needed a way to catch a package with its hand in the cookie jar before it reached production.

The Problem with "Cool-down" Phases

PyPI suggested delaying updates to let the community find malware first. But this has two fatal flaws:

The Vulnerability Gap: You can't patch known security holes if you're stuck in a mandatory cool-down.
Human Error: If you forget the safeguard just once in a single environment, it’s game over.

The Strategy: A Virtual Blast Chamber

I decided to build PipCanary. The goal was simple: install the package in a sandbox, monitor its behavior, and scream if it tries to touch something it shouldn't.

1. The Sandbox (bubblewrap)

I needed a lightweight container that could run inside an existing Docker CI/CD pipeline. I chose bubblewrap. It allows me to create a temporary environment with zero access to sensitive files or network protocols unless explicitly permitted.

2. The Monitor (strace)

To see what the package was doing during pip install, I used strace. It tracks every system call made by the process and its subprocesses. If a package tries to open() your ~/.ssh/id_rsa, PipCanary sees it instantly.

3. The "Lazy" Malware Test

I struggled to write a PoC that executed during installation until I realized I could just script a "load and initialize" step inside the sandbox. This mimics how modern malware (like the PyTorch Lightning incident) operates by triggering the payload as soon as the module is imported.

Real-World Validation: The PyTorch Lightning Attack

Shortly after I finished the PoC, the PyTorch Lightning incident broke. This was a sophisticated attack:

Malware hidden in a directory within the .whl file.
Obfuscated JavaScript payload.
The Python code would download the bun runtime to execute the JS secretly.

Static scanners probably missed it. PipCanary on the other hand monitors system calls, it didn't matter how obfuscated the JS was. The moment the bun runtime tried to reach for credentials, the "Canary" would die, and the CI/CD pipeline would halt.

Conclusion

PipCanary proves that you don't need a massive security suite to protect your supply chain. By combining a sandbox with behavioral monitoring, we can catch even the most sophisticated, obfuscated attacks.

It’s still in its infancy, but seeing it protect my clients' infrastructure against real-world hits has been incredibly rewarding.

Check out the project here: PipCanary on PyPi and GitHub (https://github.com/sebastian-kuebeck/pipcanary)

LiteLLM Incident: https://snyk.io/de/blog/poisoned-security-scanner-backdooring-litellm/
LiteLLM supply-chain attacks guidance: https://blog.pypi.org/posts/2026-04-02-incident-report-litellm-telnyx-supply-chain-attack/
PyTorch Lightning Incident: https://thehackernews.com/2026/04/pytorch-lightning-compromised-in-pypi.html

DEV Community: sebastian-kuebeck