CVE-2019-10130 in PostgreSQL
Summary
by MITRE
A vulnerability was found in PostgreSQL versions 11.x up to excluding 11.3, 10.x up to excluding 10.8, 9.6.x up to, excluding 9.6.13, 9.5.x up to, excluding 9.5.17. PostgreSQL maintains column statistics for tables. Certain statistics, such as histograms and lists of most common values, contain values taken from the column. PostgreSQL does not evaluate row security policies before consulting those statistics during query planning; an attacker can exploit this to read the most common values of certain columns. Affected columns are those for which the attacker has SELECT privilege and for which, in an ordinary query, row-level security prunes the set of rows visible to the attacker.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/07/2025
This vulnerability in PostgreSQL represents a significant information disclosure flaw that exploits the database's handling of column statistics and row-level security policies. The issue affects multiple major versions of PostgreSQL including 11.x up to 11.2, 10.x up to 10.7, 9.6.x up to 9.6.12, and 9.5.x up to 9.5.16, with the vulnerability stemming from the fundamental design flaw where PostgreSQL does not evaluate row security policies before consulting column statistics during query planning operations. This creates an indirect information leakage channel that bypasses normal access controls through the statistical data collection mechanisms.
The technical flaw manifests when PostgreSQL maintains column statistics for tables, specifically including histograms and lists of most common values that contain actual data values from the columns. During query planning, the database engine accesses these statistical structures without first applying row-level security policies that would normally filter out rows accessible to specific users. This means that an attacker with SELECT privileges on a table can exploit this weakness to extract the most common values from columns that would otherwise be restricted by row-level security policies. The vulnerability is particularly dangerous because it operates at the query planning layer rather than the data access layer, making it harder to detect and prevent through conventional security measures.
The operational impact of this vulnerability extends beyond simple information disclosure to potentially enable more sophisticated attacks. An attacker can use the extracted most common values to reconstruct sensitive data patterns, perform statistical inference attacks, or identify sensitive information that should be protected by row-level security. This weakness is especially concerning in environments where row-level security is used to implement fine-grained access controls, as it allows unauthorized users to gain insights into restricted data that would normally be hidden. The vulnerability essentially creates a side-channel attack vector that can be exploited even when proper access controls are in place, undermining the effectiveness of PostgreSQL's row-level security mechanisms.
Organizations affected by this vulnerability should immediately implement the available patches for their PostgreSQL versions, with the specific versions mentioned in the CVE being addressed through updates to 11.3, 10.8, 9.6.13, and 9.5.17 respectively. The mitigation strategy should include comprehensive testing of the updated systems to ensure that the fix does not introduce performance regressions or compatibility issues. Security teams should also conduct thorough assessments of their PostgreSQL environments to identify any potential exploitation attempts and monitor for unusual query patterns that might indicate attempts to extract statistical information. This vulnerability aligns with CWE-200 (Information Exposure) and represents a specific implementation weakness in the ATT&CK technique T1213.001 (Data from Information Repositories) where adversaries can extract sensitive information through indirect means rather than direct data access. The issue demonstrates the importance of considering all data access paths, including those that occur during query planning and optimization phases, when implementing security controls in database systems.