PostgreSQL 16.4 protects pg_dump against relation replacement

A backup process can cross a privilege boundary while reading a database. The August 8 PostgreSQL maintenance release fixes CVE-2024-7348, in which an attacker replaces an object while pg_dump is running. The replacement can cause the dump session to execute attacker-controlled SQL with the privileges of the role performing the backup.

The attack requires the ability to create and drop non-temporary objects. The announcement describes replacing a sequence or similar object with a view or foreign table that executes malicious code. It is therefore a concurrency problem involving object identity and object kind. The dump's earlier understanding of an object cannot safely establish what a later access will execute.

I regard backup behavior as part of PostgreSQL's administration contract. A dump often runs with broader authority than an application role, and reading database objects can involve more than retrieving inert bytes. This fix gives that distinction a concrete implementation in both the server and the client utility.

Object kind can change what reading does

The security notice identifies supported PostgreSQL versions 12 through 16 as affected. An attacker does not need the privileges of the backup role at the start. The problem is that a concurrent privileged dump can access a replacement object whose behavior the attacker controls.

A sequence, a view and a foreign table are different kinds of relation. The announcement's replacement example matters because views can expand into queries and foreign tables can involve foreign access. The intended backup operation can consequently encounter behavior that differs from what its earlier object discovery led it to expect. Permission to manipulate one set of objects becomes a way to influence a more privileged session's execution.

The timing requirement is central. An account of the issue that says only that untrusted views are dangerous would omit the substitution between observations. The dump must remain safe while another session changes the database. The fix addresses which relation kinds that dump session is allowed to access, so it can refuse an unexpected executable interpretation.

This also explains why identifying the backup role is relevant to impact. The announcement says the injected SQL executes as that role, often a superuser. It does not say every backup necessarily uses superuser authority. The authority available to the dump session determines the authority available to the injected code in the described attack.

The server adds a restriction that the client requests

The 16.4 release notes describe the new server parameter restrict_nonsystem_relation_kind. It can disable expansion of non-builtin views and access to foreign tables. The updated pg_dump sets the parameter when it is available. The defense thus requires cooperation between the server that enforces the restriction and the utility that requests it.

Both components must be new enough to contain the fix. Updating the database while leaving an older backup utility in a separate environment does not satisfy the stated requirement. Updating the utility while dumping an older server also leaves out part of the defense. The announcement explicitly qualifies protection in terms of both versions.

That has practical consequences for how an update is recorded. The server binary can belong to one deployment, while a scheduled dump job uses a utility installed elsewhere. A cluster version therefore does not prove the backup process has the repaired client. Conversely, a recently updated backup image does not establish that every source server understands the new restriction.

The implementation is more specific than globally prohibiting views or foreign tables in the database. It adds a session restriction that the dump requests for its work. Ordinary application use of these relation kinds is a separate concern from protecting a privileged backup operation against a concurrent substitution. The release notes describe the parameter in that security context.

I prefer that explicit division of responsibility. The server supplies an enforceable restriction and the utility selects it for the operation that needs it. An operator can then identify two concrete update requirements instead of assuming that installing a patch in either location protects every path through the system.

Maintenance updates still preserve earlier follow-up work

The announcement includes PostgreSQL 16.4, 15.8, 14.13, 13.16 and 12.20, alongside PostgreSQL 17 Beta 3. The maintenance releases are cumulative and do not require dump and restore or pg_upgrade within the corresponding major version. Binary replacement is the normal installation path described in the notice.

It also warns that skipping earlier updates can leave additional post-update steps. The May release announcement is an example. Its correction to extended statistics visibility needs a SQL repair in existing affected databases. Installing August's cumulative binaries does not itself demonstrate that an operator completed a prior catalog-level procedure.

These are separate security mechanisms. May's issue concerns access through statistics views. August's issue concerns attacker-controlled replacement objects during a privileged dump. Their remediation records need different evidence, even when one maintenance window installs the current binaries that contain both sets of code changes.

The distinction is useful without turning an update into a generic checklist. For this vulnerability, the decisive fact is whether the server and the actual dump utility support the new protection. Earlier release-specific database changes remain necessary when the upgrade path crosses them. The project documents both conditions rather than treating a version string as a complete maintenance history.

A related concurrency assumption also changes

The 16.4 notes contain another correction where a database object can change between planning and execution. Partition-pruning setup had assumed that a partition could not be detached during that interval. ALTER TABLE DETACH PARTITION CONCURRENTLY makes that assumption invalid, and the old behavior could produce transient execution failures.

That bug has a different impact from the dump vulnerability, but it illustrates a common requirement in these fixes. A later operation must account for changes allowed while it was preparing its work. In the dump case, the new relation-kind restriction prevents an unexpected replacement from becoming privileged SQL execution. Protection applies when the updated utility asks an updated server to enforce that restriction during the dump session.