PostgreSQL 18.4 fixes authorization across database boundaries

PostgreSQL's May 14 maintenance update fixes eleven security vulnerabilities and more than sixty bugs. The announcement names 18.4, 17.10, 16.14, 15.18 and 14.23 as the updated releases. CVE-2026-6472 concerns a missing permission check when creating a multirange type. Several other fixes concern privileges or unsafe input crossing between a server and an administrative client, which makes the update relevant beyond the host running PostgreSQL.

I have run PostgreSQL for decades and remain comfortable choosing it for relational systems. That preference includes taking its maintenance documentation seriously. This release makes me want an inventory of the clients and utilities used to administer a database, as well as the server itself. A patched server does not establish that a separately installed backup or administration client has received its own corrected code.

A multirange type could enter another schema

The 18.4 release notes explain CVE-2026-6472 in terms of a missing CREATE privilege check. A multirange type can occupy a different schema from its parent range type. PostgreSQL neglected to check the creator's permission on the schema selected for the multirange type. The update applies the missing authorization check.

The announcement describes the consequence as query hijacking. An object creator could affect other queries that use search_path to resolve user-defined types, including types supplied by extensions. A victim could then execute arbitrary SQL functions chosen by the attacker. The permission check matters because the attack depends on placing an object where another operation may find it.

I would examine this as an object-resolution problem when assessing a deployment. The relevant questions include who can create objects and which queries resolve names through a search path. Those questions help explain the exposure, but they do not replace the fix. The advisory identifies supported versions 14 through 18 as vulnerable before their corresponding May maintenance releases.

This is also a reason to avoid treating extension-related namespaces as inherently trustworthy. The announcement explicitly includes extension-defined types among the objects whose resolution can be affected. My confidence in PostgreSQL's extension model depends on permission checks applying to the surrounding operations, including creation of associated objects in another schema.

Administrative clients receive server-controlled data

CVE-2026-6477 concerns libpq large-object functions and an unsafe form of PQfn(). For a non-integral result, that API does not receive the size of the destination buffer. It therefore cannot check whether the server's response fits. The release notes say a malicious server can overwrite client memory, and that correcting the public API would require an API change.

The update marks the unsafe function deprecated and uses a checked variant internally within libpq. The announcement identifies lo_export(), lo_read(), lo_lseek64() and lo_tell64() as affected operations. It also explains that pg_dump and the psql large-object export command call lo_read(). The consequence reaches familiar administrative programs through their use of the client library.

I would include the machines that run these programs in the maintenance scope. That could mean a separate administration environment or a backup image, depending on the installation. This is a recommendation about inventory, not an assertion about a particular deployment. The advisory's mechanism establishes why the client library's version is relevant even when the person performing the work thinks of it as a server maintenance task.

CVE-2026-6475 raises a related issue for pg_basebackup and pg_rewind. The release notes describe insufficient validation of output paths supplied by their input. A malicious source could cause writes to files accessible to the local process. The correction rejects absolute paths and parent-directory references to constrain where the utilities write data.

The announcement gives an important qualification. Starting a server from the resulting data already implicitly trusts the source superuser, including through capabilities such as shared_preload_libraries. The practical security difference concerns actions between the copy operation and server startup, such as moving files to another virtual machine or taking a snapshot. I would retain that qualification when explaining the vulnerability to someone responsible for a backup workflow.

Authentication history affects exposure

CVE-2026-6478 concerns timing behavior when comparing MD5-hashed passwords. The announcement says the issue does not affect SCRAM-SHA-256 passwords, which are the default in all supported releases. It also warns that an upgraded database may retain MD5-hashed passwords originating in PostgreSQL 13 or earlier. Current software defaults therefore do not establish the format of every existing credential.

The release notes describe replacing ordinary comparisons with timing-safe comparisons. They also say the project does not know whether the data dependencies are usefully exploitable in every corrected location. I would keep the assessment tied to the published scope instead of claiming a demonstrated attack against every authentication path. The actionable distinction is between the password formats present in the installation.

Two logical-replication fixes also depend on who controls names and who later executes an administrative operation. CVE-2026-6476 fixes unquoted subscription names in pg_createsubscriber. CVE-2026-6638 fixes unquoted schema and relation names during ALTER SUBSCRIPTION ... REFRESH PUBLICATION. The announcement identifies the former as affecting supported branches 17 and 18, and the latter as affecting 16 through 18.

For the refresh-publication issue, an attacker who can create a subscriber table can cause SQL execution with publication-side credentials at the next refresh. I would examine both sides of that relationship when assessing permissions. A local object name can affect an operation that uses credentials on another server, which is why the quoting fix has a security consequence beyond unusual identifier handling.

Keep the upgrade scope explicit

The announcement says the maintenance releases are cumulative and do not require a dump and reload or pg_upgrade. Operators can stop PostgreSQL and update the binaries, while checking earlier release notes for any skipped post-update work. That describes the server upgrade procedure, but the client vulnerabilities make a wider inventory useful for this particular release.

I would record which server packages, client libraries and administrative utilities have received the update. Then I would review the operations relevant to the installation, including source-server trust during backup and the credentials used for logical replication. This gives the maintenance record enough detail to distinguish an updated database service from an environment where the affected administration tools have also been replaced.