CVE-2026-6575

What it actually does

CVE-2026-6575 is a low-complexity information disclosure flaw in PostgreSQL 18 prior to 18.4. The vulnerable pg_restore_attribute_stats() function can accept array inputs with mismatched lengths, causing the query planner to read beyond the end of one array. A user with table-maintenance privileges can potentially infer adjacent backend memory contents through planner behavior or resulting statistics handling. The flaw does not directly allow data modification, privilege escalation, or denial of service, and PostgreSQL versions before major version 18 are not affected.

Why it matters to the business

An attacker who already has a low-privileged but table-maintenance-capable database role could use this issue to expose small amounts of process memory from the database server. In practical terms, this may risk leakage of sensitive query fragments, metadata, or other in-memory values, depending on what is adjacent in memory at the time of exploitation. The CVSS score is moderate-low, EPSS is very low, it is not in CISA KEV, and no public exploit maturity is reported, so urgency is lower than for remotely exploitable or unauthenticated flaws; however, PostgreSQL 18 deployments should still be upgraded because database memory exposure can undermine confidentiality assumptions.

How an attack unfolds

An attacker first obtains credentials for, or compromises, a PostgreSQL role that is permitted to maintain table statistics or otherwise invoke the affected pg_restore_attribute_stats() code path. They then craft statistic-restoration input containing array values whose lengths do not match. When PostgreSQL processes those inputs during planning/statistics restoration, the vulnerable code reads beyond the intended array boundary. By repeatedly submitting controlled mismatched inputs and observing returned behavior, errors, query planning effects, or restored statistic outcomes, the attacker may infer bytes or values from adjacent backend memory. The attack is post-authentication and constrained by database privileges; it is primarily a confidentiality issue rather than a full database compromise primitive.

How to fix it

Upgrade affected PostgreSQL 18 deployments to PostgreSQL 18.4 or later. PostgreSQL versions before 18 are not affected by this issue. If an immediate upgrade is not possible, reduce exposure by restricting table-maintenance/statistics-restoration privileges to trusted administrative roles only, reviewing roles that can perform table maintenance operations, limiting interactive SQL access, and monitoring for unusual calls or workflows involving statistics restoration. Treat privilege reduction as a temporary mitigation, not a replacement for patching.

How to confirm the fix worked

Confirm the running server version with SELECT version(); or SHOW server_version;. Systems reporting PostgreSQL 18.0, 18.1, 18.2, or 18.3 should be considered exposed; PostgreSQL 18.4 or later is fixed for this issue, and versions before 18 are unaffected. Validate that package inventories, container images, managed database engine versions, and standby/replica nodes are all updated. Also review database roles to confirm that only trusted administrators retain table-maintenance capabilities that could reach pg_restore_attribute_stats().

Typical attack path

1. Gain authenticated access to a PostgreSQL 18 database role with table-maintenance or statistics-restoration capabilities.
2. Identify that the database server is running PostgreSQL 18.0, 18.1, 18.2, or 18.3.
3. Prepare inputs to pg_restore_attribute_stats() containing arrays with deliberately unmatched lengths.
4. Trigger the affected statistics restoration or planning path.
5. Observe resulting planner behavior, errors, or statistics-related outputs to infer memory values beyond the end of the shorter array.
6. Repeat with varied inputs to attempt to recover additional adjacent memory content.

How to detect it

To assess possible prior exploitation, review PostgreSQL statement logging, audit extension logs such as pgaudit, database activity monitoring records, and application SQL logs for calls to pg_restore_attribute_stats() or workflows restoring crafted statistics. Focus on activity from non-administrative roles, newly created roles, unusual maintenance sessions, or repeated failures around statistics restoration. If log_statement was not enabled and no database audit logging exists, retrospective detection may be limited. Investigate surrounding session context, including source IP address, authenticated database user, application_name, timestamps, errors, and any subsequent access to sensitive tables. PostgreSQL server logs may show function invocation errors or malformed array/statistics input if errors were generated, but successful memory inference may leave little evidence beyond SQL execution traces.

• pg_restore_attribute_stats(
• pg_restore_attribute_stats
• ERROR: array length
• ERROR: malformed array literal
• STATEMENT: SELECT pg_restore_attribute_stats
• STATEMENT: SELECT pg_restore_attribute_stats
• CALL pg_restore_attribute_stats
• SELECT pg_restore_attribute_stats

What your security team should do

• Inventory PostgreSQL instances and identify any running major version 18 before 18.4.
• Prioritize upgrading PostgreSQL 18 deployments to 18.4 or later during the next maintenance window.
• Restrict table-maintenance and statistics-restoration privileges to trusted administrative roles until patching is complete.
• Review database audit logs for unusual or repeated use of pg_restore_attribute_stats() or statistics restoration activity by non-administrative users.
• Ensure replicas, containers, base images, and disaster-recovery systems are updated alongside primary database servers.
• Because EPSS is very low, exploit maturity is reported as none, and the issue is not in CISA KEV, handle as a confidentiality-hardening patch unless local threat modeling indicates untrusted database maintainers.