Multiple features escape "security restricted operation" sandbox

An attacker having permission to create non-temporary objects in at least one schema can execute arbitrary SQL functions under the identity of a superuser.

While promptly updating PostgreSQL is the best remediation for most users, a user unable to do that can work around the vulnerability by disabling autovacuum and not manually running ANALYZE, CLUSTER, REINDEX, CREATE INDEX, VACUUM FULL, REFRESH MATERIALIZED VIEW, or a restore from output of the pg_dump command. Performance may degrade quickly under this workaround.

VACUUM without the FULL option is safe, and all commands are fine when a trusted user owns the target object.

The PostgreSQL project thanks Etienne Stalmans for reporting this problem.

Version Information

Affected Version Fixed In Fix Published
13 13.1 2020-11-12
12 12.5 2020-11-12
11 11.10 2020-11-12
10 10.15 2020-11-12
9.6 9.6.20 2020-11-12
9.5 9.5.24 2020-11-12

For more information about PostgreSQL versioning, please visit the versioning page.

CVSS 3.0

Overall Score 8.8
Component core server
Vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Reporting Security Vulnerabilities

If you wish to report a new security vulnerability in PostgreSQL, please send an email to

For reporting non-security bugs, please see the Report a Bug page.