Curious about possible Supply Side Security Vulnerability Scenario using Pip


I’m a security developer that has recently started playing around with Python, and for the last few days have been playing around with how Pip is set up. As a relative neophyte to the whole world I’m hoping someone here has an answer to a question I have regarding Supply Side security vulnerabilities with Pip.

Would the following be possible using Pip:

Say a malicious developer would like to add in a security vulnerability into a package that they have ownership of. They add something like a remote code execution vulnerability into their package, and generate a number of wheel files from that vulnerable source. However, before uploading this update to pip, they remove the vulnerability from their source, and the source file they upload to Pip is clean. In other words, a version of a package would actually have a clean source file, but vulnerable wheel files.

Is the above a possible scenario, or am I unaware of/not understanding something about Pip’s package ecosystem? I ask because I’m trying to play around with building a tool that compares the differences between versions of a vulnerability (to scan for possibly insecure code changes), but I’ve found that isn’t always a simple proposition with some packages having 10/20/40+ wheel files for a given version of a package.


Yes, it’s possible. It’s one of the reasons some of us are starting to talk about reproducible builds to allow for 3rd-party validation the uploaded wheel files match the uploaded sdist (and then potentially sdist to git tag).

1 Like