PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25: vulnerabilities in one minor release

What happened

52 vulnerabilities in one minor release — an unusually large batch for PostgreSQL, which usually fixes a handful at a time.

43 flaws are in the core, 6 in client tools (pg_dump, pg_restore, pg_basebackup, reindexdb, vacuumdb) and 3 in bundled extensions (plperl, pltcl, dblink, dict_int).

40 reach all five lines; the rest touch only the lines that carry the feature, so do not read 52 as the same number for every line.

32 carry CVSS 8.8: they need a logged-in role, but any role will do, and the result is code as the process's operating-system user.

Only 1 needs no login, and that one affects availability only.

PostgreSQL 14 gets its final release here and is end-of-life: no further security fix will come for that line.

The path in

• Any role, no superuser needed. A web application connects with its own role; one SQL injection in that application is enough to reach these flaws.
• A closed port does not remove the risk. The attacker goes through the application, not through port 5432.
• Client tools count too: pg_restore on an archive you did not produce, pg_dump in tar format piped to psql, pg_basebackup reading a manifest — so cron backup jobs and docker exec are in scope.
• Extensions: only where plperl, pltcl, dblink or dict_int is installed.
• PostgreSQL 14: end-of-life, so nothing after this release — for that line the answer is a major upgrade, not a minor one.

Which copy runs

• Docker and Compose: the image tag is the version. postgres:16 pulled on deploy day stays at that day's minor; a floating tag only helps after docker compose pull and up -d.
• The distro's package: postgresql-16 from the repository; patch with apt, then restart the cluster.
• Managed services (RDS, Cloud SQL, Supabase, Neon): the provider patches on its own schedule; SELECT version() shows the build that actually runs.
• Built from source or from your own image: nobody patches it for you.

Running is not installed

• apt upgrade replaces files on disk; the postmaster keeps the old binary in memory until it restarts. SELECT version() answers "which build is running"; dpkg -l postgresql-16 does not.
• With a container, pull only downloads the image; up -d creates the new process. docker ps still shows the old image if you stopped at pull.

The fix for each line

After the upgrade, not only the upgrade

Replacing the binary is enough to fix the code, but this release also has data work. The announcement's Updating section, verbatim, so you can check against it:

All PostgreSQL update releases are cumulative. As with other minor releases, users are not required to dump and reload their database or use pg_upgrade in order to apply this update release; you may simply stop PostgreSQL and update its binaries.

If you suspect that a GIN index is affected by one of the corruption issues fixed in this release, you should reindex it, for example:

REINDEX INDEX your_index_name;

If you use pg_trgm, you should reindex any GiST indexes that use the gist_trgm_ops operator class.

If you see missing chunk number errors when reading a table, you should reindex the table, which also reindexes its TOAST table, for example:

REINDEX TABLE your_table_name;

If you use incremental backups, we recommend taking a new full backup after updating and using it as the basis for subsequent incremental backups.

If you use partitioned tables, the following query finds NOT NULL NO INHERIT constraints on partitioned tables:

SELECT conrelid::regclass, conname
FROM pg_constraint
WHERE contype = 'n' AND connoinherit
AND conrelid IN (SELECT oid FROM pg_class WHERE relkind = 'p');

You can remove unwanted constraints with ALTER TABLE ... DROP CONSTRAINT .... Constraints you want to keep should be repaired with ALTER TABLE ... ALTER CONSTRAINT ... INHERIT, which will fail if any of the table's partitions contain NULL values in that column.

If you have B-tree indexes on bpchar columns (that is, columns declared as bpchar without a length), you should reindex them after updating. Columns declared as char(n) are not affected.

Users who have skipped one or more update releases may need to run additional post-update steps; please see the release notes from earlier versions for details.

For more details, please see the release notes .

If you use pg_trgm for search, the GiST REINDEX is the step most easily missed: search keeps working and quietly returns fewer rows.

The 52 vulnerabilities

Descriptions and CVSS scores are quoted in English from postgresql.org's CVE pages; each row links its page.

What to do

• Move the line you run to its fixed release — the table above. A minor update needs no dump and reload.
• PostgreSQL 14: upgrade the major (pg_upgrade, or dump and restore) to a supported line. The last release of 14 is not a fix.
• Containers: docker compose pull then up -d, then check SELECT version() inside the container.
• Managed services: read the build in use; if the provider has not patched, there is no fix on your side, only mitigation in the application.

Check yourself

psql -c 'SELECT version();'

Tells you: the build actually running, not the one installed

psql -c 'SHOW server_version;'

Tells you: the version the server reports

psql -c 'SELECT pg_postmaster_start_time();'

Tells you: when the postmaster started: before the package upgrade means the new binary is not loaded

docker exec <container> psql -U postgres -c 'SELECT version();'

Tells you: the build inside the container, not on the host

apt list --installed 'postgresql-*'

Tells you: the installed packages on Debian or Ubuntu — only half the answer

psql -c '\dx'

Tells you: installed extensions: plperl, pltcl, dblink, dict_int are in this group

Sources

• https://www.postgresql.org/about/news/postgresql-187-1712-1616-1520-1425-and-19-rc-2-released-3442/
• https://www.postgresql.org/support/security/
• CVE-2026-116304
• CVE-2026-116306
• CVE-2026-116307

Written from the release announcement and postgresql.org's CVE pages; data read on 2026-11-13. Where they differ, postgresql.org wins.