Description

devpi is a Python package index staging server and packaging, testing, and release tool. Prior to 6.20.2 and 7.0.0b3, a server configured with the primary or deprecated master role allows an unauthenticated, modified GET request to the +changelog route because verify_primary does not reject a missing identity and therefore fails to require ReplicaIdentity. The response can disclose complete database content, including Argon2 password hashes and identifiers and salts for devpi-tokens; exposed hashes may be subject to dictionary attacks, and public tokens may assist attempts to derive the server secret. Large responses can also consume significant CPU, input/output capacity, and bandwidth. Servers using the standalone role are not exposed through replication, and an instance served exclusively through nginx with devpi-lockdown redirects the request to login with no known exploit. This issue is fixed in devpi-server versions 6.20.2 and 7.0.0b3.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-14T18:17:53.703Z",
  "pubdate": "2026-09-14T18:17:53.703Z",
  "executiveSummary": "This vulnerability is an improper access control flaw within the devpi-server package index software, identified as an unauthenticated information disclosure issue.\nThe vulnerability allows remote, unauthenticated attackers to query the +changelog route on servers configured with the primary or master role.\nSuccessful exploitation results in the unauthorized exfiltration of the entire server database, including sensitive Argon2 password hashes, devpi-token identifiers, and associated salts.\nThe exposure of cryptographic material facilitates offline dictionary or brute-force attacks against user credentials and potentially assists in deriving the server secret.\nBeyond data theft, the vulnerability creates a denial-of-service vector, as malicious actors can force the server to process large responses, exhausting CPU, I/O, and network bandwidth.\nThe vulnerability affects devpi-server versions prior to 6.20.2 and 7.0.0b3. Servers utilizing the standalone role or those protected by nginx with devpi-lockdown are currently not considered exploitable.",
  "technicalDetails": "The root cause of this vulnerability lies in the flawed implementation of the 'verify_primary' function within the devpi-server codebase. This function is responsible for ensuring that requests to sensitive routes are performed by authorized entities, specifically requiring a valid 'ReplicaIdentity'.\nIn affected versions, the 'verify_primary' function fails to adequately validate the presence of an identity when processing GET requests directed at the '+changelog' route. Because the validation logic does not explicitly reject requests lacking a proper identity, the server incorrectly treats the request as legitimate, bypassing intended security boundaries.\nThe attack flow proceeds as follows: An unauthenticated remote attacker identifies a devpi-server instance running with the 'primary' or 'master' role. The attacker crafts a specific GET request targeting the '+changelog' path. Due to the failure in 'verify_primary', the application layer processes the request without authentication checks. The backend then retrieves and serializes the complete internal database state and returns it in the HTTP response body.\nThe impact of this disclosure is severe. The database dump includes Argon2-hashed passwords and internal tokens. Argon2, while robust, is susceptible to offline password cracking if the hashes are successfully leaked. Furthermore, the exposure of devpi-token salts and identifiers simplifies the process of intercepting or impersonating authenticated sessions. Attackers may also leverage the structure of the returned data to map the internal server state and identify high-value targets.\nFurthermore, the vulnerability introduces a resource exhaustion risk. By repeatedly requesting the '+changelog' route, an attacker can trigger the generation of massive, unpaginated responses. This forces the server to allocate significant memory for object serialization, consume CPU cycles for hash/data processing, and utilize substantial outbound network bandwidth, effectively creating a sustained denial-of-service condition.\nSystems configured in a 'standalone' role are not exposed as they do not process replication-related identity verification in the same manner. Instances gated by nginx and utilizing the 'devpi-lockdown' plugin are protected, as the reverse proxy intercepts and redirects the traffic to a login flow before the vulnerable application code is ever reached."
}