What these two vulnerabilities do
CVE-2026-6471 (CVSS 7.2) affects the logical decoding mechanism introduced in PostgreSQL 9.4. An account holding the REPLICATION attribute can specify an arbitrary output plugin when creating a logical replication slot. Before the fix, PostgreSQL loaded the requested file via dlopen without verifying its origin, allowing code to be executed with the privileges of the postgres system account. The attacker does not need direct network access to your instance: a compromised replication peer, a CDC (Change Data Capture) tool, or an internal user with the REPLICATION attribute is enough. The fix adds an output_plugin_libraries parameter listing allowed libraries — defaulting to pgoutput and test_decoding only.
CVE-2026-14669 (CVSS 8.8) is a heap buffer overflow in the to_char(timestamptz) function. The function builds a work buffer from the format string, but the POSIX timezone handling code paths copy the user-supplied abbreviation into that buffer without a length check. An ordinary authenticated user can trigger the vulnerability by passing an excessively long timezone abbreviation, overwriting adjacent heap structures and hijacking execution to achieve arbitrary code execution with postgres OS user privileges.
Two CVE comparison
| Criterion | CVE-2026-6471 | CVE-2026-14669 |
|---|---|---|
| CVSS Score | 7.2 (High) | 8.8 (High) |
| Component | Logical decoding | `to_char(timestamptz)` |
| Attack vector | Network | Network |
| Minimum required privilege | REPLICATION attribute | Authenticated user |
| Public access required | No | No |
| Impact type | Arbitrary code execution | Arbitrary code execution |
| Fix date | 2026-08-13 | 2026-08-13 |
Affected and fixed versions
Both CVEs affect all maintained PostgreSQL branches. The fixed versions, released simultaneously on August 13, 2026, are: PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24. Any instance running a version older than these numbers is exposed. PostgreSQL 13 and earlier have reached end of life and no longer receive patches: if your instance runs on an end-of-life branch, these CVEs add to an already existing structural risk. Applications that embed PostgreSQL — Supabase, NocoDB, Gitea, Twenty CRM, Planka — are affected if they have not yet updated their base image.
Before patching: audit your replication roles
Before applying the patch, it is worth knowing how many accounts carry the REPLICATION attribute on your instances. The following query lists all concerned roles:
SELECT rolname, rolreplication, rolsuper FROM pg_roles WHERE rolreplication = true OR rolsuper = true ORDER BY rolsuper DESC, rolname;
If you find accounts with REPLICATION that are not serving an active replication purpose (backup, CDC, monitoring), revoke the attribute: ALTER ROLE role_name NOREPLICATION;. This is a partial workaround while waiting for the patch, and a permanent good practice.
Patching via apt on Debian and Ubuntu
Check the current version
Connect to your instance and check the current version: psql -U postgres -c 'SELECT version();'. Note the branch (14, 15, 16, 17, or 18) to install the correct target package.
Ensure the PGDG repository is configured
Standard Debian and Ubuntu repositories often ship outdated versions. To get up-to-date fixes, use the official PostgreSQL repository. If not already configured: sudo apt install -y postgresql-common && sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh. This script configures the PGDG repository for your distribution.
Update the packages
A minor update (17.10 → 17.11, 16.14 → 16.15, etc.) does not require pg_upgradecluster and keeps your data in place. Run: sudo apt update && sudo apt install postgresql-17 (replace 17 with your branch). APT will install the fixed version. For other branches: sudo apt install postgresql-16, postgresql-15, postgresql-14 as appropriate.
Restart the service
The service must be restarted to load the new binary: sudo systemctl restart postgresql. Then verify the service restarted correctly: sudo systemctl status postgresql.
Confirm the version after patching
Reconnect and verify the displayed version matches the fix: psql -U postgres -c 'SELECT version();'. You should see 17.11, 16.15, 15.19, 14.24, or 18.6 depending on your branch.
Patching via Docker
Pull the fixed image
The official postgres images on Docker Hub have been updated with the fixed versions. Pull the image matching your branch: docker pull postgres:17.11, or with the minor tag for your branch (postgres:16.15, postgres:15.19, postgres:14.24). For Alpine images: docker pull postgres:17.11-alpine.
Restart the container
If you use Docker Compose, update the image tag in your docker-compose.yml, then: docker compose pull && docker compose up -d. For a directly launched container: docker stop postgres-container && docker rm postgres-container, then relaunch with the new image. Your data stays in the mounted volume — verify the volume is declared before removing the container.
Verify the version inside the container
Connect to the container and confirm the version: docker exec -it postgres-container psql -U postgres -c 'SELECT version();'. The output should show the fixed version.
Workarounds if patching is temporarily impossible
If you cannot restart the instance immediately, three measures reduce exposure to CVE-2026-6471 without applying the patch:
First, revoke the REPLICATION attribute from accounts that do not need it (ALTER ROLE name NOREPLICATION;). Second, restrict replication entries in pg_hba.conf to the IP addresses of legitimate peers only — replace a rule host replication all 0.0.0.0/0 with entries specific to each authorized host. Third, if your instance does not use logical replication at all, you can set wal_level = replica (instead of logical) in postgresql.conf — this disables logical decoding and closes the CVE-2026-6471 attack vector.
For CVE-2026-14669, no application-level workaround is documented: the only remedy is updating the binary.
Checking applications that embed PostgreSQL
Supabase, NocoDB, Gitea, Twenty CRM, and Planka embed PostgreSQL in their Docker images or Helm charts. For these applications, updating PostgreSQL means updating the application image itself. Check each application's release notes: since August 13, 2026, distributions that published an update should have integrated PostgreSQL 17.11, 16.15, or equivalent. If no update is available for your application, you can deploy a separate PostgreSQL container at the fixed version and point the application to it — or pin the postgres base image in your docker-compose.yml to the fixed version, if the architecture allows.
The SELECT version(); command in psql is not sufficient to confirm the fix is active if multiple PostgreSQL binaries coexist on the same host. Check which binary is actually running: pg_lsclusters on Debian/Ubuntu lists all clusters with their version. Ensure the active cluster is using the updated binary, not a residual binary from a previous installation.
Deploy PostgreSQL with root access to apply patches yourself
On shared hosting or in a PaaS environment, you have no access to the PostgreSQL binary: the update depends on your provider. On a VPS with root access, you apply this patch in under ten minutes, without depending on a third party. You choose the restart window, you keep control over pg_hba.conf, and you audit your replication roles yourself. This is the model that naturally applies to any self-hosted stack.
