Das PostgreSQL-Projekt hat für alle unterstützten Versionen neue Ausgaben veröffentlicht und dabei 28 Sicherheitslücken auf einmal geschlossen. Das ist die größte Zahl an Schwachstellen, die PostgreSQL je in einer einzigen Freigabe behoben hat. Neun der Lücken tragen die Formulierung „executes arbitrary code“ direkt im Titel, ein Angreifer kann darüber also Schadcode auf dem Datenbankserver ausführen. Wer PostgreSQL im Einsatz hat, sollte zeitnah aktualisieren.

Worum es geht

Betroffen sind die Versionsstränge 14 bis 18. Die abgesicherten Ausgaben tragen die Nummern 18.6, 17.11, 16.15, 15.19 und 14.24. Die Version 18.5 wurde übersprungen und nie ausgeliefert, weil kurz vor der Freigabe eine Regression auffiel. Der Sprung geht daher von 18.4 direkt auf 18.6.

Von den 28 Schwachstellen liegen 17 bei einem CVSS-Wert von 8,0 oder höher, allein 14 exakt bei 8,8. Ein CVSS-Wert von 8,8 gilt als hoch und liegt nur knapp unter der Schwelle zu kritisch. Zusätzlich zu den Sicherheitslücken behebt das Update mehr als 110 gemeldete Fehler.

Das Muster hinter vielen der schweren Lücken ist ähnlich. Ein Integer-Überlauf oder eine fehlende Prüfung führt dazu, dass PostgreSQL zu kleine Speicherbereiche anfordert und dann über deren Grenzen hinausschreibt. Solche Heap- und Stack-Überläufe sind die klassische Grundlage, um eigenen Code einzuschleusen und auszuführen.

Warum das gefährlich ist

Die meisten der schweren Lücken lassen sich von einem Datenbanknutzer mit niedrigen Rechten ausnutzen. Das ist der entscheidende Punkt: Ein Angreifer braucht kein Administratorkonto, ein normaler Datenbankzugang genügt in vielen Fällen, um Code als der Betriebssystem-Nutzer auszuführen, unter dem der PostgreSQL-Dienst läuft. Aus einem eingeschränkten Datenbankkonto wird so eine vollständige Übernahme des Servers.

Betroffen sind dabei keine exotischen Randfunktionen, sondern Bausteine, die in praktisch jeder Installation stecken. Ein Heap-Überlauf sitzt in to_char (CVE-2026-14669), einer im Statistikmodul pg_stat_statements (CVE-2026-14676) und einer im Backup-Werkzeug pg_dump (CVE-2026-19385). Weitere Lücken betreffen die Regexp-Verarbeitung (CVE-2026-14664) sowie die prozeduralen Sprachen plperl und pltcl. Diese Funktionen laufen oft im Minutentakt, etwa wenn Monitoring- oder Backup-Skripte darauf zugreifen.

Eine besondere Rolle spielen die Werkzeuge rund um Sicherung und Wiederherstellung. Über die Schwachstelle CVE-2026-18408 (CVSS 8,8) kann der Superuser eines pg_dump-Ursprungsservers im Zuge einer Wiederherstellung Schadcode im psql-Client ausführen. Das trifft vor allem Umgebungen, in denen Dumps aus fremden oder nicht vollständig vertrauenswürdigen Quellen eingespielt werden. Wer Backups nur aus eigenen, kontrollierten Systemen zurückspielt, ist hier weniger exponiert, sollte die Lücke aber nicht ignorieren.

Erwähnenswert ist außerdem CVE-2026-14663 im Verschlüsselungsmodul pgcrypto. Wenn OpenSSL eine angeforderte Chiffre ablehnt, etwa im FIPS-Modus oder bei veralteten Algorithmen wie Blowfish, 3DES oder CAST5, bemerkte pgcrypto den Fehlschlag bisher nicht und schrieb die Daten faktisch im Klartext weg. Die vermeintliche Verschlüsselung war damit trivial zu brechen. Wer pgcrypto mit solchen Ciphern einsetzt, sollte prüfen, ob Daten betroffen sind.

Zum Zeitpunkt der Veröffentlichung gibt es keine Berichte, dass Angreifer die Lücken bereits aktiv ausnutzen. Für viele der Schwachstellen liegen mit den öffentlichen Commit-Beschreibungen aber genug Details vor, um daraus einen Exploit zu bauen. Der zeitliche Vorsprung durch schnelles Patchen ist deshalb real.

Der Sonderfall PostgreSQL 14

Das Projekt weist erneut darauf hin, dass der Support für PostgreSQL 14 am 12. November 2026 endet. Ab diesem Zeitpunkt gibt es keine Sicherheitsupdates mehr, gefundene Lücken bleiben dann dauerhaft offen. Alle 28 Lücken dieser Runde betreffen auch Version 14 und wurden in 14.24 behoben, dem vorletzten regulären Update für diesen Zweig.

Die Zahlen aus dem laufenden Jahr machen das Problem greifbar. Ein großer Teil der 2026 gemeldeten Schwachstellen betraf PostgreSQL 14, und die Fundrate steigt eher, als dass sie sinkt. Eine Installation, die nach dem letzten Update auf Version 14 eingefroren bleibt, sammelt binnen weniger Monate ein wachsendes Bündel bekannter, dokumentierter und ungepatchter Lücken an. Wer noch produktiv auf 14 läuft, sollte die Migration auf eine unterstützte Version (15, 16, 17 oder 18) jetzt planen und Anwendungen frühzeitig auf Kompatibilität testen.

Es reicht nicht, nur die Binaries auszutauschen und den Dienst neu zu starten. Drei Punkte erledigt der Paketmanager nicht automatisch, sie verlangen nach dem Update Handarbeit, sonst bleiben Indizes und Statistiken fehlerhaft.