Jump to:
Restore functionality of ALTER {ROLE|DATABASE} SET role (Tom Lane, Noah Misch) §
The fix for CVE-2024-10978 accidentally caused settings for role to not be applied if they come from non-interactive sources, including previous ALTER {ROLE|DATABASE} commands and the PGOPTIONS environment variable.
Harden PQescapeString and allied functions against invalidly-encoded input strings (Andres Freund, Noah Misch) § § § § § §
Data-quoting functions supplied by libpq now fully check the encoding validity of their input. If invalid characters are detected, they report an error if possible. For the ones that lack an error return convention, the output string is adjusted to ensure that the server will report invalid encoding and no intervening processing will be fooled by bytes that might happen to match single quote, backslash, etc.
The purpose of this change is to guard against SQL-injection attacks that are possible if one of these functions is used to quote crafted input. There is no hazard when the resulting string is sent directly to a PostgreSQL server (which would check its encoding anyway), but there is a risk when it is passed through psql or other client-side code. Historically such code has not carefully vetted encoding, and in many cases it's not clear what it should do if it did detect such a problem.
This fix is effective only if the data-quoting function, the server, and any intermediate processing agree on the character encoding that's being used. Applications that insert untrusted input into SQL commands should take special care to ensure that that's true.
Applications and drivers that quote untrusted input without using these libpq functions may be at risk of similar problems. They should first confirm the data is valid in the encoding expected by the server.
The PostgreSQL Project thanks Stephen Fewer for reporting this problem. (CVE-2025-1094)
Improve behavior of libpq's quoting functions (Andres Freund, Tom Lane) § § §
The changes made for CVE-2025-1094 had one serious oversight: PQescapeLiteral() and PQescapeIdentifier() failed to honor their string length parameter, instead always reading to the input string's trailing null. This resulted in including unwanted text in the output, if the caller intended to truncate the string via the length parameter. With very bad luck it could cause a crash due to reading off the end of memory.
In addition, modify all these quoting functions so that when invalid encoding is detected, an invalid sequence is substituted for just the first byte of the presumed character, not all of it. This reduces the risk of problems if a calling application performs additional processing on the quoted string.
Avoid one-byte buffer overread when examining invalidly-encoded strings that are claimed to be in GB18030 encoding (Noah Misch, Andres Freund) § §
While unlikely, a SIGSEGV crash could occur if an incomplete multibyte character appeared at the end of memory. This was possible both in the server and in libpq-using applications. (CVE-2025-4207)
Tighten security checks in planner estimation functions (Dean Rasheed) §
The fix for CVE-2017-7484, plus followup fixes, intended to prevent leaky functions from being applied to statistics data for columns that the calling user does not have permission to read. Two gaps in that protection have been found. One gap applies to partitioning and inheritance hierarchies where RLS policies on the tables should restrict access to statistics data, but did not.
The other gap applies to cases where the query accesses a table via a view, and the view owner has permissions to read the underlying table but the calling user does not have permissions on the view. The view owner's permissions satisfied the security checks, and the leaky function would get applied to the underlying table's statistics before we check the calling user's permissions on the view. This has been fixed by making security checks on views occur at the start of planning. That might cause permissions failures to occur earlier than before.
The PostgreSQL Project thanks Dean Rasheed for reporting this problem. (CVE-2025-8713)
Prevent pg_dump scripts from being used to attack the user running the restore (Nathan Bossart) §
Since dump/restore operations typically involve running SQL commands as superuser, the target database installation must trust the source server. However, it does not follow that the operating system user who executes psql to perform the restore should have to trust the source server. The risk here is that an attacker who has gained superuser-level control over the source server might be able to cause it to emit text that would be interpreted as psql meta-commands. That would provide shell-level access to the restoring user's own account, independently of access to the target database.
To provide a positive guarantee that this can't happen, extend psql with a \restrict command that prevents execution of further meta-commands, and teach pg_dump to issue that before any data coming from the source server.
The PostgreSQL Project thanks Martin Rakhmanov, Matthieu Denais, and RyotaK for reporting this problem. (CVE-2025-8714)
Convert newlines to spaces in names included in comments in pg_dump output (Noah Misch) §
Object names containing newlines offered the ability to inject arbitrary SQL commands into the output script. (Without the preceding fix, injection of psql meta-commands would also be possible this way.) CVE-2012-0868 fixed this class of problem at the time, but later work reintroduced several cases.
The PostgreSQL Project thanks Noah Misch for reporting this problem. (CVE-2025-8715)
⇑ Upgrade to 17.2 released on 2024-11-21 - docs
Restore functionality of ALTER {ROLE|DATABASE} SET role (Tom Lane, Noah Misch) §
The fix for CVE-2024-10978 accidentally caused settings for role to not be applied if they come from non-interactive sources, including previous ALTER {ROLE|DATABASE} commands and the PGOPTIONS environment variable.
⇑ Upgrade to 17.3 released on 2025-02-13 - docs
Harden PQescapeString and allied functions against invalidly-encoded input strings (Andres Freund, Noah Misch) § § § § § §
Data-quoting functions supplied by libpq now fully check the encoding validity of their input. If invalid characters are detected, they report an error if possible. For the ones that lack an error return convention, the output string is adjusted to ensure that the server will report invalid encoding and no intervening processing will be fooled by bytes that might happen to match single quote, backslash, etc.
The purpose of this change is to guard against SQL-injection attacks that are possible if one of these functions is used to quote crafted input. There is no hazard when the resulting string is sent directly to a PostgreSQL server (which would check its encoding anyway), but there is a risk when it is passed through psql or other client-side code. Historically such code has not carefully vetted encoding, and in many cases it's not clear what it should do if it did detect such a problem.
This fix is effective only if the data-quoting function, the server, and any intermediate processing agree on the character encoding that's being used. Applications that insert untrusted input into SQL commands should take special care to ensure that that's true.
Applications and drivers that quote untrusted input without using these libpq functions may be at risk of similar problems. They should first confirm the data is valid in the encoding expected by the server.
The PostgreSQL Project thanks Stephen Fewer for reporting this problem. (CVE-2025-1094)
⇑ Upgrade to 17.4 released on 2025-02-20 - docs
Improve behavior of libpq's quoting functions (Andres Freund, Tom Lane) § § §
The changes made for CVE-2025-1094 had one serious oversight: PQescapeLiteral() and PQescapeIdentifier() failed to honor their string length parameter, instead always reading to the input string's trailing null. This resulted in including unwanted text in the output, if the caller intended to truncate the string via the length parameter. With very bad luck it could cause a crash due to reading off the end of memory.
In addition, modify all these quoting functions so that when invalid encoding is detected, an invalid sequence is substituted for just the first byte of the presumed character, not all of it. This reduces the risk of problems if a calling application performs additional processing on the quoted string.
⇑ Upgrade to 17.5 released on 2025-05-08 - docs
Avoid one-byte buffer overread when examining invalidly-encoded strings that are claimed to be in GB18030 encoding (Noah Misch, Andres Freund) § §
While unlikely, a SIGSEGV crash could occur if an incomplete multibyte character appeared at the end of memory. This was possible both in the server and in libpq-using applications. (CVE-2025-4207)
⇑ Upgrade to 17.6 released on 2025-08-14 - docs
Tighten security checks in planner estimation functions (Dean Rasheed) §
The fix for CVE-2017-7484, plus followup fixes, intended to prevent leaky functions from being applied to statistics data for columns that the calling user does not have permission to read. Two gaps in that protection have been found. One gap applies to partitioning and inheritance hierarchies where RLS policies on the tables should restrict access to statistics data, but did not.
The other gap applies to cases where the query accesses a table via a view, and the view owner has permissions to read the underlying table but the calling user does not have permissions on the view. The view owner's permissions satisfied the security checks, and the leaky function would get applied to the underlying table's statistics before we check the calling user's permissions on the view. This has been fixed by making security checks on views occur at the start of planning. That might cause permissions failures to occur earlier than before.
The PostgreSQL Project thanks Dean Rasheed for reporting this problem. (CVE-2025-8713)
Prevent pg_dump scripts from being used to attack the user running the restore (Nathan Bossart) §
Since dump/restore operations typically involve running SQL commands as superuser, the target database installation must trust the source server. However, it does not follow that the operating system user who executes psql to perform the restore should have to trust the source server. The risk here is that an attacker who has gained superuser-level control over the source server might be able to cause it to emit text that would be interpreted as psql meta-commands. That would provide shell-level access to the restoring user's own account, independently of access to the target database.
To provide a positive guarantee that this can't happen, extend psql with a \restrict command that prevents execution of further meta-commands, and teach pg_dump to issue that before any data coming from the source server.
The PostgreSQL Project thanks Martin Rakhmanov, Matthieu Denais, and RyotaK for reporting this problem. (CVE-2025-8714)
Convert newlines to spaces in names included in comments in pg_dump output (Noah Misch) §
Object names containing newlines offered the ability to inject arbitrary SQL commands into the output script. (Without the preceding fix, injection of psql meta-commands would also be possible this way.) CVE-2012-0868 fixed this class of problem at the time, but later work reintroduced several cases.
The PostgreSQL Project thanks Noah Misch for reporting this problem. (CVE-2025-8715)