Jump to:
Remove PUBLIC creation permission on the public schema (Noah Misch)
The new default is one of the secure schema usage patterns that Section 5.9.6 has recommended since the security release for CVE-2018-1058. The change applies to new database clusters and to newly-created databases in existing clusters. Upgrading a cluster or restoring a database dump will preserve public's existing permissions.
For existing databases, especially those having multiple users, consider revoking CREATE permission on the public schema to adopt this new default. For new databases having no need to defend against insider threats, granting CREATE permission will yield the behavior of prior releases.
Fix MERGE to enforce row security policies properly (Dean Rasheed)
When MERGE performs an UPDATE action, it should enforce any UPDATE or SELECT RLS policies defined on the target table, to be consistent with the way that a plain UPDATE with a WHERE clause works. Instead it was enforcing INSERT RLS policies for both INSERT and UPDATE actions.
In addition, when MERGE performs a DO NOTHING action, it applied the target table's DELETE RLS policies to existing rows, even though those rows are not being deleted. While it's not a security problem, this could result in unwanted errors.
The PostgreSQL Project thanks Dean Rasheed for reporting this problem. (CVE-2023-39418)
Restrict visibility of pg_stats_ext and pg_stats_ext_exprs entries to the table owner (Nathan Bossart)
These views failed to hide statistics for expressions that involve columns the accessing user does not have permission to read. View columns such as most_common_vals might expose security-relevant data. The potential interactions here are not fully clear, so in the interest of erring on the side of safety, make rows in these views visible only to the owner of the associated table.
The PostgreSQL Project thanks Lukas Fittl for reporting this problem. (CVE-2024-4317)
By itself, this fix will only fix the behavior in newly initdb'd database clusters. If you wish to apply this change in an existing cluster, you will need to do the following:
Find the SQL script fix-CVE-2024-4317.sql in the share directory of the PostgreSQL installation (typically located someplace like /usr/share/postgresql/). Be sure to use the script appropriate to your PostgreSQL major version. If you do not see this file, either your version is not vulnerable (only v14–v16 are affected) or your minor version is too old to have the fix.
In each database of the cluster, run the fix-CVE-2024-4317.sql script as superuser. In psql this would look like
\i /usr/share/postgresql/fix-CVE-2024-4317.sql
(adjust the file path as appropriate). Any error probably indicates that you've used the wrong script version. It will not hurt to run the script more than once.
Do not forget to include the template0 and template1 databases, or the vulnerability will still exist in databases you create later. To fix template0, you'll need to temporarily make it accept connections. Do that with
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
and then after fixing template0, undo it with
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
Prevent trusted PL/Perl code from changing environment variables (Andrew Dunstan, Noah Misch) § § §
The ability to manipulate process environment variables such as PATH gives an attacker opportunities to execute arbitrary code. Therefore, “trusted” PLs must not offer the ability to do that. To fix plperl, replace %ENV with a tied hash that rejects any modification attempt with a warning. Untrusted plperlu retains the ability to change the environment.
The PostgreSQL Project thanks Coby Abrams for reporting this problem. (CVE-2024-10979)
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)
| Config parameter: | Default value: |
|---|---|
| db_user_namespace | off |
| force_parallel_mode | off |
| old_snapshot_threshold | -1 |
| operator_precedence_warning | off |
| promote_trigger_file | |
| stats_temp_directory | pg_stat_tmp |
| trace_recovery_messages | log |
| vacuum_cleanup_index_scale_factor | 0.1 |
| vacuum_defer_cleanup_age | 0 |
| Config parameter: | Default value in Pg 13.21: | Default value in Pg 17.5: |
|---|---|---|
| checkpoint_completion_target | 0.5 | 0.9 |
| hash_mem_multiplier | 1 | 2 |
| log_autovacuum_min_duration | -1 | 600000 |
| log_checkpoints | off | on |
| password_encryption | md5 | scram-sha-256 |
| vacuum_cost_page_miss | 10 | 2 |
⇑ Upgrade to 14.1 released on 2021-11-11 - docs
⇑ Upgrade to 14.3 released on 2022-05-12 - docs
⇑ Upgrade to 14.5 released on 2022-08-11 - docs
⇑ Upgrade to 15 released on 2022-10-13 - docs
Remove PUBLIC creation permission on the public schema (Noah Misch)
The new default is one of the secure schema usage patterns that Section 5.9.6 has recommended since the security release for CVE-2018-1058. The change applies to new database clusters and to newly-created databases in existing clusters. Upgrading a cluster or restoring a database dump will preserve public's existing permissions.
For existing databases, especially those having multiple users, consider revoking CREATE permission on the public schema to adopt this new default. For new databases having no need to defend against insider threats, granting CREATE permission will yield the behavior of prior releases.
⇑ Upgrade to 15.2 released on 2023-02-09 - docs
⇑ Upgrade to 15.3 released on 2023-05-11 - docs
⇑ Upgrade to 15.4 released on 2023-08-10 - docs
Fix MERGE to enforce row security policies properly (Dean Rasheed)
When MERGE performs an UPDATE action, it should enforce any UPDATE or SELECT RLS policies defined on the target table, to be consistent with the way that a plain UPDATE with a WHERE clause works. Instead it was enforcing INSERT RLS policies for both INSERT and UPDATE actions.
In addition, when MERGE performs a DO NOTHING action, it applied the target table's DELETE RLS policies to existing rows, even though those rows are not being deleted. While it's not a security problem, this could result in unwanted errors.
The PostgreSQL Project thanks Dean Rasheed for reporting this problem. (CVE-2023-39418)
⇑ Upgrade to 16.1 released on 2023-11-09 - docs
⇑ Upgrade to 16.2 released on 2024-02-08 - docs
⇑ Upgrade to 16.3 released on 2024-05-09 - docs
Restrict visibility of pg_stats_ext and pg_stats_ext_exprs entries to the table owner (Nathan Bossart)
These views failed to hide statistics for expressions that involve columns the accessing user does not have permission to read. View columns such as most_common_vals might expose security-relevant data. The potential interactions here are not fully clear, so in the interest of erring on the side of safety, make rows in these views visible only to the owner of the associated table.
The PostgreSQL Project thanks Lukas Fittl for reporting this problem. (CVE-2024-4317)
By itself, this fix will only fix the behavior in newly initdb'd database clusters. If you wish to apply this change in an existing cluster, you will need to do the following:
Find the SQL script fix-CVE-2024-4317.sql in the share directory of the PostgreSQL installation (typically located someplace like /usr/share/postgresql/). Be sure to use the script appropriate to your PostgreSQL major version. If you do not see this file, either your version is not vulnerable (only v14–v16 are affected) or your minor version is too old to have the fix.
In each database of the cluster, run the fix-CVE-2024-4317.sql script as superuser. In psql this would look like
\i /usr/share/postgresql/fix-CVE-2024-4317.sql
(adjust the file path as appropriate). Any error probably indicates that you've used the wrong script version. It will not hurt to run the script more than once.
Do not forget to include the template0 and template1 databases, or the vulnerability will still exist in databases you create later. To fix template0, you'll need to temporarily make it accept connections. Do that with
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
and then after fixing template0, undo it with
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
⇑ Upgrade to 16.4 released on 2024-08-08 - docs
⇑ Upgrade to 17.1 released on 2024-11-14 - docs
Prevent trusted PL/Perl code from changing environment variables (Andrew Dunstan, Noah Misch) § § §
The ability to manipulate process environment variables such as PATH gives an attacker opportunities to execute arbitrary code. Therefore, “trusted” PLs must not offer the ability to do that. To fix plperl, replace %ENV with a tied hash that rejects any modification attempt with a warning. Untrusted plperlu retains the ability to change the environment.
The PostgreSQL Project thanks Coby Abrams for reporting this problem. (CVE-2024-10979)
⇑ Upgrade to 17.2 released on 2024-11-21 - docs
⇑ 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
⇑ Upgrade to 17.5 released on 2025-05-08 - docs