CVE-2024-4317 - PostgreSQL pg_stats_ext Information Disclosure Explained

In April 2024, a new vulnerability was published affecting PostgreSQL, one of the world's most popular open-source databases. This exploit—CVE-2024-4317—impacts how PostgreSQL handles built-in database views used for tracking statistical information. Many users may not realize that someone with minimal database access can spy on valuable data through these statistics, even without being granted appropriate permissions.

Let’s break down the vulnerability, look at example scenarios and code, and discuss practical steps for protection.

pg_stats_ext_exprs

The core of the issue: Unprivileged users (any database user with basic access) are able to read statistical information about data in tables they shouldn't be able to see—including the *most common values* in columns, which can indirectly reveal actual data or computation results.

Why does this matter?

Statistics collected by PostgreSQL’s CREATE STATISTICS command are meant to help the query planner make smarter decisions. But some of this information, like “most common column values,” can leak actual data or outcomes of protected computations.

Example Scenarios

- Sensitive data exposure: If you run a database hosting multiple tenants, one tenant (with no direct access to another’s data) could snoop on the most common email addresses, last names, or other private values held by other tenants.
- Function result leakage: Some statistics reference results of functions that users ordinarily shouldn’t be able to execute or view.

PostgreSQL major versions: 14, 15, 16

- Impacted minor releases: PostgreSQL 16.2 and earlier, 15.6 and earlier, 14.11 and earlier

Unaffected: PostgreSQL 13 and lower

But beware: Merely installing a patched version does NOT secure existing databases, unless you also recreate them or follow release note instructions. The fix is only automatically applied to *new* databases that are initialized with initdb.

How Does It Work? Code Snippet Perspective

Here’s how an attacker with database access could leverage this flaw.

Alice’s actions

-- Alice creates a table and populates it with secret data
CREATE TABLE secret_data (
    id serial PRIMARY KEY,
    valuable_info text
);

INSERT INTO secret_data (valuable_info)
VALUES ('Secret1'), ('Secret2'), ('AnotherSecret');

-- Alice creates statistics
CREATE STATISTICS info_stats (most_common_vals) ON valuable_info FROM secret_data;

Even though Eve has *no privileges* to read from secret_data, she can still do

-- View stats for all databases, including Alice's stats!
SELECT * FROM pg_stats_ext WHERE tablename = 'secret_data';

-- Check out expressions and values
SELECT * FROM pg_stats_ext_exprs WHERE statname = 'info_stats';

Sample Output

| schemaname | tablename | statistics_name | inherited | most_common_vals | ... |
|------------|--------------|-----------------|-----------|---------------------|-----|
| public | secret_data | info_stats | f | {Secret1,Secret2} | ... |

Now, eve sees actual common values stored in the statistics, even if she can’t SELECT from the table itself.

Links: Official References

- PostgreSQL Security Release, April 2024
- CVE Record - CVE-2024-4317
- Release Notes for PostgreSQL 16.3
- Release Notes for PostgreSQL 15.7
- Release Notes for PostgreSQL 14.12

Upgrade PostgreSQL Software to 16.3+, 15.7+, or 14.12+, *even if you think you’re safe*.

2. For existing databases, follow instructions in the release notes (you’ll need to manually execute provided SQL commands to adjust permissions that close the information leak).
3. For new databases only, the issue is automatically fixed when you use initdb (i.e., initializing a new data directory).
4. Review your permissions! Don’t give untrusted users access to databases where others’ sensitive stats might be visible.

Exploit Details: What Makes This Vulnerable?

The built-in statistical views (pg_stats_ext and pg_stats_ext_exprs) did not check whether a querying user actually had SELECT permission on the *underlying table or functions*. As a result, these views returned sensitive data and computation results to *any* logged-in user.

Key Point: This is not a flaw in the table security model itself, but in the views *presented* by PostgreSQL for admin convenience.

Conclusion

CVE-2024-4317 exposes how even indirect data—like statistics—can leak sensitive information when not properly protected. If you manage PostgreSQL 14, 15, or 16 in any shared/multi-tenant environment, fixing this is non-optional. Upgrade and follow up with manual SQL steps as advised in the official release notes!

Want to stay safe?

- Subscribe to PostgreSQL Announce for security updates.

Timeline

Published on: 05/14/2024 15:43:16 UTC
Last modified on: 05/14/2024 16:11:39 UTC