CVE-2026-54723: Medium severity pip/devpi-server vulnerability
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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/devpi-serverto a version that resolves this vulnerability.Fixed in 6.20.2 - Upgrade
Upgrade
devpi-serverto a version that resolves this vulnerability.Fixed in 6.20.2 - Upgrade
Upgrade
devpi-serverto a version that resolves this vulnerability.Fixed in 7.0.0b3 - Configuration
If replication is not used, explicitly configure the server instance to use the replication role "standalone" (instead of "primary"/deprecated "master") to prevent the +changelog route from exposing complete database content.
devpi-server replication role role = standalone - Compensating control
If the server instance is exclusively served through nginx with the devpi-lockdown plugin, ensure this configuration is in place so the +changelog route is redirected to the login form due to missing user information.
- Operational
If a database leak could have happened and any tokens are public, change the server secret.
- Operational
If a database leak could have happened, change the passwords after a patched version (or other mitigation) is in place.
Event History
Frequently Asked Questions
Which deployments are affected?
Instances configured with the replication protocol enabled through the primary role or deprecated master role are exposed. The affected +changelog route can disclose the complete database, including password hashes and devpi-tokens token IDs and salts.
What does exploitation require and what is the operational impact?
An attacker can use a trivially modified GET request to the +changelog route; no authentication or user interaction is indicated. Exploitation can also impose significant CPU, I/O, and bandwidth load depending on database size.
What remediation is recommended after possible exposure?
Upgrade to devpi-server 6.20.2 or 7.0.0b3, which fix the logic bug. If a database leak may have occurred, change passwords after patching or applying another mitigation; if devpi-tokens are used and tokens may be public, also change the server secret.
How should leaked credentials and token material be assessed?
Leaked password hashes use Argon2, making immediate brute-force attacks less likely, but dictionary attacks remain feasible. For devpi-tokens, public tokens may potentially help an attacker derive a weak server secret using techniques similar to password-hash cracking.