PostgreSQL released a major security update on November 12, 2026: versions 18.7, 17.12, 16.16, 15.20, and 14.25 fix 52 security vulnerabilities, most of them rated 8.8 out of 10. A logged-in database user could exploit many of them to run arbitrary code as the operating system user behind the database.
If you run PostgreSQL anywhere — your own server, a VPS, or a managed service — check your version today and patch. This is one of the largest PostgreSQL security releases ever, and the fix is a simple minor update.
This guide explains what was fixed, which versions are safe, how to check your version, and how to patch — including what to do if your database is managed by a cloud provider. It also covers the remarkable story at the center of the release: a type-confusion bug whose roots go back 22 years, to a commit from May 2004.
What Was Fixed: 52 Flaws, Most of Them Critical
The scale of this release is unusual. The PostgreSQL Global Development Group fixed 52 security vulnerabilities and over 140 other bugs in a single update, across every supported version. Thirty-two of the 52 CVEs score 8.8 on the CVSS scale. Most share the same attack pattern: a database role that can create a table, function, or type uses it to trigger a type confusion or use-after-free bug, and ends up executing code as the postgres operating system account.
That pattern matters because the barrier to entry is low. Six of the flaws need nothing more than a database login — a read-only account without CREATE privileges is enough. If your database has any login role you do not fully trust — an application account, a reporting user, a third-party integration — that account is a potential attacker until the binaries are replaced. There is no configuration workaround for most of these flaws; the fix is the update.
The flaws fall into a few families. The largest group is type confusion: the database misreads a value because its type changed mid-operation, and the confusion leads to memory corruption and code execution. Others are heap buffer overflows, use-after-free bugs, and integer wraparounds. A smaller group covers privilege and row-security gaps, small memory disclosures, and one pre-authentication spinlock leak. The common thread is memory safety in the core server — the part of PostgreSQL that every query passes through.
The 22-Year-Old Bug at the Center: CVE-2026-6460
The most important single flaw is CVE-2026-6460, rated 8.8. It is a type confusion in how PostgreSQL handles composite types when a row type changes — for example, after ALTER TYPE or ALTER TABLE ... SET DATA TYPE — while a query has already captured values of that type. The database then misreads those values, and the confusion can be turned into remote code execution.
A proof of concept exists, and the flaw was reported by about 20 different people, including the OpenAI and Anthropic security programs.
The remarkable part is the age of the underlying primitive. Security researcher Mehmet Ince, who reported 21 related cases, traces the mutable-row-type primitive to a commit from May 5, 2004 — more than 22 years ago — that introduced ALTER TABLE ... ALTER COLUMN ... TYPE. The exploitation technique he used relies on another commit from May 14, 2015, which added expanded-object pointers.
In his write-up of the research, he describes turning the old primitive into a working remote code execution chain without any AI assistance, starting in August 2026.
PostgreSQL treated CVE-2026-6460 as an umbrella issue covering a much wider family of composite-type problems, and the fix is correspondingly broad. It introduces composite attribute versioning: the database now tracks when a type definition changes and refuses to read values captured under the old version. Six of the 52 CVEs are directly connected to this article's findings, including CVE-2026-120142 (dropped-column type confusion), CVE-2026-120148 (extended-statistics pseudo-type confusion, rated 8.1), and CVE-2026-120139 (tuple-size integer wraparound, rated 8.8).
This is the second major server vulnerability disclosure in as many days — the Apache HTTP Server RCE flaw was disclosed on November 11 — and it follows the Claude Code password leak from earlier in the month. November 2026 is turning into a busy month for security teams, and the PostgreSQL release is the biggest item on the list so far.
Which Versions Are Safe?
The fix is available for every supported PostgreSQL branch. If you run any version below the fixed release for your branch, you are affected. PostgreSQL 14 deserves special attention: 14.25 is the final release of PostgreSQL 14, which is now end of life and will receive no further security or bug fixes. If you still run PostgreSQL 14 in production, this update is your last one — plan an upgrade to a supported version.
| Branch | Fixed version | Status |
|---|---|---|
| PostgreSQL 18 | 18.7 | Supported — update now |
| PostgreSQL 17 | 17.12 | Supported — update now |
| PostgreSQL 16 | 16.16 | Supported — update now |
| PostgreSQL 15 | 15.20 | Supported — update now |
| PostgreSQL 14 | 14.25 | End of life — final release, plan an upgrade |
The release also includes the second release candidate of PostgreSQL 19, which is not yet a stable release. If you are testing PostgreSQL 19, use RC 2 rather than RC 1. For everyone else, the minor update for your current branch is the right move — there is no need to change major versions to get the security fix.
How to Check Your PostgreSQL Version
Checking takes seconds. If you can connect to the database, run one query:
SELECT version();The output shows your full version string, for example "PostgreSQL 16.15 on x86_64-pc-linux-gnu". Compare the number with the table above: anything below the fixed version for your branch needs the update. You can also check from the command line with pg_config --version, or ask your hosting provider if you do not have database access.
If you run PostgreSQL in a container, check the image tag — many deployments pin a specific minor version, and the tag tells you exactly what you have. If you manage databases for clients, check all of them: the flaws affect every supported branch, so a fleet with mixed versions is likely to have more than one vulnerable server.
For the public side of your stack, a HTTP Header Checker shows what your server reveals to the outside world, though the database version itself is never exposed in headers.
How to Patch: Stop, Replace, Start
Patching is a minor update, and minor updates in PostgreSQL are deliberately simple. You do not need to dump and reload your database, and you do not need pg_upgrade. Stop PostgreSQL, update its binaries through your package manager or installer, and start it again. The official announcement confirms this directly: all update releases are cumulative, so one update brings you to the fixed version whatever you are coming from.
The exact commands depend on your system. On Debian or Ubuntu with the PostgreSQL apt repository, it is apt update followed by apt install for the postgresql package of your branch. On Red Hat-based systems, use dnf or yum. On managed servers, your provider's update mechanism applies the new binaries. In every case, stop the server first, replace the binaries, and start it again — do not try to swap binaries under a running server.
After updating, there are post-update steps for some installations. The release fixes several index-corruption issues in GIN and pg_trgm indexes, so reindex any index you suspect is affected. The announcement also recommends taking a new full backup after updating and using it as the base for subsequent incremental backups, because several incremental-backup fixes could have produced corrupt backups before the update. Check the "Updating" section of the official release announcement for the full list of post-update steps.
What If You Run Managed PostgreSQL?
Many teams do not run PostgreSQL themselves. If your database is on a managed PostgreSQL hosting service — Amazon RDS or Aurora, Google Cloud SQL, Azure Database for PostgreSQL, or a smaller provider — the provider applies the patch, not you. That does not mean you can ignore the release: you need to know when your provider will apply it, and whether your instances are scheduled.
Managed providers typically roll out minor updates on a maintenance schedule, and the timing varies. Some apply security patches quickly; others wait for their next maintenance window, which can be days away.
Open your provider's console and check the pending maintenance for each instance. If a patch is scheduled, note the date. If nothing is scheduled, contact support or check the provider's status page — for a release of this size, most providers publish a timeline within a day or two.
While you wait, reduce the risk. Review which roles can log in to each database and remove any you do not recognize or no longer need. Six of these flaws need only a login, so every unnecessary account is an unnecessary opening.
If an application connects with a highly privileged role, consider whether it can use a restricted one instead. These are good habits at any time; during a patch window, they are the only defense you have. The pganalyze analysis of the release walks through the same triage, including which CVE families matter most for managed deployments.
What an Attacker Could Do With These Flaws
The impact is straightforward: arbitrary code execution as the operating system user running the database, usually the postgres account. From there, an attacker can read any data the database can reach, including credentials stored in it. They can also pivot to other services on the same host, since the database server often shares a machine with application code, backups, or configuration files.
The CVSS scores reflect that. A score of 8.8 with an attack vector of network, low complexity, low privileges required, and no user interaction means the flaw is remotely exploitable by an authenticated user with total loss of confidentiality, integrity, and availability. That is the worst realistic combination short of an unauthenticated flaw — and for the six flaws that need only a login, the privileges required are effectively just having an account.
There is no public evidence of exploitation in the wild for these CVEs at the time of writing. But a proof of concept exists for the headline flaw, and the details are now public. The window between disclosure and exploitation is usually measured in days for flaws like these. Patching now is not cautious — it is the normal response.
Why This Release Is Different
PostgreSQL does not usually ship 52 security fixes at once. The size of this release says something about what was found: not one bug, but a whole family of related memory-safety problems in the core server, many of them sharing the same root cause in type handling.
The umbrella fix for CVE-2026-6460 was invasive enough that PostgreSQL added a new versioning layer for composite types — a significant change for a minor release, made because the alternative was leaving the holes open.
The release also fixes over 140 non-security bugs, including several that could cause data loss or wrong query results: GIN index corruption, planner errors with lateral references and outer joins, and incremental backup corruption. Even if the security flaws did not exist, this would be a worthwhile update. With them, it is urgent.
Run SELECT version() today. If the number is below the fixed release for your branch, update. If you are on PostgreSQL 14, update to 14.25 and then plan your move to a supported version, because there will not be another 14 release. The check takes a minute and the patch takes a few more — and for the largest PostgreSQL security release in recent memory, that is a very good trade.
Frequently Asked Questions
Which PostgreSQL versions are affected by the November 2026 security flaws?
Every supported branch is affected: PostgreSQL 14 through 18. The fixed versions are 18.7, 17.12, 16.16, 15.20, and 14.25. Any installation running an earlier minor version on those branches is vulnerable. PostgreSQL 14 is end of life with this release, so 14.25 is the last fix it will ever receive.
How do I check my PostgreSQL version?
Connect to the database and run SELECT version(); — the output shows your full version string. You can also run pg_config --version from the command line, check your container image tag, or ask your hosting provider. Compare the number with the fixed version for your branch in the table above.
Do I need to patch if my database is managed?
Yes, but your provider applies the patch. Check your provider's console for scheduled maintenance on each instance — Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL, and others roll out minor updates on their own schedules. If nothing is scheduled, contact support. While you wait, remove unnecessary login roles, since six of the flaws need only a database login.
What is CVE-2026-6460?
CVE-2026-6460 is the headline flaw in this release, rated 8.8. It is a type confusion after a row type changes — for example, after ALTER TYPE or ALTER TABLE ... SET DATA TYPE — that lets a database user execute arbitrary code. It was reported by about 20 people, including the OpenAI and Anthropic security programs, and the underlying primitive dates to a 2004 PostgreSQL commit.
Is there an exploit in the wild for these PostgreSQL flaws?
No public exploitation in the wild has been reported, and the technical details are public. However, a proof of concept exists for CVE-2026-6460. The window between disclosure and exploitation for flaws like these is usually measured in days, so patch now rather than waiting for an in-the-wild report.
Do I need to dump and reload my database to apply the fix?
No. This is a minor update: stop PostgreSQL, update the binaries, and start it again. No dump, reload, or pg_upgrade is needed. After updating, reindex any GIN or pg_trgm indexes you suspect are affected, and take a new full backup to use as the base for future incremental backups.
