Description

Missing authorization in PostgreSQL logical decoding allows a non-superuser holding REPLICATION privilege to dlopen any file visible to the operating system account running the server, via the choice of logical decoding plugin. This in turn runs arbitrary code as that account. Versions before PostgreSQL 18.5, 17.11, 16.15, 15.19, and 14.24 are affected.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.2",
  "pubDate": "2026-08-13T13:19:16.747Z",
  "pubdate": "2026-08-13T13:19:16.747Z",
  "executiveSummary": "A missing authorization vulnerability exists in PostgreSQL logical decoding. The flaw allows a non-superuser holding REPLICATION privilege to leverage the selection of a logical decoding plugin to execute arbitrary code via the dynamic loading of files visible to the operating system user account running the database server. The vulnerability impacts PostgreSQL versions prior to 18.5, 17.11, 16.15, 15.19, and 14.24.\nThe risk implication is severe, as it bridges database-level replication privileges to full operating system code execution under the security context of the PostgreSQL service account. An attacker possessing REPLICATION privileges can exploit this flaw without superuser intervention, bypassing expected permission boundaries and compromising the underlying host environment. Exploitation requires authenticated access to the database server with specific replication rights and the ability to specify or configure a logical decoding plugin that triggers the operating system's dynamic linker functionality.",
  "technicalDetails": "The root cause of the vulnerability lies in insufficient authorization checks within the PostgreSQL logical decoding subsystem. Specifically, when establishing a logical decoding session, the database engine permits the specification of a custom output plugin. PostgreSQL utilizes dynamic loading mechanisms via the operating system's dlopen functionality to load and execute the specified plugin binary.\nWhile standard dynamic library loading in PostgreSQL typically enforces strict path restrictions or requires database superuser privileges, the logical decoding implementation fails to adequately restrict plugin selection for users holding only REPLICATION privileges. Consequently, a malicious or unprivileged user with replication rights can supply a path to any file accessible to the operating system account executing the PostgreSQL daemon.\nThe step-by-step attack flow proceeds as follows: First, the attacker authenticates to the PostgreSQL server using credentials that possess the REPLICATION privilege. Second, the attacker initiates a replication stream or logical decoding session using SQL commands such as pg_logical_slot_get_changes or via the replication protocol, explicitly supplying a targeted file path or a specially crafted file visible to the postgres OS user as the logical decoding plugin parameter. Third, the PostgreSQL server attempts to load the provided path using the dlopen function. Fourth, the operating system executes the initialization routines contained within the loaded file. Finally, this results in arbitrary code execution within the memory space and security context of the operating system account running the PostgreSQL service server.\nThe vulnerable component is the logical decoding plugin loading mechanism within PostgreSQL. Affected versions include all releases prior to 18.5, 17.11, 16.15, 15.19, and 14.24. The requirement for exploitation includes holding REPLICATION privileges, network exposure to the PostgreSQL service, and read/load access by the database server user to the target file being passed to dlopen."
}