PostgreSQL 18.7, 17.12 und Co.: 52 Lücken geschlossen, PostgreSQL 14 am Ende

Die PostgreSQL Global Development Group hat am 12. November 2026 die Versionen 18.7, 17.12, 16.16, 15.20 und 14.25 sowie den zweiten Release Candidate von PostgreSQL 19 veröffentlicht. Die Updates schließen 52 Sicherheitslücken und beheben mehr als 140 weitere Fehler. Für PostgreSQL 14 ist es die letzte Version, die Reihe hat damit ihr Supportende erreicht.

Betroffen sind alle Betreiber unterstützter PostgreSQL-Versionen, ob nativ installiert oder im Container. Das Update ist ein Minor-Release ohne Dump und Restore, verlangt nach Angaben des Projekts aber je nach Nutzung Nacharbeiten wie ein REINDEX oder ein neues Vollbackup. Admins sollten es zeitnah im nächsten Wartungsfenster einplanen und die Nacharbeiten gleich mit vorsehen.

Was ist passiert?

Die Ankündigung listet 52 CVE-Nummern mit CVSS-3.1-Werten auf. 32 davon sind mit 8,8 bewertet, meist als Codeausführung durch Typverwechslungen, Use-after-free-Fehler oder Pufferüberläufe, darunter mehrere Fehler in PL/Perl und PL/Tcl. Hinzu kommen SQL-Injection-Lücken in Werkzeugen wie pg_dump und reindexdb sowie Umgehungen von Zeilensicherheitsregeln. Phoronix ordnet die Menge in die Welle KI-gestützter Fehlerberichte ein, die das Projekt seit Wochen belastet und bereits PostgreSQL 19 verzögert hat.

Unter den mehr als 140 behobenen Fehlern sind mehrere, die Daten betreffen: Fehler in GIN-Indizes, die zu fehlenden oder falschen Treffern führen konnten, Probleme mit inkrementellen Backups, die beschädigte Sicherungen erzeugen konnten, und ein Fehler beim Export von Snapshots auf Standby-Servern, der bei parallelem pg_dump Dump und Standby beschädigen konnte.

Wer ist betroffen?

Betroffen sind alle unterstützten Hauptversionen von 14 bis 18. Die meisten der schweren Lücken setzen ein angemeldetes Datenbankkonto mit einfachen Rechten voraus. Ohne Anmeldung kommen laut CVSS-Vektoren nur fünf Lücken aus, und auch die haben meist Vorbedingungen: CVE-2026-116314 und CVE-2026-116330 betreffen das Einspielen manipulierter Dumps mit pg_restore beziehungsweise psql, CVE-2026-120145 setzt laut Projekt einen kompromittierten Publisher bei der logischen Replikation voraus und trifft nur Abonnements, die einem Superuser gehören. Direkt aus dem Netz ohne Vorbedingung lässt sich laut Projekt nur CVE-2026-116322 auslösen: Ein nicht angemeldeter Client kann einen Neustart des Servers erzwingen, betroffen ist nur PostgreSQL 18 (CVSS 5,3). Wer Datenbanken an viele Anwendungen oder Kunden mit eigenen Konten vergibt oder fremde Dumps einspielt, ist stärker gefährdet als ein Server mit einer einzigen Anwendung.

Wie kritisch ist das?

Hinweise auf Angriffe nennt die Ankündigung nicht. Die Masse der mit 8,8 bewerteten Lücken erlaubt nach den Beschreibungen Codeausführung, sobald ein Angreifer SQL mit einem regulären Konto absetzen kann, etwa über eine kompromittierte Anwendung oder gestohlene Zugangsdaten. Das macht das Update für Mehrmandanten-Umgebungen und Hosting-Angebote dringlicher als für isolierte Einzelinstanzen. Die Datenfehler bei GIN-Indizes und inkrementellen Backups sind unabhängig von Angriffen ein Grund, nicht lange zu warten.

Was sollten Admins jetzt tun?

• Inventar: Hauptversion und Stand prüfen, etwa mit SELECT version();, auch in Containern und eingebetteten Installationen.
• Update: Auf 18.7, 17.12, 16.16, 15.20 oder 14.25 aktualisieren. Laut Projekt reicht es, PostgreSQL zu stoppen und die Binärdateien zu ersetzen.
• PostgreSQL 14: Den Umstieg auf eine unterstützte Hauptversion planen, 14.25 ist das letzte Update.
• GIN-Indizes: Bei Verdacht auf fehlerhafte Treffer neu aufbauen.
• pg_trgm: Alle GiST-Indizes mit der Operatorklasse gist_trgm_ops neu aufbauen, das empfiehlt das Projekt ohne Einschränkung.
• B-Tree-Indizes auf Spalten vom Typ bpchar ohne Längenangabe nach dem Update neu aufbauen, char(n) ist laut Projekt nicht betroffen.
• Bei Fehlermeldungen „missing chunk number“ die betroffene Tabelle mit REINDEX TABLE neu indizieren.
• Inkrementelle Backups: Nach dem Update ein neues Vollbackup als Basis anlegen.
• Partitionierte Tabellen: Die in der Ankündigung genannte Abfrage nach NOT NULL NO INHERIT-Einschränkungen ausführen und Treffer bereinigen.
• Übersprungene Updates: Wer frühere Minor-Releases ausgelassen hat, muss laut Projekt eventuell deren Nacharbeiten nachholen, die Versionshinweise der älteren Releases nennen sie.

Einordnung für Unternehmen

PostgreSQL läuft in vielen Umgebungen als Datenbank hinter Fachanwendungen oder selbst gehosteten Diensten, oft als Container. Dort kommt das Update erst an, wenn jemand das Image anhebt oder neu zieht und den Container neu erstellt. Die Datenfehler machen dieses Update wichtiger als ein übliches Minor-Release: Wer inkrementelle Backups nutzt, sollte sich nach dem Update nicht mehr auf die alte Sicherungskette verlassen. PostgreSQL 19 soll nach Plan am 19. November 2026 erscheinen.

Passende Anleitungen auf S-EDV

• PostgreSQL nativ installieren und absichern: PGDG-APT-Repository, systemd und pg_hba.conf (Ubuntu/Debian)
• PostgreSQL pg_dump und pg_restore: Anleitung für Backup und Migration per Kommandozeile
• PostgreSQL 19 verspätet sich: KI-Fehlerberichte bremsen Release

Quellen

• PostgreSQL: Ankündigung der Updates vom 12. November 2026
• PostgreSQL: Versionshinweise zu 18.7 (Quelltext-Spiegel)
• Phoronix: Bericht zu den 52 Lücken