Cybersecurity
PostgreSQL patches replication code execution flaw
PostgreSQL released fixes for CVE-2026-6471, a logical decoding flaw that could let a replication account execute code as the database server user, and asked administrators to update plugin settings.
- PostgreSQL shipped fixes on 13 August for CVE-2026-6471, which affected releases before 18.6, 17.11, 16.15, 15.19 and 14.24.
- Exploitation required an account with the REPLICATION attribute and a server configured with wal_level = logical.
- The new output_plugin_libraries setting limited which logical decoding plugins could load, and non-default plugins had to be added after upgrading.
- The PostgreSQL Project credited Vladimir Tokarev and Yu Kunpeng, and Tokarev later described the issue in a 1 September Cyera Research post.
- A separate patch for pg_createsubscriber was still under review on 4 September, and the flaw was not in CISA's KEV catalog.
PostgreSQL shipped updates on 13 August for CVE-2026-6471. The issue affected releases before 18.6, 17.11, 16.15, 15.19 and 14.24, and it had existed since logical decoding appeared in PostgreSQL 9.4 in 2014.
The flaw could be used only when an account had the REPLICATION attribute and the server ran with wal_level set to logical. PostgreSQL said backup tools, standby servers, CDC pipelines and monitoring systems often used that attribute.
Cyera said the replication path handed the plugin name from CREATE_REPLICATION_SLOT straight to the library loader. It said the parser accepted quoted names containing path separators and ../ sequences, so an attacker could point the loader at a full path.
According to Cyera, Windows could retrieve a library over SMB from an attacker-controlled machine, while Linux and macOS needed NFS automounting or another way to place a file on disk. The company said its test plugin then changed the role catalogue to make the replication account a superuser and added three persistence methods.
PostgreSQL rejected applying its usual LOAD restriction to the replication path. Jacob Champion said in the commit message that the change would have broken third-party plugins outside the administrator-controlled plugins directory, so the fix instead introduced output_plugin_libraries with pgoutput and test_decoding listed by default.
Named in this story
People
- Vladimir Tokarev
- reported the problem and wrote the Cyera Research note
- Yu Kunpeng
- was credited with reporting the problem
- Jacob Champion
- wrote the fix and explained it in a commit message
Companies
- Cyera
- described the attack path and tested the exploit plugin
- SUSE
- published an assessment that repeated the CVSS rating
Organisations
- PostgreSQL Project
- credited the researchers and published release notes
- PostgreSQL Global Development Group
- explained the new plugin restriction in release notes
- Cyera Research
- published the September 1 write-up that named the flaw PostGREShell
- Debian
- warned that some extensions needed extra configuration after the update
- Ubuntu
- shipped updated security notices for supported releases
Products and systems
- PostgreSQL
- released the affected updates
- Amazon RDS
- had fixed packages available for the affected branches
- pgoutput
- was the default logical decoding plugin named in the fix
- test_decoding
- was listed as a default logical decoding plugin
- wal2json
- was named as a non-default plugin affected by the new setting
- decoderbufs
- was named as a non-default plugin affected by the new setting
- pg_createsubscriber
- still failed to check the new parameter in one conversion path
How the source tells it
The source read as a technical security advisory, with a modest sense of urgency from the patching and mitigation guidance.
- urgency It foregrounded upgrade and reload steps alongside advice for reducing exposure before patching
- threat It stressed code-execution impact and attacker-controlled loading paths when explaining the flaw