PostgreSQL 14.3 closes a privilege gap in object maintenance
CVE-2022-1552 lets an object creator exploit privileged maintenance. PostgreSQL 14.3 repairs when security restrictions apply and separately requires rebuilding affected ltree indexes.
Maintaining another user's database object can require executing behavior associated with that object. That creates a privilege problem when the maintenance process has more authority than the object's creator. The maintenance command must preserve the distinction between the authority needed to perform its work and the authority available to behavior the object introduces.
The May 12 PostgreSQL update closes CVE-2022-1552 in PostgreSQL 14.3 and the corresponding supported maintenance branches. Several commands activated the security-restricted-operation protections too late or omitted them in some paths. A user allowed to create non-temporary objects could construct an object that executed SQL under a superuser identity when privileged maintenance reached it.
I default to PostgreSQL for relational work, and that confidence includes taking its privilege boundaries seriously. This advisory concerns normal administration of objects owned by someone else. It makes the trust placed in object creation permissions relevant to operations that can otherwise look like routine background work.
Object ownership matters to maintenance
The security advisory names autovacuum, REINDEX, CREATE INDEX, REFRESH MATERIALIZED VIEW, CLUSTER, and pg_amcheck. Those operations made incomplete efforts to handle another user's objects safely. The attack requires permission to create non-temporary objects in at least one schema. It is not described as an attack available to any unauthenticated network client.
That requirement gives the advisory an administrative context. Permission to define an object is a meaningful capability, but it should not grant the creator control over a superuser's later work. A database that allows object creation by less-trusted users therefore needs maintenance to treat those objects as potentially hostile inputs.
The affected operation can be automatic. The release notes identify autovacuum processing the object as one trigger, alongside a superuser explicitly running an affected command. Avoiding an obvious manual action is insufficient when a background process can reach the same object. This is why the published workaround includes autovacuum, even though disabling it carries an operational cost.
The advisory also distinguishes trusted ownership. It says the commands are fine when a trusted user owns the target object. That limits the issue to a trust relationship between an object and the authority maintaining it. It does not support the broader claim that every invocation of these commands is an exploit.
Protection has to cover the whole operation
The 14.3 release notes describe the repair as confining additional operations within security-restricted-operation protections. The error was partly one of timing. Installing restrictions after an operation has already reached behavior controlled by an object creator leaves an earlier stage outside the intended boundary.
This distinction matters when interpreting a security fix. The presence of protection code somewhere in a command does not establish that all relevant execution occurs under it. A command can have several paths, and setup work can be security relevant before its main processing loop begins. The advisory expressly includes paths where protection was late and paths where it was absent.
The available sources do not provide a reason to publish an invented exploit script. They establish the required permission, the affected commands, and the resulting authority. Those details are enough to understand why an object definition supplied by one user must remain constrained during another user's maintenance operation.
I find the timing explanation especially useful. A security review that asks only whether a command activates a protection mechanism misses whether it activates that mechanism before all object-controlled behavior. The repaired behavior needs that earlier boundary to hold throughout the operation.
The workaround removes substantial functionality
The advisory recommends updating promptly. For users unable to update, it describes disabling autovacuum, avoiding the affected manual commands, and avoiding restoration from pg_dump output. It warns that performance can deteriorate quickly under this workaround. These restrictions make the workaround a significant operational change, not a small configuration adjustment.
The same text explicitly says VACUUM is safe. That is a useful distinction because the list includes autovacuum. The command names alone do not establish identical exposure, and an explanation should preserve the project's stated scope instead of merging them into a general warning about all cleanup.
A workaround that removes automatic maintenance also creates work for an operator. Its cost follows from the breadth of the excluded operations described by the advisory. Updating repairs the implementation so that those operations can run with the intended restrictions. The published guidance therefore gives a concrete reason to prefer the maintenance release over relying on the workaround indefinitely.
The fixed versions are 14.3, 13.7, 12.11, 11.16, and 10.21. The advisory credits Alexander Lakhin with reporting the vulnerability. Keeping the branch-specific versions explicit matters for installations that are supported but do not run the newest major release. The security repair is available without making a major-version migration part of the response.
An unrelated index repair remains necessary
The same release contains a separate correctness issue in GiST indexes over ltree columns. The default signature length changed accidentally while the operator class gained parameter support. Operations performed without first updating the extension to version 1.2 could assume a signature length of 28 bytes where the intended default was 8. The notes say such indexes are very likely corrupt.
That defect has a different remedy from the privilege issue. Installing fixed binaries changes the code that future operations use. It does not reconstruct an existing index that already contains an inconsistent representation. The project recommends reindexing all GiST indexes over ltree columns after installing the update, while distinguishing GiST indexes over ltree[], which are unaffected.
This is not a reason to rebuild every index in a database. The recommendation identifies an access method and a column type. Preserving that specificity makes the required post-update work assessable and keeps it separate from the security repair affecting maintenance commands.
Within the 14 series, the release does not require a dump and restore. The announcement describes stopping the server and updating the binaries, with additional guidance for skipped earlier maintenance releases. For an installation using the affected ltree indexes, completion also includes their rebuild. The two issues share a release, but they change different things about what an administrator must do after installing it.