PostgreSQL CVE-2026-14681

Exploitation requires three concurrent conditions: (1) the target PostgreSQL instance is running version 17.x before 17.11 or 18.x before 18.5 - versions prior to 17 are unaffected; (2) pg_hba.conf is configured to require GSSAPI authentication for the relevant host/database combination; and (3) the server's TLS configuration is more permissive than the GSSAPI configuration, creating the mismatch that permits the downgrade. The attacker must also hold valid PostgreSQL credentials (PR:L), ruling out unauthenticated exploitation. What limits exploitation: the high attack complexity (AC:H) of requiring the specific TLS/GSS configuration mismatch, the need for a pre-existing authenticated database account, and the requirement for a GSSAPI-configured deployment - organisations not using Kerberos/GSSAPI are not exposed regardless of version.

The NVD CVSS 3.1 score of 4.2 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N) accurately characterises this as a moderate-severity authentication downgrade, not a critical breach. The AC:H metric is significant: exploitation requires a specific configuration state where TLS settings are more permissive than GSSAPI settings - a non-default condition that requires both GSSAPI to be mandated in pg_hba.conf and TLS to be independently configured with weaker requirements. PR:L further limits exposure to users who already hold valid database credentials. The confidentiality and integrity impacts are both Low, reflecting that the attacker does not gain elevated access but does circumvent the intended security boundary. No EPSS data was provided in source intelligence, so exploitation probability cannot be quantified. The vulnerability is not listed in CISA KEV and no public proof-of-concept code has been identified. The 'Information Disclosure' tag in source data is consistent with data transiting over TLS without GSSAPI integrity sealing. Real-world risk is meaningful for organisations relying on Kerberos/GSSAPI for compliance or regulatory authentication posture, but this is not a mass-exploitation candidate given the complexity and authentication prerequisites.

An authenticated database user on an enterprise network where pg_hba.conf mandates GSSAPI (Kerberos) authentication connects to the PostgreSQL server using a client that initiates a direct TLS session rather than a GSSAPI handshake. If the server's TLS configuration is more permissive than its GSS policy, the server accepts the connection under TLS-only protection, bypassing the GSSAPI mutual authentication and message integrity guarantees. The user then exchanges data with the server without the Kerberos-level integrity enforcement that the administrator believed was enforced. No public exploit code has been identified at time of analysis.