PostgreSQL 14.5 protects extension objects from hostile ownership
CVE-2022-2625 exploits extension scripts that accept an existing object outside the extension. PostgreSQL 14.5 enforces membership checks in the server and repairs a separate permission regression.
An extension installation script can encounter a database object with the name it intends to create. Accepting that object is unsafe if its owner remains someone the extension installer does not trust. The familiar SQL forms CREATE OR REPLACE and CREATE IF NOT EXISTS can hide that distinction by making an installation continue successfully.
The August 11 PostgreSQL update closes CVE-2022-2625. PostgreSQL 14.5 and the corresponding supported branch updates prevent extension scripts from replacing or accepting existing objects that do not already belong to the extension. The repair lives in the core server, so affected extensions do not each need their own rewritten script to block this attack.
I consider the extension system one of PostgreSQL's strongest capabilities. That makes the ownership rules around installation especially important. Running an extension script with administrative authority needs to preserve the distinction between objects the extension controls and objects another user has placed in the same schema.
A matching name does not establish membership
The 14.5 release notes describe an attacker becoming the owner of an extension object and modifying it to compromise later uses. The faulty scripts used creation forms intended to tolerate an existing object without restricting that behavior to known extension members. A name collision therefore became a way to influence the extension's installed state.
The two SQL forms express different immediate intentions. CREATE OR REPLACE can replace an existing definition, while CREATE IF NOT EXISTS can accept an object already present. In the extension context described by the advisory, both need to establish that the existing object belongs to the extension. Otherwise the script can act on a definition whose ownership and history do not match its assumptions.
This is a trust problem in an existing database namespace. Permission to create an ordinary object should not let its creator arrange for that object to gain a trusted role in a later administrative installation. Checking only whether the desired name exists leaves out the relationship between that object and the extension being installed or updated.
The change also reduces accidental replacement. An unrelated object can collide with an extension script without anyone attempting an attack. Rejecting that collision makes the installation failure visible instead of allowing an administrative operation to overwrite or accept something outside its intended membership.
The attack needs more than object creation
The CVE advisory gives a specific sequence of prerequisites. The attacker needs permission to create non-temporary objects in at least one schema. An administrator must then create or update an affected extension in that schema. Finally, a victim must use the targeted object. The attacker can wait for those actions or try to induce them.
The eventual SQL runs with the victim role's authority, which can be superuser authority. This is not a claim that merely connecting to PostgreSQL grants administrative execution. It is an escalation path through object placement, privileged extension work, and later use of the resulting object.
That sequence explains why installation and use belong in the same security analysis. The unsafe installation prepares a condition that becomes consequential when another user invokes the object. Examining only the immediate result of the installation command can miss the ownership relationship that determines who can change the definition afterward.
Known affected extensions include both bundled and external extensions. The advisory therefore describes a server-level response to a pattern shared across scripts. It also credits Sven Klemm with reporting the issue. The fixed branches listed are 14.5, 13.8, 12.12, 11.17, and 10.22, covering the supported production releases named in the announcement.
I prefer this response to a collection of package-specific instructions. The server can enforce the extension-membership rule at the operation where it matters. An installation then gets the same protection against this pattern regardless of which affected script reaches that operation.
A previous security repair also needed a permission correction
The release has a separate connection to CVE-2022-1552, the maintenance privilege issue repaired earlier this year. The earlier fix made CREATE INDEX use the table owner's permissions during lookups of operator classes and other objects. Previously those lookups used the calling user's permissions.
The release notes say the changed lookup permissions broke dump-and-restore cases. pg_dump emits index creation before it restores grants. A caller who could perform the operation under the previous rules could therefore encounter a permission failure in the intermediate state of a restore. Version 14.5 corrects those checks.
The distinction between the two entries matters. CVE-2022-2625 is the security vulnerability closed by this release. The CREATE INDEX change repairs a compatibility problem caused by an earlier security fix. Describing both identifiers as newly closed vulnerabilities in 14.5 would misstate the announcement and obscure why the second change exists.
This is also a concrete example of permission timing during restoration. The final database may have the intended grants, but the restoration procedure constructs that state in an order. A permission check performed before grants have returned can fail even when the finished schema would allow the same operation. Restoring the intended caller context addresses that specific mismatch.
The production update and beta have different purposes
The announcement includes PostgreSQL 15 Beta 3 alongside the maintenance releases. It explicitly discourages production use of that beta and invites representative application workloads for testing. That makes the beta a separate activity from applying the production security update. A supported PostgreSQL 14 installation can receive the security repair through 14.5 without adopting a prerelease major version.
Within the 14 series, no dump and restore is required for this update. The announcement describes stopping PostgreSQL and updating the binaries, while retaining the usual instruction to inspect earlier release notes when skipping maintenance releases. Existing instructions from those releases can still require additional work.
For the extension issue, the changed behavior is a membership check during installation and update. A script that previously accepted an unrelated existing object can now fail at that point. That failure identifies a real mismatch between the object present in the schema and the extension's expected ownership context. The rejection makes that mismatch explicit before the script can establish the unsafe state described in the advisory.