If your custom software keeps its data in PostgreSQL, there's an update waiting for you. Yesterday (12 November) the PostgreSQL project released 18.7, 17.12, 16.16, 15.20 and 14.25, and between them they fix 52 security vulnerabilities and over 140 other bugs. That's not a typo. Fifty-two.
It's also the last update PostgreSQL 14 will ever get. In the project's own words, "This is the final release of PostgreSQL 14."
So there are really two jobs here. Patch everything this week, and work out a plan for anything still on 14.
What's in the release
I've stuck to what the PostgreSQL project has published, because a list of 52 CVEs is long enough without anyone adding guesses to it.
- Fixed versions: 18.7, 17.12, 16.16, 15.20 and 14.25. If you're on any supported version, those are the numbers you want to see.
- How serious: most of the 52 are scored 8.8 on CVSS, and many have descriptions ending in "executes arbitrary code". That means getting the database server to run code it shouldn't.
- The headline one: CVE-2026-6460, a type confusion bug in the core server that can execute arbitrary code, scored 8.8.
- Tools as well as the server: there are fixes for pg_dump, pg_restore, reindexdb and vacuumdb, including SQL injection and command injection issues. These are the tools your backup scripts probably use.
- Exploitation: the announcement doesn't say anything about these being used in attacks.
Why "needs a login" isn't as comforting as it sounds
The CVSS vector for CVE-2026-6460 says it needs low privileges. In plain terms, the attacker has to be able to connect to the database and run SQL as some ordinary user. That rules out a random person on the internet poking at port 5432, assuming you haven't left it open to the world (worth checking while you're in there).
Here's the catch for anyone running a web app. Your app is a logged-in database user. It connects with a username and password and runs SQL all day long. If someone finds a SQL injection hole in the app, or gets hold of the connection details from a leaked config file, they're now that user. With bugs like these unpatched, being an ordinary database user can turn into running code on the database server itself.
So I'd treat database patches as seriously as web server patches, even though the database sits further back.
How to check and update
First, find out what you're running. On the server, psql --version tells you the client version, and on Debian or Ubuntu pg_lsclusters lists each cluster with its version and status. Or connect and run SELECT version();.
The good news is that this is a minor release. The project says you don't need to dump and reload or use pg_upgrade. You can "simply stop PostgreSQL and update its binaries". On a packaged install that's your normal package update and a restart, so plan a few minutes of downtime and tell anyone who needs to know.
Then read the post-update notes, because this release has a few:
- If you use pg_trgm (common for fuzzy search), reindex any GiST indexes using the gist_trgm_ops operator class.
- If you have B-tree indexes on bpchar columns declared without a length, reindex them. Columns declared as char(n) aren't affected.
- If you use incremental backups, take a new full backup after updating and base future incrementals on that.
- If you suspect GIN index corruption, see "missing chunk number" errors or use partitioned tables, the announcement tells you what to check.
And if you've skipped earlier updates, the project points out you may need the post-update steps from those releases too. That's the quiet cost of falling behind: the catch-up job gets longer each time.
If your database is managed, on Amazon RDS for example, you don't install anything yourself, but it's still worth checking which minor version you're on and whether automatic minor upgrades are switched on. Don't assume.
The bigger job: PostgreSQL 14
PostgreSQL 14 is now end of life. It got this last batch of fixes, and from here on the project won't fix new security bugs in it. With 52 CVEs in one release, I wouldn't bet on the next batch being empty.
One thing to watch: Ubuntu 22.04's default PostgreSQL package is version 14. Ubuntu 24.04 ships 16. So if you've got a server that was built a few years ago and nobody has touched the database since, there's a decent chance it's on 14 without anyone having chosen that. Check with your distribution how it'll handle fixes from now on, but either way, 14 is on borrowed time.
A major upgrade is a bigger job than a patch. You'll use pg_upgrade or a dump and restore, and you should test it on a copy first. Your application needs testing too, because it's the one that has to keep working afterwards. Extensions, odd data types and old queries are where the surprises tend to hide. I went through what to check in more detail in my post on PostgreSQL 14 reaching end of life.
Before you do any of it, make sure you've got a backup you've actually restored from. Not one you think works. Try getting something back before you need to.
If nobody owns the database
This is the bit that worries me most. Lots of bespoke software gets built, launched and then left. The app works, so nobody looks at the server, and the database quietly gets older underneath it. Then a release like this one comes out and there's nobody whose job it is to notice.
If that sounds familiar, there are a couple of ways we can help. Our code audit (£250 + VAT) covers one app, its server and its database: how the code is put together, who can see what they shouldn't, whether it's patched, and whether a backup would actually bring it back. If you'd rather someone just kept on top of it, Look after it (from £355 a month + VAT) keeps your software's frameworks and libraries up to date and its hosting running and watched. For the server side on its own, I also do server retainers. And we take on existing software that someone else built.
In the meantime, run that version check today. It takes thirty seconds, and you'll know whether you've got a five-minute patch or a proper upgrade project on your hands. If it's the second one and you'd like a hand, get in touch.
Cheers, Rob
