Description

Observable response discrepancy in PostgreSQL SCRAM authentication allows an unauthenticated user to test the existence of a user via observing the SCRAM iteration count. This requires the probed user to have a non-default scram_iterations count, because the authentication challenge for a nonexistent user reports the default scram_iterations. Within major versions 16-18, minor versions before PostgreSQL 18.5, 17.11, and 16.15 are affected. Versions before PostgreSQL 16 are unaffected.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-13T13:17:44.653Z",
  "pubdate": "2026-08-13T13:17:44.653Z",
  "executiveSummary": "An observable response discrepancy vulnerability exists within PostgreSQL SCRAM authentication, allowing an unauthenticated remote attacker to verify the existence of specific database user accounts.\nThe flaw impacts PostgreSQL major versions 16 through 18, specifically affecting minor versions prior to PostgreSQL 18.5, 17.11, and 16.15, while versions prior to PostgreSQL 16 remain unaffected.\nThe root cause stems from differing behavior in the authentication challenge mechanism when handling requests for valid versus invalid users, specifically through the exposure of the configured SCRAM iteration count.\nSuccessful exploitation requires the targeted user account to be configured with a non-default scram_iterations count, as nonexistent users and default users share a matching default iteration parameter in the challenge response.\nThe risk implication is primarily informational leakage, enabling reconnaissance phases of an attack by allowing unauthorized entities to harvest valid usernames from the database system.\nNo special privileges or prior authentication are required to initiate the attack, making it accessible to any unauthenticated network entity capable of establishing a connection to the PostgreSQL server.",
  "technicalDetails": "The vulnerability resides in the PostgreSQL SCRAM authentication component, specifically within the protocol handshake where the server issues an authentication challenge to the client connecting via the SCRAM protocol.\nDuring the initial phase of the SCRAM authentication sequence, the PostgreSQL server transmits parameters including the cryptographic salt and the iteration count to the connecting client.\nIf a client initiates authentication against a nonexistent username, the server generates a challenge response utilizing the globally configured default scram_iterations count to prevent direct enumeration.\nHowever, if the targeted user account has been explicitly provisioned with a custom, non-default scram_iterations parameter, the server includes this unique iteration count within the authentication challenge sent to the unauthenticated client.\nAn unauthenticated attacker can observe this discrepancy in the returned iteration count during the SCRAM-SHA-256 or SCRAM-SHA-256-PLUS challenge phase. By comparing the iteration count returned by the server against the known default configuration, the attacker can definitively infer whether the probed username exists within the PostgreSQL system catalogs.\nThe attack flow proceeds as follows: 1) The unauthenticated attacker initiates a connection to the PostgreSQL server. 2) The attacker sends a startup message specifying a target username. 3) The server evaluates the username existence and retrieves its associated SCRAM configuration parameters. 4) The server responds with the authentication challenge containing the specific scram_iterations value. 5) The attacker analyzes the challenge payload; if the iteration count differs from the server-wide default, the attacker confirms the existence of the targeted user account.\nThe affected components are restricted to PostgreSQL major versions 16, 17, and 18, specifically prior to minor versions 16.15, 17.11, and 18.5 respectively. Older major versions are not vulnerable to this specific SCRAM observation flaw.\nNetwork exposure is defined by the accessibility of the PostgreSQL port (typically TCP 5432) to the network boundary from which the attacker operates. No authentication or authorization is required to reach the vulnerable code path, as the enumeration vector occurs prior to credential validation."
}