CVE-2026-6474

What it actually does

This vulnerability is an externally controlled format string flaw in PostgreSQL's timeofday() function. An authenticated attacker who can execute SQL can supply a crafted time zone value and then invoke timeofday(), causing PostgreSQL to treat attacker-controlled time zone content as a format string. The practical impact described is information disclosure: portions of PostgreSQL server process memory may be returned in query results. The CVSS vector indicates network reachability, low attack complexity, required low privileges, no user interaction, and limited confidentiality impact, with no stated integrity or availability impact.

Why it matters to the business

An attacker with database access could potentially read small fragments of PostgreSQL server memory. Depending on what is present in memory at the time, this could expose sensitive operational data such as query contents, application data fragments, credentials, tokens, or connection details. The issue affects PostgreSQL versions before 18.4, 17.10, 16.14, 15.18, and 14.23. Although it is not currently listed in CISA KEV, has low EPSS, and no public exploit maturity is reported, database memory disclosure should still be treated seriously where PostgreSQL is internet-accessible, shared by multiple applications, or used in regulated environments.

How an attack unfolds

An attacker first obtains a PostgreSQL account or reaches an application feature that allows execution of attacker-controlled SQL. The attacker then sets the session time zone to a specially crafted value containing format string tokens. After changing the session time zone, the attacker calls the timeofday() function. Because the vulnerable PostgreSQL versions mishandle externally controlled formatting in this path, the returned value may include unintended bytes from the PostgreSQL server process memory. The attacker can repeat the process with different crafted time zone values to attempt to disclose additional memory fragments. Exploitation does not require operating system access or user interaction, but it does require SQL execution privileges.

How to fix it

Upgrade PostgreSQL to a fixed release for the deployed major version: PostgreSQL 18.4 or later, 17.10 or later, 16.14 or later, 15.18 or later, or 14.23 or later. If immediate upgrade is not possible, reduce exposure by restricting direct database network access, enforcing least-privilege database roles, preventing untrusted users from executing arbitrary SQL, monitoring and limiting use of session-level TimeZone changes by non-administrative roles, and reviewing application features that pass user-controlled SQL or time zone values to PostgreSQL. PostgreSQL 13 and older are outside the fixed-version list and should be migrated to a supported fixed branch if still in use.

How to confirm the fix worked

Confirm the running PostgreSQL version with SELECT version(); or by checking the package manager inventory, container image tag, or vendor build metadata. Verify that every affected major branch has been upgraded to at least 18.4, 17.10, 16.14, 15.18, or 14.23. Validate that replicas, standby nodes, containers, development databases, and managed-service instances are also on fixed builds. Review database access controls to confirm that only trusted roles can execute arbitrary SQL. If statement logging or audit logging is available, test that TimeZone changes and timeofday() calls are captured so future exploitation attempts can be investigated.

Typical attack path

1. Gain valid PostgreSQL credentials, compromise an application account with database access, or find an injection path that permits SQL execution.
2. Connect to a vulnerable PostgreSQL server running a version before 18.4, 17.10, 16.14, 15.18, or 14.23.
3. Set the session TimeZone parameter to a crafted value containing format string sequences.
4. Invoke SELECT timeofday(); or an equivalent SQL path that calls timeofday().
5. Inspect the returned time string for leaked PostgreSQL server memory contents.
6. Repeat with variations of the crafted time zone value to attempt to disclose additional memory fragments.
7. Use any exposed secrets, query data, or operational details to support further compromise.

How to detect it

To determine whether exploitation has already occurred, review PostgreSQL statement logs, pgaudit logs, database proxy logs, application SQL logs, and authentication/session logs. Focus on sessions that set or changed the TimeZone parameter and then called timeofday(), especially from low-privileged application accounts, unfamiliar source IP addresses, unusual client applications, or accounts that do not normally run diagnostic SQL. Look for crafted TimeZone values containing printf-style format tokens such as %p, %x, %s, %n, excessive percent characters, long malformed time zone strings, or repeated invalid TimeZone errors. Also review query results, application error logs, and database client logs for anomalous timeofday() output containing hexadecimal-looking memory values, unexpected strings, or non-time data. Because exploitation may only return data in query results and may not create files or processes on the server, absence of operating system artifacts does not rule out exploitation.

• SELECT timeofday()
• timeofday()
• SET TimeZone
• SET timezone
• SET TIME ZONE
• set_config('TimeZone'
• invalid value for parameter "TimeZone"
• TimeZone=%p
• TimeZone=%x
• TimeZone=%s
• TimeZone=%n
• SET TimeZone TO '%p
• SET TimeZone TO '%x
• SET TimeZone TO '%s
• SET TimeZone TO '%n
• SET TIME ZONE '%p
• SET TIME ZONE '%x
• SET TIME ZONE '%s
• SET TIME ZONE '%n

What your security team should do

• Prioritize patching PostgreSQL instances that are internet-facing, reachable from shared application tiers, or used by multiple tenants or applications.
• Upgrade to PostgreSQL 18.4, 17.10, 16.14, 15.18, or 14.23 or later depending on the deployed major version.
• Inventory all PostgreSQL servers, containers, and managed instances to identify vulnerable versions, including non-production systems that may contain copied production data.
• Hunt historical database logs for suspicious combinations of TimeZone changes and timeofday() calls, especially from application users that do not normally run administrative or diagnostic SQL.
• Enable or tune PostgreSQL statement/audit logging for security-sensitive SQL patterns where operationally feasible, including SET TimeZone and SELECT timeofday().
• Restrict direct database access to trusted application hosts and administrative networks.
• Review application code and database permissions to reduce opportunities for arbitrary SQL execution by low-privileged users.
• Treat any confirmed exploitation as a potential sensitive data exposure event and assess whether credentials, tokens, or regulated data may have been present in database memory.