PostgreSQL 18.7 security release: 52 CVEs, check your version

If you keep scraped data in PostgreSQL, check the version today. On 12 November 2026 PostgreSQL released 18.7, 17.12, 16.16, 15.20 and 14.25, which fix 52 security vulnerabilities and over 140 bugs. The headline one, CVE-2026-6460, lets a low-privilege role run code on the database server. And 14.25 is the last release PostgreSQL 14 will ever get.

What PostgreSQL fixed on 12 November

The release announcement covers every supported branch plus the second release candidate of PostgreSQL 19, which is planned for general release on 19 November 2026. Its own words: “This release fixes 52 security vulnerabilities and over 140 bugs reported over the last several months.”

That’s a big list, and it’s not padded with low scores. Going through the announcement’s table, 32 of the 52 CVEs are rated CVSS 8.8, and 28 titles say the bug executes or may execute arbitrary code. The rest range from 3.1 to 8.1.

Branch	Fixed version	Supported until
18	18.7	14 November 2030
17	17.12	8 November 2029
16	16.16	9 November 2028
15	15.20	11 November 2027
14	14.25	final release, now end of life

The support dates come from PostgreSQL’s versioning policy.

CVE-2026-6460: a 22-year-old type confusion

PostgreSQL’s advisory for CVE-2026-6460 describes a type confusion that “allows an object creator to execute arbitrary code as the operating system user running the database”. The main route is ALTER ... SET DATA TYPE, and the advisory names others, such as adding a column, rolling back and adding it again. The root cause, in its words, is that “values were not self-identifying”, so stale values could survive in places like PL/pgSQL variables and data dictionary entries.

• Score: CVSS 3.0 8.8, vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. That PR:L is the part to notice, because it means low privileges, not superuser.
• Affected: every version before 18.7, 17.12, 16.16, 15.20 and 14.25.
• Workaround: none listed. Upgrade.

Mehmet Ince, a vulnerability researcher, published his write-up on 9 November as part 3 of a six-part series on risk in managed PostgreSQL. He says he could trigger the crash “as a lowest-privileged login role on any PostgreSQL instance”, and that he turned it into a working exploit on PostgreSQL 18.6. He dates the underlying primitive to a commit from 5 May 2004, the one that added ALTER TABLE ... ALTER COLUMN ... TYPE, which is where the 22 years come from.

He also reported 21 related cases, and says 6 of the 52 CVEs are directly connected to his write-up, with CVE-2026-6460 as the umbrella fix.

Why this matters if you store scraped data

A scraping setup rarely has one database user. The usual picture is a role per worker pool, maybe one per customer or project, a read-only role for the dashboard, and a login someone made for a BI tool once and forgot. Every one of those can log in, and a bug that needs only a login turns each of them into a possible route to the server’s operating system account.

That’s the part worth thinking through. If a worker’s credentials sit in a config file on a cheap VPS, or a tenant can write their own SQL against a shared database, the question isn’t whether your superuser password is strong. It’s who else holds a login. Raw pages and parsed records often share one server too, as in a typical scraping architecture, so code execution there reaches all of it.

Managed hosting doesn’t take this off your plate. Ince writes that he ported his exploit to “almost every managed PostgreSQL platform” he knew and hadn’t seen a vendor that wasn’t affected. The teams he sent reports to include AWS Aurora/RDS, Microsoft Azure PostgreSQL, Google AlloyDB and Supabase. Your provider decides when you get 18.7, so look at what it’s running.

Check your setup in five minutes

1. Version, on every server.

SELECT version();
SHOW server_version;

Run it on primaries, replicas, the staging copy and anything in a container. Compare the minor number with the table above. A replica runs its own binaries, so it can lag behind the primary.

2. Who can log in.

SELECT rolname, rolsuper, rolcreaterole, rolcreatedb
FROM pg_roles
WHERE rolcanlogin
ORDER BY rolname;

Every row here is a role that can connect. Shared worker users, per-tenant roles and old tool accounts are the ones to look at hard, because the advisory says an object creator is enough. Drop logins nobody uses, and treat the rest as reasons to patch soon rather than later.

3. Where the credentials live. For each login role, find where its password is stored: .env files on worker boxes, CI secrets, a shared config repo. A low-privilege password that sits on many machines is a wider door than its privileges suggest.

4. Managed services. In the provider’s console, check the engine version and the maintenance window. If it still shows an older minor after the provider ships the fix, schedule the update yourself.

Applying the update

For 15 to 18 this is a minor update. PostgreSQL says you don’t need to dump and reload or use pg_upgrade: stop the server, update the binaries, start it again. Distro packages carry their own version strings, so check the package once it’s in place and confirm with SELECT version();.

Read the Updating section before you call it done, because a few cases want extra work:

• GIN indexes that may be affected: REINDEX INDEX your_index_name;
• pg_trgm: reindex GiST indexes that use gist_trgm_ops. Fuzzy matching on scraped titles and names is a common reason to have these.
• B-tree indexes on bpchar columns declared without a length. Columns declared as char(n) aren’t affected.
• missing chunk number errors: REINDEX TABLE your_table_name;
• Incremental backups: take a new full backup after updating and base later incrementals on it.
• Partitioned tables: the announcement gives a query against pg_constraint to find not-null constraints that need fixing.

If you skipped earlier update releases, the announcement notes you may need their post-update steps as well.

Don’t forget the client side. pg_dump, pg_restore, reindexdb, vacuumdb and pg_basebackup each have their own CVE in this release, including a pg_restore bug that executes arbitrary code from a crafted non-plain archive. Update the tools on the machines that run your backups and migrations, not just the server.

Plan off PostgreSQL 14

The announcement is plain about it: “PostgreSQL 14 is now end-of-life and will no longer receive security and bug fixes.” It suggests production users plan an upgrade to a supported version.

So do two things. Patch to 14.25 now, since it carries this release’s fixes and nothing after it will. Then schedule the major upgrade. Moving between major versions means pg_upgrade or pg_dump and pg_restore, unlike the minor update above, so test it on a copy first. 15 is supported until November 2027, while 18 runs to November 2030, which makes it the less rushed choice if you’re doing the work anyway. If you’re tempted by 19, the RC notes say its GA is planned for 19 November and that some indexes may need reindexing after pg_upgrade.

What to do now

List every PostgreSQL you run, including the managed ones and the forgotten staging copy, and run SELECT version(); on each. Patch to 18.7, 17.12, 16.16, 15.20 or 14.25, update the client tools, and do the reindex steps that apply to you. Then go through the login roles, because with CVE-2026-6460 a forgotten worker account counts. Got Apache in front of it too? Check that box as well, the Apache HTTP/2 fix came out on the 11th. If you’re also reworking where scraped data lands, the scraping architecture guide covers how to split raw and parsed storage.