GHSA-m5pq-69xg-vcq3 — devpi-server
MEDIUMGHSA-m5pq-69xg-vcq3 is a medium-severity (CVSS 6.5) CWE-304 vulnerability in devpi-server. A fix is available for devpi-server — see the affected versions and patch details below.
devpi-server may leak database contents
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-m5pq-69xg-vcq3.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-m5pq-69xg-vcq3 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 382,574 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
devpi-serverReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Impact
If the replication protocol is enabled by using the primary (or deprecated master) role for a server instance, then the +changelog URL route can be used to read the complete database content including password hashes, and the ids and salts of tokens from devpi-tokens by using a trivially modified GET request.
The leaked hashes use the argon2 algorithm, so they are not immediately at risk by brute-force methods, but dictionary attacks are feasible. If a database leak could have happened, it is advised to change the passwords after a patched version or other mitigation is in place.
When devpi-tokens is in use, the quality of the server secret is important. It might be possible to derive the server secret if actual tokens are public by using similar techniques to finding the password for a hash. If a database leak could have happened and any tokens are public, it is advised to change the server secret.
Besides the information leak this can be used to produce significant CPU, IO and bandwidth usage depending on the database size.
Patches
The logic bug causing this issue is fixed with devpi-server 6.20.2 and devpi-server 7.0.0b3.
Workarounds
When replication isn't used the role can explicitly be set to standalone.
If the server instance is exclusively served through nginx with the devpi-lockdown plugin, the request is redirected to the login form due to missing user information. There is no known exploit in this case.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | devpi-server | all versions | 6.20.2pip install --upgrade 'devpi-server==6.20.2' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for devpi-server, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update devpi-server to 6.20.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m5pq-69xg-vcq3 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-m5pq-69xg-vcq3 in your dependencies?
Find it across PyPI, including transitive dependencies.