CVE-2026-6478

What it actually does

PostgreSQL instances using legacy MD5 password authentication are vulnerable to a network-exploitable timing side channel during password-hash comparison. An unauthenticated attacker who can repeatedly attempt authentication against an affected PostgreSQL server may measure response-time differences and use them to gradually recover credential material sufficient to authenticate as a database role protected by an MD5-hashed password. SCRAM-SHA-256 password authentication is not affected, and SCRAM is the default in supported PostgreSQL releases; the main exposure is upgraded environments that still retain MD5-hashed role passwords from PostgreSQL 13 or earlier. Affected versions are PostgreSQL before 18.4, 17.10, 16.14, 15.18, and 14.23.

Why it matters to the business

Successful exploitation can allow unauthorized database login, which may lead to data exposure, data tampering, fraudulent transactions, or abuse of database privileges granted to the compromised role. The risk is concentrated in PostgreSQL deployments that still allow MD5 password authentication or contain roles with MD5-stored passwords after upgrades. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but internet-exposed or widely accessible database services should still be prioritized because exploitation requires only network access and repeated authentication attempts.

How an attack unfolds

An attacker first identifies a reachable PostgreSQL service that accepts password authentication. They then determine or guess valid database role names and send many authentication attempts while precisely measuring timing differences in the server responses. If the target role uses a legacy MD5-hashed password, the attacker can exploit the non-constant-time comparison behavior to infer credential material over many attempts. Once enough information is recovered, the attacker authenticates as the affected role and gains whatever database access that role permits, such as reading application data, modifying records, creating objects, or pivoting through database features if additional privileges are available. Exploitation is less practical against noisy or rate-limited networks, and it does not apply to roles using SCRAM-SHA-256 passwords.

How to fix it

Upgrade PostgreSQL to a fixed release: 18.4 or later, 17.10 or later, 16.14 or later, 15.18 or later, or 14.23 or later. In addition to patching, migrate all remaining MD5-hashed role passwords to SCRAM-SHA-256 by setting password_encryption = 'scram-sha-256' and rotating passwords for affected roles so stored password verifiers are regenerated as SCRAM. Review pg_hba.conf and remove or replace md5 authentication methods with scram-sha-256 where client compatibility permits. Restrict PostgreSQL network exposure to trusted application hosts, VPNs, private networks, or bastion paths; do not expose database listeners broadly to the internet. Where immediate upgrade is not possible, reduce risk by disabling MD5 authentication, rotating legacy role passwords to SCRAM, enforcing connection rate limits at network or proxy layers, and monitoring for repeated failed authentication attempts.

How to confirm the fix worked

Confirm the running PostgreSQL version is at or above the fixed release for its major version: 18.4, 17.10, 16.14, 15.18, or 14.23. Verify that no database roles retain MD5 password verifiers by checking for role password values beginning with 'md5' in PostgreSQL system catalogs using an appropriately privileged administrative account. Review pg_hba.conf and confirm authentication methods do not use 'md5' for untrusted or remote connections; prefer 'scram-sha-256'. Validate that password_encryption is set to 'scram-sha-256' for future password changes. Test representative application connections after migration to ensure drivers and clients support SCRAM-SHA-256. Confirm external exposure controls by scanning authorized network ranges for reachable PostgreSQL listeners and validating that only approved sources can connect.

Typical attack path

1. Scan for reachable PostgreSQL services, commonly on TCP port 5432.
2. Identify or guess valid PostgreSQL role names through application knowledge, leaked configuration, error messages, or common naming patterns.
3. Confirm that the service accepts password authentication and is not enforcing SCRAM-SHA-256-only authentication.
4. Send a high volume of carefully timed authentication attempts against a target role.
5. Analyze authentication response timing to recover credential material for a role using an MD5-hashed password.
6. Authenticate successfully using the recovered credential material.
7. Use the compromised database role privileges to read, alter, or exfiltrate data, or to expand access where database permissions allow.

How to detect it

Look for evidence of repeated authentication probing against PostgreSQL, especially many failed password attempts against one or a small number of roles from a consistent source IP or over unusual time windows. Relevant log sources include PostgreSQL server logs, syslog or journald records for the PostgreSQL service, database proxy logs, cloud database audit logs, firewall logs, load balancer logs, VPN logs, and endpoint/network telemetry for connections to PostgreSQL, commonly TCP/5432. In PostgreSQL logs, search for repeated FATAL authentication failures, invalid role attempts, connection storms, or abnormal login timing patterns. Because this is a timing side-channel vulnerability, there may be no distinctive payload or exploit string; detection depends on behavioral patterns such as high-volume failed logins, low-and-slow authentication attempts, attempts distributed across role names, and a later successful login from the same source after many failures. If suspicious activity is found, review successful connections following the failed attempts, database audit trails for queries run by the targeted role, changes to roles or privileges, unusual data exports, COPY usage, large result sets, new functions/extensions, and connections originating from unfamiliar IP addresses. Also inspect whether targeted roles used MD5 password verifiers at the time of activity, because SCRAM-SHA-256 roles are not affected by this flaw.

• FATAL: password authentication failed for user
• password authentication failed for user
• FATAL: role "
• does not exist
• authentication method 5 not supported
• pg_hba.conf
• md5
• scram-sha-256
• port 5432
• TCP/5432

What your security team should do

• Prioritize inventory of PostgreSQL servers that are network-accessible or internet-exposed and determine whether they run affected versions.
• Upgrade affected PostgreSQL deployments to 18.4, 17.10, 16.14, 15.18, or 14.23 or later according to the deployed major version.
• Identify all roles with MD5-stored passwords and rotate those passwords after enabling SCRAM-SHA-256 password encryption.
• Replace 'md5' entries in pg_hba.conf with 'scram-sha-256' wherever client compatibility allows.
• Restrict PostgreSQL access at firewalls, security groups, network ACLs, and service meshes to only approved application and administrative sources.
• Enable and centralize PostgreSQL authentication logging, including failed logins and connection source addresses.
• Investigate unusual bursts of failed password authentication, especially repeated attempts against the same role from the same source or from geographically unusual sources.
• Review database role privileges and reduce high-impact permissions for application roles to limit damage if credentials are compromised.
• Ensure backup, recovery, and audit logging processes are functioning before and after upgrade or authentication migration.