pip

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $15,000 Google Patch Rewards pays on the Tier 1 named-project row, listed under "Security-relevant bits of common package managers", for a patch you get accepted upstream and that stays merged, without reverts, for one month. It does not pay for the report. The Tier 1 column runs from $500 for a one-liner to $15,000 for a complicated, high-impact change, and the panel sets the final figure. The patch must be at least one month and under twelve months old, it is rate-limited to three submissions a person a month, and the maintainers decide whether to accept it. CVE history 10 Last 12 months 24 Lifetime Parsing/validation 30 % Code execution 30 % Access control 20 % Info disclosure 15 % Latest advisories Loading the feed Overview pip ships with CPython and is the default install path for the whole Python ecosystem. It is invoked as root inside a very large share of container builds and CI pipelines, and it executes arbitrary build-backend code by design when it installs an sdist, so the distance between a pip defect and code execution on a build machine is short. CVE-2025-8869 is the reference point: a tarball symlink extraction fallback that allowed writes outside the target directory. Its behaviour across multiple indexes is also the mechanism behind an entire class of real corporate compromises. The Python Software Foundation runs no bug bounty, so sorona.xyz pays you directly on a qualified, reproduced finding. In scope Reports go through the PyPA security process described in SECURITY.md and cover pip itself. setuptools, wheel and packaging are separate upstreams with their own processes The whole index and resolver path: how --index-url and --extra-index-url are handled, how candidates are selected, and any dependency confusion between a private and a public index Archive handling in full, covering wheel and sdist extraction, path traversal on unpack, and symlink handling Metadata parsing across every format pip reads, including wheel metadata, requirement specifiers, constraint files and requirements files Build-backend invocation through setup.py and pyproject.toml, which is arbitrary code execution at install time and therefore worth attacking from the metadata side Hash and integrity checking, including any gap that lets --require-hashes or a --hash pin be satisfied by content that does not match The network layer and pip's local HTTP cache, where one install can seed what a later install trusts Credential handling for ~/.netrc, keyring integrations and index URLs that carry secrets, including anything that sends a credential to the wrong host Installation targets and environment handling, covering virtual environments, --target and --prefix, and anything that writes outside where the user asked Out of scope PyPI itself, the Warehouse service, which is a separate codebase with no cash pathway of its own Malicious packages published to PyPI, which are an ecosystem abuse problem rather than a defect in pip Bugs in setuptools, wheel or packaging proper, which are separate upstreams with their own OSS-Fuzz entries Reports without a merged patch, as far as the Google pathway is concerned: on that rail there is no reward for a report alone One-line fixes for non-exploitable crashes, which the Patch Rewards rules will not reward, including crashes that come from resource exhaustion Patches the maintainers decline, patches under one month or over twelve months old, and anything past three submissions a person a month Most-valued findings An extraction flaw that writes outside the target directory, through path traversal or a symlink fallback. That is the CVE-2025-8869 shape and it lands as root in most container builds Index or resolver trust confusion that lets a public index satisfy a requirement the operator intended a private index to serve. That is the dependency-confusion mechanism behind real corporate compromises An integrity-checking gap where --require-hashes or a pinned hash is satisfied by content that does not match, since that is the one control careful users rely on Metadata parsing that reaches build-backend invocation earlier or more broadly than the user asked for, turning a resolution step into code execution Cache poisoning where one install seeds artefacts a later install trusts, which persists across pipeline runs on the same runner Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report privately through the PyPA security process described in SECURITY.md, with a detailed reproduction; an unreproducible report is not eligible Show the bug in pip itself rather than in setuptools, wheel or packaging, each of which is a separate upstream Give the maintainers room to ship a release before any public writeup The Google patch money is the only cash path here, and it is a separate pathway: you land the fix upstream yourself and keep it merged, without reverts, for one month On that pathway a patch must be at least one month and under twelve months old, you may submit at most three a month, and the maintainers decide whether to accept it Google cannot pay anyone on a sanctions list, in a sanctioned territory, or located in Russia or Belarus Disclosure Coordinated with the PyPA maintainers, who fix privately, ship a release and publish an advisory that flows into the Python advisory database with reporter credit. Hold the detail until that release is out, because pip updates itself across CI fleets slowly and the window matters. Nothing in the Patch Rewards rules restricts who may help you prepare or route the report. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability