{"id":2698,"date":"2026-09-04T18:06:45","date_gmt":"2026-09-04T18:06:45","guid":{"rendered":"https:\/\/thedigitalfortress.us\/?p=2698"},"modified":"2026-09-04T18:06:45","modified_gmt":"2026-09-04T18:06:45","slug":"postgresql-fixes-12-year-old-logical-decoding-flaw-enabling-replication-role-code-execution","status":"publish","type":"post","link":"https:\/\/thedigitalfortress.us\/?p=2698","title":{"rendered":"PostgreSQL Fixes 12-Year-Old Logical Decoding Flaw Enabling Replication-Role Code Execution"},"content":{"rendered":"
\n
<\/a><\/div>\n

PostgreSQL has released updates to address a security flaw that allows an account with the REPLICATION attribute to run arbitrary code as the operating-system user running the database server.<\/p>\n

The flaw, tracked as CVE-2026-6471<\/strong> (CVSS score: 7.2), has been present since logical decoding was introduced in PostgreSQL 9.4 in 2014. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.<\/p>\n

Exploitation requires an account carrying the REPLICATION attribute and a server running with wal_level = logical. Backup tools, standby servers, change data capture (CDC) pipelines, and monitoring systems routinely hold that attribute.<\/p>\n

The fix, shipped on August 13, adds a server parameter called output_plugin_libraries that lists which libraries may be loaded as logical decoding output plugins, defaulting to ‘pgoutput, test_decoding’.<\/p>\n

Installations using any other output plugin, wal2json, and decoderbufs<\/p>\n

among them, will have logical decoding refused after updating until an administrator adds the library to that list and reloads the server configuration.<\/p>\n

\u00abPreviously, a replication user could select any loadable library for logical decoding, allowing exploits of various sorts. To allow locking this down without breaking setups that worked before, introduce a whitelist of allowed output plugins,\u00bb the PostgreSQL Global Development Group said in the 18.6 release notes<\/a>.<\/p>\n

\n
\"Cybersecurity\"<\/a><\/div>\n<\/div>\n

The PostgreSQL Project credited Vladimir Tokarev and Yu Kunpeng with reporting the problem.<\/p>\n

Tokarev detailed it in a September 1 write-up<\/a> for data security firm Cyera Research, which names the flaw PostGREShell<\/strong>.<\/p>\n

The plugin name supplied in a CREATE_REPLICATION_SLOT command is passed directly to the function that loads the library, Cyera said.<\/p>\n

<\/p>\n

PostgreSQL’s existing restriction on plugin paths, which confines non-superusers to a single administrator-controlled directory, is never called on the replication path. The replication protocol’s parser accepts almost any character inside a double-quoted plugin name, including path separators and ..\/ traversal, so a full filesystem path reaches the loader as typed.<\/p>\n

\"\"<\/a><\/div>\n

On Windows, the server resolves a network path over Server Message Block (SMB) and fetches the library from a machine the attacker controls, writing nothing to the target, Cyera said.<\/p>\n

On Linux and macOS, the same result requires enabling Network File System (NFS) automounting. Everywhere else the attacker needs an existing way to write a file to the server’s disk. Code loaded this way runs inside the database backend process as the postgres operating-system user.<\/p>\n

Cyera’s test plugin then wrote the role catalog directly to make the replication account a PostgreSQL superuser. It also set up three persistence mechanisms that survive a server restart.<\/p>\n

Cyera describes the REPLICATION attribute as a low-privilege backup credential, but PostgreSQL scored the flaw with Privileges Required set to High, a rating reproduced in SUSE’s own assessment<\/a>.<\/p>\n

\"\"<\/a><\/div>\n

PostgreSQL rejected applying its existing LOAD restriction to the replication path.<\/p>\n

\u00abREPLICATION users were not previously subject to restrictions on output plugin paths, so they were able to bypass LOAD-time protections during logical decoding. Unfortunately, adding the standard LOAD restrictions now would retroactively require all third-party output plugins to be installed under the $libdir\/plugins directory,\u00bb Jacob Champion, who wrote the fix, said in the commit message<\/a>.<\/p>\n

Failed loads appear in the server log as ERROR: library \u00ab…\u00bb may not be used as an output plugin, with a hint naming the setting, according to the parameter’s documentation<\/a>.<\/p>\n

Administrators are advised to take the following steps –<\/p>\n

    \n
  1. Run SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; before updating to identify the output plugins in use, which will only show plugins successfully used at some point.<\/li>\n
  2. Update to 18.6, 17.11, 16.15, 15.19, or 14.24, or to the equivalent distribution package.<\/li>\n
  3. Add any non-default plugin to output_plugin_libraries and reload the configuration with pg_ctl reload or SELECT pg_reload_conf(). A restart is not required.<\/li>\n
  4. Set the new cluster’s output_plugin_libraries before running pg_upgrade –check when migrating from version 17 or later, as the check fails if the list does not permit the old cluster’s slot plugins.<\/li>\n<\/ol>\n

    Fixed packages are available on Amazon RDS<\/a> for all five branches, as well as from Debian, SUSE, and Ubuntu.<\/p>\n

    PostgreSQL’s advisory<\/a> covers supported branches 14 through 18 and does not address earlier ones. PostgreSQL 14 stops receiving fixes on November 12, 2026, the project said in its release announcement<\/a>.<\/p>\n

    The upstream fix \u00abrequires additional changes to the configuration if some extensions are used,\u00bb Debian’s advisory<\/a> warns, naming its wal2json and decoderbufs packages.<\/p>\n

    Ubuntu’s USN-8653-1<\/a>, which shipped the fix for 22.04, 24.04, and 26.04 LTS on August 20, makes no mention of the parameter and tells administrators only to restart PostgreSQL after the update.<\/p>\n

    \n
    \"Cybersecurity\"<\/a><\/div>\n<\/div>\n

    As of September 4, the wal2json project had updated its documentation<\/a> to tell users to add the plugin to output_plugin_libraries, citing the CVE.<\/p>\n

    A gap in the fix is still open. pg_createsubscriber creates replication slots using pgoutput without checking the new parameter, so a –dry-run succeeds and the conversion then fails.<\/p>\n

    \u00abpg_createsubscriber command creates replication slots with plugin ‘pgoutput’, without checking the GUC. This meant if the plugin name is not specified in the parameter, –dry-run mode passes but actual convertion fails. It’s very surprising for users and should be avoided,\u00bb Hayato Kuroda of Fujitsu said in a message to the pgsql-hackers mailing list<\/a>.<\/p>\n

    A patch was under review and had not been committed as of September 4. CVE-2026-6471 remained absent from CISA’s Known Exploited Vulnerabilities (KEV) catalog<\/a> as of September 4.<\/p>\n

    The Hacker News found no proof-of-concept code for it in public repositories on the same date.<\/p>\n

    Until the update can be applied, Cyera said exposure can be reduced by stripping the REPLICATION attribute from accounts that do not need it, restricting replication entries in pg_hba.conf to known addresses, blocking outbound SMB (port 445) and NFS (port 2049) traffic from database servers, and disabling autofs where it is not needed.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    PostgreSQL has released updates to address a security flaw that allows an account with the REPLICATION attribute to run arbitrary code as the operating-system user running the database server. The…<\/p>\n","protected":false},"author":1,"featured_media":2699,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[3309,10,3311,524,13,655,70,3310,1074,3312],"class_list":["post-2698","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-12yearold","tag-code","tag-decoding","tag-enabling","tag-execution","tag-fixes","tag-flaw","tag-logical","tag-postgresql","tag-replicationrole"],"_links":{"self":[{"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/posts\/2698","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2698"}],"version-history":[{"count":0,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/posts\/2698\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/media\/2699"}],"wp:attachment":[{"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2698"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2698"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2698"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}