CVE-2024-10978: PostgreSQL Privilege Escalation Flaw

CVE-2024-10978 Overview

CVE-2024-10978 is an Incorrect Privilege Assignment vulnerability affecting PostgreSQL database systems. This flaw allows a less-privileged application user to view or modify data rows different from those intended when the application utilizes SET ROLE, SET SESSION AUTHORIZATION, or equivalent features.

The vulnerability arises when an application query uses attacker-controlled parameters or conveys query results to the attacker, and that query reacts to current_setting('role') or the current user ID. Under these conditions, the query may modify or return data as though the session had not used SET ROLE or SET SESSION AUTHORIZATION. While the attacker does not control which incorrect user ID applies, this still represents a significant authorization bypass that can lead to unauthorized data access or modification.

Critical Impact

Authenticated attackers can potentially view or modify database rows belonging to other users through privilege confusion when applications use session authorization switching features.

Affected Products

• PostgreSQL versions before 17.1
• PostgreSQL versions before 16.5, 15.9, 14.14, 13.17, and 12.21
• Debian Linux 11.0

Discovery Timeline

• November 14, 2024 - CVE-2024-10978 published to NVD
• November 3, 2025 - Last updated in NVD database

Technical Details for CVE-2024-10978

Vulnerability Analysis

This vulnerability is classified under CWE-266 (Incorrect Privilege Assignment). The flaw exists in how PostgreSQL handles privilege context during role switching operations. When an application uses SET ROLE or SET SESSION AUTHORIZATION to temporarily assume a different user context, queries that reference the current role or user ID may not correctly reflect the switched context.

The attack requires specific conditions to be exploitable: the target application must utilize role switching functionality, and the application must either accept query parameters from the attacker or return query results to them. If a query checks current_setting('role') or evaluates the current user ID as part of its authorization logic, it may incorrectly process requests using the original session's privilege context rather than the switched role.

This creates a window where authorization decisions based on the current role may be inconsistent with the actual effective privileges, potentially allowing access to rows or data that should be restricted.

Root Cause

The root cause is improper handling of privilege context state within PostgreSQL when role switching operations are performed. The internal representation of the current role or user ID can become inconsistent with the effective authorization context established by SET ROLE or SET SESSION AUTHORIZATION. This inconsistency causes queries that rely on these internal values for row-level security or similar authorization checks to make incorrect access decisions.

Attack Vector

The attack is network-based but requires low-level authentication to the database. The attack complexity is high because it requires a specific application architecture that:

1. Uses SET ROLE or SET SESSION AUTHORIZATION for privilege switching
2. Accepts user-controlled parameters in queries OR returns query results to the attacker
3. Contains queries that reference current_setting('role') or current user ID for authorization decisions

The vulnerability manifests when these conditions align, causing the privilege checking mechanism to evaluate against the wrong user context. The attacker cannot directly control which incorrect user ID is applied, limiting the precision of exploitation but still enabling unauthorized data access or modification.

For detailed technical information, refer to the PostgreSQL Security Advisory and related PostgreSQL mailing list discussion.

Detection Methods for CVE-2024-10978

Indicators of Compromise

• Unexpected query results returning data from other users or roles
• Audit log entries showing data access patterns inconsistent with user privileges
• Database modifications to rows that the authenticated user should not have access to
• Anomalous patterns in applications using SET ROLE or SET SESSION AUTHORIZATION

Detection Strategies

• Review application code for usage of SET ROLE, SET SESSION AUTHORIZATION, or similar privilege-switching functions
• Audit database queries that reference current_setting('role') or current_user for authorization logic
• Enable PostgreSQL logging to capture role switching operations and subsequent query activity
• Implement query result validation to detect unexpected data access patterns

Monitoring Recommendations

• Monitor PostgreSQL logs for SET ROLE and SET SESSION AUTHORIZATION statements followed by suspicious query patterns
• Configure database activity monitoring to alert on cross-user data access anomalies
• Implement row-level access auditing for sensitive tables
• Deploy SentinelOne Singularity to detect exploitation attempts and anomalous database access patterns

How to Mitigate CVE-2024-10978

Immediate Actions Required

• Upgrade PostgreSQL to patched versions: 17.1, 16.5, 15.9, 14.14, 13.17, or 12.21
• Review applications using SET ROLE or SET SESSION AUTHORIZATION for vulnerable query patterns
• Audit queries that use current_setting('role') or user ID checks for authorization decisions
• Consider implementing application-level authorization checks independent of session role context

Patch Information

PostgreSQL has released security updates addressing this vulnerability. Upgrade to the following minimum versions based on your current major version:

Debian Linux users should apply updates per the Debian LTS security announcements.

Workarounds

• Avoid using SET ROLE or SET SESSION AUTHORIZATION in applications until patches are applied
• Implement application-layer authorization checks that do not rely on PostgreSQL session context
• Use separate database connections with appropriate credentials instead of role switching
• Restrict database user privileges to minimize impact of potential exploitation

# Verify PostgreSQL version and check for vulnerable configurations
psql -c "SELECT version();"

# Check for applications using SET ROLE or SET SESSION AUTHORIZATION
grep -r "SET ROLE\|SET SESSION AUTHORIZATION" /path/to/application/