CVE-2024-10978 is a vulnerability in PostgreSQL stemming from incorrect privilege assignment related to the use of role-switching commands such as SET ROLE and SET SESSION AUTHORIZATION. These commands allow an application session to assume the identity and privileges of another database role temporarily. The issue occurs when an application query uses attacker-controlled parameters or returns query results to an attacker and relies on functions like current_setting('role') or the current user ID to enforce access control or filter data. Due to the flaw, the query may behave as if the role switch did not happen, causing the database to return or modify rows that the less-privileged user should not access. This can lead to unauthorized data disclosure or modification. Exploitation requires the attacker to have the ability to influence query parameters or receive query results and for the application to use role switching in a way that trusts current_setting('role') or user ID for access decisions. The vulnerability affects multiple PostgreSQL versions before the patched releases 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21. The CVSS 3.1 score of 4.2 indicates a medium severity with network attack vector, high attack complexity, low privileges required, no user interaction, and limited confidentiality and integrity impact. No known exploits have been reported, but the vulnerability poses a risk in environments where role switching is used for multi-tenant or delegated access control scenarios. The root cause lies in inconsistent privilege context evaluation during query execution when role switching is active. This can cause queries to bypass intended row-level security or access control logic. The vulnerability highlights the importance of careful application design when using PostgreSQL's role management features and the need to apply vendor patches promptly.

For European organizations, the impact of CVE-2024-10978 depends largely on their use of PostgreSQL in multi-tenant or role-based access control environments where SET ROLE or SET SESSION AUTHORIZATION commands are used. Unauthorized data disclosure or modification could occur if attackers can manipulate query parameters or receive query results, potentially exposing sensitive personal data or business-critical information. This could lead to violations of GDPR and other data protection regulations, resulting in regulatory fines and reputational damage. The vulnerability does not allow privilege escalation beyond the roles assigned but can cause unauthorized access within the scope of the application’s role management. Organizations in sectors such as finance, healthcare, government, and critical infrastructure that rely on PostgreSQL for sensitive data storage are at higher risk. The medium severity rating suggests the impact is moderate but should not be underestimated given the potential for data leakage or integrity compromise. The absence of known exploits reduces immediate risk but does not eliminate the need for prompt remediation. The complexity of exploitation and requirement for specific application behavior limit widespread exploitation but targeted attacks against vulnerable applications remain a concern.

1. Upgrade PostgreSQL to the fixed versions: 17.1, 16.5, 15.9, 14.14, 13.17, or 12.21 or later to ensure the vulnerability is patched. 2. Review and audit application code that uses SET ROLE or SET SESSION AUTHORIZATION to ensure it does not rely on current_setting('role') or current user ID for access control decisions. 3. Implement strict input validation and parameter sanitization to prevent attacker-controlled parameters from influencing queries that use role switching. 4. Avoid returning query results directly to untrusted users when role switching is involved. 5. Employ additional application-level access controls and logging to detect anomalous access patterns related to role switching. 6. Conduct penetration testing focused on role-switching scenarios to identify potential exploitation paths. 7. Monitor PostgreSQL logs for unusual SET ROLE or SET SESSION AUTHORIZATION usage. 8. Educate developers and DBAs about the risks of relying on session role settings for security decisions. 9. Consider using row-level security policies that do not depend on session role settings or current user ID functions. 10. Maintain an incident response plan to quickly address any suspected exploitation.