The vulnerability CVE-2026-6478 in PostgreSQL is a covert timing channel in the comparison of MD5-hashed passwords during authentication. An attacker can exploit this timing side channel to recover user credentials remotely, enabling unauthorized database access. This issue specifically affects PostgreSQL instances that still use MD5-hashed passwords, typically from upgrades originating in PostgreSQL 13 or earlier. The vulnerability does not impact scram-sha-256 hashed passwords, which are the default in all supported PostgreSQL versions. Red Hat has released security updates that fix this issue in PostgreSQL versions 14.23, 15.18, 16.14, 17.10, and 18.4 and later. The recommended mitigation is to migrate all user passwords away from MD5 hashing to stronger algorithms such as scram-sha-256 by altering user passwords, which updates the stored hash and requires re-authentication. The CVSS v3.1 base score is 6.5 (medium severity), reflecting network attack vector, low attack complexity, no privileges required, no user interaction, and impacts confidentiality and integrity.

The vulnerability allows remote attackers to recover user credentials by exploiting a covert timing channel in MD5 password comparison during PostgreSQL authentication. Successful exploitation can lead to unauthorized access to the database with the recovered credentials. There is no impact on availability. The vulnerability does not affect scram-sha-256 hashed passwords, which are the default in supported versions. The impact is limited to environments still using MD5 password hashes, often due to legacy upgrades.

A fix is available and has been released in PostgreSQL versions 14.23, 15.18, 16.14, 17.10, and 18.4 and later, as provided by Red Hat security advisories. Users should upgrade to these fixed versions. Additionally, to mitigate the vulnerability, users must ensure that no PostgreSQL user passwords are hashed using MD5. This can be done by altering user passwords to trigger migration to stronger hashing algorithms such as scram-sha-256. For example, execute: ALTER USER username WITH PASSWORD 'new_password'; This requires users to re-authenticate, and services relying on these credentials may need to be restarted to pick up the changes. No other mitigations are indicated by the vendor advisory.