PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 Released!
The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21. This release fixes 4 security vulnerabilities and over 35 bugs reported over the last several months.
For the full list of changes, please review the release notes.
PostgreSQL 12 EOL Notice
This is the final release of PostgreSQL 12. PostgreSQL 12 is now end-of-life and will no longer receive security and bug fixes. If you are running PostgreSQL 12 in a production environment, we suggest that you make plans to upgrade to a newer, supported version of PostgreSQL. Please see our versioning policy for more information.
Security Issues
CVE-2024-10976: PostgreSQL row security below e.g. subqueries disregards user ID changes
CVSS v3.1 Base Score: 4.2
Supported, Vulnerable Versions: 12 - 17.
Incomplete tracking in PostgreSQL of tables with row security allows a reused query to view or change different rows from those intended. CVE-2023-2455 and CVE-2016-2193 fixed most interaction between row security and user ID changes. They missed cases where a subquery, WITH query, security invoker view, or SQL-language function references a table with a row-level security policy. This has the same consequences as the two earlier CVEs. That is to say, it leads to potentially incorrect policies being applied in cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs.
Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used
CREATE POLICY
to define a row security policy. An attacker must tailor an attack to a particular application's pattern of query plan reuse, user ID changes, and role-specific row security policies. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.The PostgreSQL project thanks Wolfgang Walther for reporting this problem.
CVE-2024-10977: PostgreSQL libpq retains an error message from man-in-the-middle
CVSS v3.1 Base Score: 3.1
Supported, Vulnerable Versions: 12 - 17.
Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application. For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results. This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.
The PostgreSQL project thanks Jacob Champion for reporting this problem.
CVE-2024-10978: PostgreSQL SET ROLE, SET SESSION AUTHORIZATION reset to wrong user ID
CVSS v3.1 Base Score: 4.2
Supported, Vulnerable Versions: 12 - 17.
Incorrect privilege assignment in PostgreSQL allows a less-privileged application user to view or change different rows from those intended. An attack requires the application to use
SET ROLE
,SET SESSION AUTHORIZATION
, or an equivalent feature. The problem arises when an application query uses parameters from the attacker or conveys query results to the attacker. If that query reacts tocurrent_setting('role')
or the current user ID, it may modify or return data as though the session had not usedSET ROLE
orSET SESSION AUTHORIZATION
. The attacker does not control which incorrect user ID applies. Query text from less-privileged sources is not a concern here, becauseSET ROLE
andSET SESSION AUTHORIZATION
are not sandboxes for unvetted queries. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.The PostgreSQL project thanks Tom Lane for reporting this problem.
CVE-2024-10979: PostgreSQL PL/Perl environment variable changes execute arbitrary code
CVSS v3.1 Base Score: 8.8
Supported, Vulnerable Versions: 12 - 17.
Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g.
PATH
). That often suffices to enable arbitrary code execution, even if the attacker lacks a database server operating system user. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.The PostgreSQL project thanks Coby Abrams for reporting this problem.
Bug Fixes and Improvements
This update fixes over 35 bugs that were reported in the last several months. The issues listed below affect PostgreSQL 17. Some of these issues may also affect other supported versions of PostgreSQL.
- Fix when attaching or detaching table partitions with foreign key constraints. After upgrade, users impacted by this issue will need to perform manual steps to finish fixing it. Please see the "Upgrading" section and the release notes for more information.
- Fix when using libc as the default collation provider when
LC_CTYPE
isC
whileLC_COLLATE
is a different locale. This could lead to incorrect query results. If you have these settings in your database, please reindex any affected indexes after updating to this release. This issue impacted 17.0 only.- Several query planner fixes, including disallowing joining partitions ( partitionwise join) if the collations of the partitions don't match.
- Fix possible wrong answers or
wrong varnullingrels
planner errors forMERGE ... WHEN NOT MATCHED BY SOURCE
actions.- Fix validation of the
COPY
FORCE_NOT_NULL
andFORCE_NULL
.- Fix server crash when a
json_objectagg()
call contains a volatile function.- Ensure there's a registered dependency between a partitioned table and a non-built-in access method specified in
CREATE TABLE ... USING
. This fix only prevents problems for partitioned tables created after this update.- Fix race condition in committing a serializable transaction.
- Fix race condition in
COMMIT PREPARED
that could require manual file removal after a crash-and-recovery.- Fix for
pg_cursors
view to prevent errors by excluding cursors that aren't completely set up.- Reduce logical decoding memory consumption.
- Fix to prevent stable functions from receiving stale row values when they're called from a
CALL
statement's argument list and theCALL
is within a PL/pgSQLEXCEPTION
block.- Fix for JIT crashes on ARM (aarch64) systems.
- The
psql
\watch
now treats values that are less than 1ms to be 0 (no wait between executions).- Fix failure to use credentials for a replication user in the password file (
pgpass
)pg_combinebackup
now throws an error if an incremental backup file is present in a directory that should contain a full backup.- Fix to avoid reindexing temporary tables and indexes in
vacuumdb
and parallelreindexdb
.This release also updates time zone data files to tzdata release 2024b. This tzdata release changes the old System-V-compatibility zone names to duplicate the corresponding geographic zones; for example
PST8PDT
is now an alias forAmerica/Los_Angeles
. The main visible consequence is that for timestamps before the introduction of standardized time zones, the zone is considered to represent local mean solar time for the named location. For example, inPST8PDT
, timestamptz input such as 1801-01-01 00:00 would previously have been rendered as1801-01-01 00:00:00-08
, but now it is rendered as1801-01-01 00:00:00-07:52:58
.
Also, historical corrections for Mexico, Mongolia, and Portugal. Notably, Asia/Choibalsan is now an alias for Asia/Ulaanbaatar rather than being a separate zone, mainly because the differences between those zones were found to be based on untrustworthy data.
PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 Released!
PostgreSQL versions 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 have been released, addressing four security vulnerabilities and more than thirty-five bugs.