PostgreSQLs Update mit 52 CVEs ist ein Upgrade-Projekt, kein Patch. Und PostgreSQL 14 ist am Ende

Am 12. November hat das PostgreSQL-Projekt die Minor-Releases 18.7, 17.12, 16.16, 15.20 und 14.25 veröffentlicht, dazu einen zweiten Release Candidate für PostgreSQL 19. Zusammen schließen sie 52 CVEs und beheben mehr als 140 Bugs. Für ein Point Release ist das eine Menge, und dieses verlangt mehr von Ihnen als das übliche „Paket aktualisieren, neu starten, Feierabend“.

Zwei Dinge machen diese Runde besonders. PostgreSQL 14.25 ist das letzte Release des Zweigs 14, damit ist 14 End-of-Life und erhält keine Sicherheits- oder Bugfixes mehr. Und der Fix für den Hauptbug, CVE-2026-6460, ändert, wie der Server mit Extensions kommuniziert. Aus einem Routine-Patch wird so ein koordiniertes Upgrade von Server und Extensions, gefolgt von etwas Reindexing und einem Backup-Reset.

Was CVE-2026-6460 ist

Es handelt sich um eine Type Confusion, die nach ALTER ... SET DATA TYPE ausgelöst werden kann. Ein Benutzer mit der Berechtigung, Objekte anzulegen, kann damit beliebigen Code als das Betriebssystemkonto ausführen, unter dem die Datenbank läuft. Das offizielle Advisory bewertet die Lücke mit 8,8 nach CVSS 3.1: über das Netzwerk erreichbar, geringe Komplexität, niedrige Privilegien, keine Benutzerinteraktion. Betroffen sind alle Versionen vor 18.7, 17.12, 16.16, 15.20 und 14.25.

„Braucht Rechte zum Anlegen von Objekten“ klingt nach einer beruhigenden Voraussetzung. Ich halte sie nicht dafür. In unseren Pentests finden wir am häufigsten eine Anwendungsrolle, der ihr eigenes Schema gehört. Migrationen laufen mit dieser Rolle, die App verbindet sich mit dieser Rolle, und mit welchem Konto auch immer eine SQL-Injection landet, kann in der Regel Tabellen anlegen. Genau dieses Angreiferprofil braucht die CVE.

Der mögliche Schaden ist das, was mich daran stört. Bei selbst gehostetem Postgres kann der OS-Benutzer des Servers das gesamte Datenverzeichnis lesen, also jede Datenbank im Cluster, nicht nur die der kompromittierten App. In Docker-Setups sieht er oft zusätzlich alle Secrets, die in den Container gemountet wurden.

Der Haken bei den Extensions

Der Fix berührt Interna, gegen die Extensions kompiliert werden. DatumGetHeapTupleHeader() wurde von einem Makro zu einer echten Server-Funktion, und heap_getattr() ruft nun heap_datum_check() auf. Deshalb haben die PGDG-Packager alle Extensions neu gebaut, und zwar gegen die neuen Minor-Releases. Ihr Rat: Server und Extensions gemeinsam aktualisieren.

Aus unserer PHP- und Docker-Arbeit wissen wir, wo es schiefgeht: Jemand pinnt das Postgres-Basisimage auf einen neuen Tag, aber die Extension-Pakete werden in einem separaten Layer mit eigenen gepinnten Versionen installiert, oder umgekehrt. Aktualisieren Sie beides in derselben Änderung, bauen Sie das Image neu und testen Sie es, bevor es in Produktion geht. Wenn Sie Extensions selbst aus dem Quellcode bauen, kompilieren Sie sie gegen die neuen Header neu. Ein Minor Release verlangt das normalerweise nicht.

Die Arbeit nach dem Upgrade

Die Release-Ankündigung nennt mehrere Bugfixes, die erst helfen, wenn Sie Dinge neu aufbauen:

• GIN-Indizes, bei denen Sie Korruption vermuten, brauchen ein Reindex.
• pg_trgm-GiST-Indizes mit gist_trgm_ops brauchen ein Reindex.
• B-Tree-Indizes auf bpchar-Spalten, die ohne Längenangabe deklariert wurden, brauchen ein Reindex.
• Jede Tabelle, die „missing chunk number“-Fehler wirft, braucht REINDEX TABLE.
• Wenn Sie inkrementelle Backups nutzen, erstellen Sie ein neues Vollbackup und basieren Sie alle weiteren Inkremente darauf. Mehrere der behobenen Bugs konnten korrupte Inkremente erzeugen.

So finden Sie die Trigram-Indizes schnell:

SELECT i.indexrelid::regclass AS index_name
FROM pg_index i
JOIN pg_opclass o ON o.oid = ANY (i.indclass::oid[])
WHERE o.opcname = 'gist_trgm_ops';

Wenn Sie nur einen Punkt der Liste erledigen, dann das Backup. Ein korruptes Inkrement zeigt keine Anzeichen von Problemen, bis Sie davon wiederherstellen, und das ist der schlechteste Zeitpunkt, es zu erfahren. Reindexing großer Tabellen kostet Zeit und I/O, planen Sie es daher in ein ruhiges Zeitfenster. Hängen Sie es nicht einfach ans Ende des Patch-Laufs.

Auch die Client-Tools aktualisieren

Nicht nur der Server braucht Patches. CVE-2026-116318 ist eine SQL-Injection in pg_dump über Namen von Not-null-Constraints, und CVE-2026-116330 betrifft das Restore-Skript im Tar-Format, das psql-Command-Injection nicht verhindert. Die Release-Mitteilung nennt außerdem CVE-2026-116314, beliebige Codeausführung in pg_restore (CVSS 8,8), und CVE-2026-116313, bei der vacuumdb --missing-stats-only einem Datenbankbesitzer erlaubt, Code als der Benutzer auszuführen, der vacuumdb startet (CVSS 7,2). Wenn andere Objekte in Ihren Datenbanken anlegen und benennen können, aktualisieren Sie die Client-Tools zusammen mit dem Server.

Überlegen Sie, wo diese Tools tatsächlich laufen: in Backup-Cron-Containern, auf CI-Runnern, auf dem Ops-Laptop, den jemand für Ad-hoc-Restores nutzt. Wenn wir Cloud-native-Apps für Enterprise-Kunden bauen, ist der Backup-Sidecar fast immer das am meisten vernachlässigte Image im Stack, gepinnt auf die Client-Version, die aktuell war, als jemand den Cronjob geschrieben hat. Und er läuft mit weitreichenden Zugangsdaten.

Prüfen Sie bei einem Managed Service, was Ihr Anbieter ausgerollt hat. Auch wenn der Server für Sie betreut wird, können Client-Tools, Reindexing und Backup-Kette weiter Ihre Aufgabe sein.

PostgreSQL 14 ist am Ende

14.25 ist der letzte Patch für den Zweig 14. Wenn Sie noch darauf laufen, spielen Sie 14.25 jetzt ein und beginnen Sie noch dieses Quartal mit der Planung des Major-Upgrades. Schieben Sie es nicht auf nächstes Jahr. Für unsere Schweizer Enterprise-Kunden mit Compliance-Anforderungen ist eine nicht mehr unterstützte Datenbankversion für sich genommen ein Audit-Befund, egal ob jemand etwas ausgenutzt hat.

Am häufigsten sehen wir 14 hinter mobilen Apps. In unseren nativen iOS- und Android-Projekten für Healthcare- und IoT-Kunden erscheinen die Apps alle paar Wochen neu, während die API-Datenbank vor Jahren einmal aufgesetzt wurde und seither niemand mehr angefasst hat, weil sie „einfach läuft“. Wenn das Ihr Backend beschreibt, ist dies der Anstoß, es zu ändern. Zielen Sie auf 18, den neuesten stabilen Zweig. 19 ist noch ein Release Candidate und gehört in eine Staging-Umgebung, nicht hinter Ihre Nutzer. Solche Migrationen haben wir im Rahmen unserer Entwicklungsarbeit schon durchgeführt, und das Datenbank-Upgrade selbst ist selten das Schwierige. Schwierig ist es, alle Services zu finden, die sich damit verbinden.

Was wir diese Woche tun würden

1. Alle Postgres-Instanzen samt Version inventarisieren, auch die vergessenen in Staging und CI.
2. Server und Extensions gemeinsam auf 18.7, 17.12, 16.16, 15.20 oder 14.25 aktualisieren.
3. pg_dump, pg_restore und vacuumdb überall aktualisieren, wo sie laufen.
4. Ein frisches Vollbackup erstellen, wenn Sie Inkremente nutzen.
5. Die betroffenen GIN-, Trigram-GiST- und bpchar-B-Tree-Indizes neu aufbauen.
6. Prüfen, welche Rollen Objekte anlegen dürfen, und dieses Recht jeder App-Rolle entziehen, die es nicht braucht.
7. Ein Datum für den Abschied von PostgreSQL 14 in den Kalender eintragen.

Wenn Ihnen ein PostgreSQL-14-Cluster bekannt vorkommt, für das niemand die Verantwortung übernehmen will, sprechen Sie uns an.