PostgreSQL veröffentlicht Notfall-Patch für 11 CVEs in allen Versionen

Jede langjährig betriebene Datenbank ähnelt einem alten Reihenhaus in Dublin. Die Vorderzimmer werden jedes Jahr neu gestrichen, aber die Leitungen hinter den Sockelleisten stammen noch aus den Siebzigern, und niemand will wirklich nachsehen. Am 14. Mai hoben die PostgreSQL-Maintainer die Dielen unter dem contrib-Modul refint an – und fanden etwas Unangenehmes.

Das Notfall-Release betrifft alle unterstützten Hauptversionen gleichzeitig. Allein das zeigt, wie gravierend der Fund war.

Was passiert ist

PostgreSQL veröffentlichte am 14. Mai 2026 Notfall-Sicherheitsupdates und schloss damit die Versionen 18.4, 17.10, 16.14, 15.18 und 14.23. Wie Cyber Press berichtete, umfasst das koordinierte Release 11 CVEs mit Stack-Buffer-Overflows, SQL-Injection, Speicheroffenlegung und Denial-of-Service-Schwachstellen – plus über 60 weitere Fehlerbehebungen.

Die kritischste Schwachstelle ist CVE-2026-6637 mit einem CVSS-Wert von 8.8. Sie steckt im contrib-Modul refint, einem alten Bestandteil, der mit Postgres ausgeliefert wird und Trigger für referenzielle Integrität bereitstellt. Ein entfernter, nicht privilegierter Datenbankbenutzer kann präparierte Eingaben liefern, um einen Stack-basierten Buffer Overflow auszulösen und beliebigen Code als OS-Benutzer auszuführen, unter dem der Datenbankserver läuft. Das ist die schlimmste Art von Datenbankfehler: Er bleibt nicht auf die Datenbank beschränkt, sondern öffnet den Weg auf den Host.

Derselbe CVE enthält einen sekundären Angriffsvektor, der SQL-Injection ermöglicht, wenn eine Anwendung eine benutzerkontrollierte Spalte als primären refint-Cascade-Schlüssel exponiert. Selbst wenn refint gegen den Overflow gehärtet ist, kann ein nachlässiges Schema-Design einem Angreifer bei Primary-Key-Updates beliebige SQL-Befehle ermöglichen.

Die weiteren schwerwiegenden Lücken: CVE-2026-6473, ein Integer-Überlauf in mehreren Serverfunktionen, der zu zu kleinen Speicherzuweisungen und Out-of-Bounds-Schreibzugriffen führt; CVE-2026-6477, ein gets()-artiger Fehler in den Large-Object-Funktionen von libpq, der einem bösartigen Server-Superuser ermöglicht, den Stack-Speicher in psql und pg_dump zu überschreiben; sowie CVE-2026-6475, ein Symlink-folgender Pfad-Traversal in pg_basebackup und pg_rewind, mit dem Dateien wie /var/lib/postgres/.bashrc überschrieben werden können. Alle vier betreffen die Versionen 14 bis 18.

Hinzu kommt CVE-2026-6478, ein MD5-Timing-Kanal, der nur Legacy-Deployments betrifft, die nach einem Upgrade von PostgreSQL 13 oder älter noch immer md5-Einträge in pg_hba.conf verwenden.

Technische Analyse

Schauen wir uns die Details an, denn der refint-Bug ist aus technischer Sicht wirklich interessant. Das refint-Modul ist älter als Postgres' moderne Foreign-Key-Implementierung. Es ist ein contrib-Modul, das seit über zwei Jahrzehnten existiert und von Anwendungen genutzt wird, die Trigger für Cascade-Referenzintegrität eingebunden haben. Die meisten Teams haben vergessen, dass es überhaupt existiert. Angreifer offenbar nicht.

Ein Stack-basierter Buffer Overflow in einer Datenbank-Engine ist ein besonders schlimmes Problem. Der PostgreSQL-Backend-Prozess läuft als OS-Benutzer postgres, dem typischerweise das Datenverzeichnis, die Konfigurationsdateien und das WAL gehören. Beliebige Codeausführung auf dieser Ebene ist kein bloßer Datenbankeinbruch – es ist der komplette Node. Von dort aus lassen sich alle Konfigurationsgeheimnisse auf dem Datenträger auslesen, die Replikation manipulieren, in authorized_keys schreiben und beliebige Auswege finden.

CVE-2026-6477 dreht das Bedrohungsmodell um und ist die Schwachstelle, die jeden, der gemeinsam genutzte oder mandantenfähige Postgres-Infrastruktur betreibt, aufhorchen lassen sollte. Der Fehler ermöglicht es einem bösartigen Server-Superuser, den Stack-Speicher im Client-Tool zu überschreiben. Wer schon einmal pg_dump gegen eine Datenbank ausgeführt hat, die er nicht selbst bereitgestellt hat, kennt die implizite Vertrauensannahme in Client-Tools: Man geht davon aus, dass der Server vertrauenswürdig ist. Diese Annahme ist nun hinfällig. lo_read() wird sowohl von psql als auch von pg_dump aufgerufen – das nächtliche Backup-Skript ist damit eine potenzielle Angriffsfläche gegen den Backup-Host.

CVE-2026-6475 folgt demselben Muster aus einem anderen Blickwinkel. Symlink-Verfolgung bei pg_basebackup-Läufen im Plain-Format oder bei pg_rewind-Failover-Operationen ermöglicht es einem Origin-Superuser, OS-Dateien auf dem Replikat zu überschreiben. Wer die .bashrc des postgres-OS-Kontos übernimmt, kontrolliert das Replikat, sobald sich das nächste Mal jemand einloggt.

Die gute Nachricht laut dem PostgreSQL-Advisory: Es ist kein Datenbank-Dump, kein Reload und kein pg_upgrade erforderlich. Es genügt ein Binär-Austausch und ein Dienstneustart – der langweilige Teil, nicht der, bei dem alles zusammenbricht.

Wer besonders betroffen ist

Jeder, der mandantenfähige Postgres-Infrastruktur betreibt – in der Praxis also die meisten Fintech-, iGaming- und Ad-Tech-Plattformen ab einer bestimmten Größe. Wer ein Managed-Database-Produkt betreibt oder logische Replikation über Vertrauensgrenzen zwischen Geschäftsbereichen einsetzt, für den ist CVE-2026-6637 ein Drei-Alarm-Brand. Ein Benutzer mit geringen Rechten in einer beliebigen Mandantendatenbank mit konfigurierten refint-Triggern kann prinzipiell auf den Host ausbrechen.

Zahlungsplattformen, die noch auf Legacy-refint-Triggern aus einer Postgres-9.x- oder 10-Migration basieren, sind gleich zweifach exponiert: durch den Overflow und durch den SQL-Injection-Vektor über den Cascade-Primary-Key. In vielen Payment-Ledgern ist der Cascade mit anwendungsseitigen Bezeichnern verknüpft – genau das Muster, das dieser Bug ausnutzt.

iGaming-Betreiber, die regionsübergreifende Read-Replicas über pg_basebackup betreiben, müssen CVE-2026-6475 genau unter die Lupe nehmen. Ein Failover während eines regionalen Vorfalls ist der denkbar schlechteste Moment, um festzustellen, dass das OS-Konto des Replikats vor sechs Stunden kompromittiert wurde.

Der MD5-Timing-Kanal ist nur relevant, wenn noch md5-Einträge in pg_hba.conf vorhanden sind. Der Standard in allen unterstützten Releases ist scram-sha-256, das nicht betroffen ist. Aber Legacy-Fintech-Deployments, die schrittweise von Version 13 oder älter migriert wurden, tragen fast immer md5-Einträge mit sich, weil niemand einen Passwort-Reset für alle Service-Accounts erzwingen wollte. Diese technische Schuld hat jetzt einen CVE erhalten.

Hinzu kommt das Kalender-Problem: PostgreSQL 14 erreicht am 12. November 2026 sein End-of-Life. Danach gibt es keine weiteren Sicherheitsfixes. Wer noch auf Version 14 ist, hat etwa sechs Monate, um ein Major-Version-Upgrade auf 16 oder 17 zu planen. Dieser Patch sollte als letzter 14.x-Sicherheitspatch behandelt werden.

Maßnahmenplan für Engineering-Teams

Diese Woche, in Prioritätsreihenfolge:

Zuerst patchen, dann prüfen. 18.4, 17.10, 16.14, 15.18 oder 14.23 auf jeden Cluster einspielen. Binär-Austausch und Dienstneustart, kein Dump-und-Reload erforderlich. Für Debian/Ubuntu: sudo apt update && sudo apt install postgresql-18. Für RHEL/Fedora: sudo dnf update postgresql. Für Homebrew auf Entwickler-Rechnern: brew upgrade postgresql@18. Managed-Cloud-Datenbanken folgen dem Wartungsfenster des Anbieters, aber ein manuelles Minor-Version-Upgrade lässt sich in der Regel über die Konsole anstoßen, statt zu warten.

Nach dem Patchen die Schemata nach refint-Trigger-Verwendung durchsuchen. Bei Treffern prüfen, welche Spalten die Cascade-Primary-Keys speisen und ob davon welche benutzerkontrolliert sind. Das ist der sekundäre SQL-Injection-Vektor.

pg_hba.conf auf jedem Host überprüfen. Jede Zeile, die noch md5 verwendet, muss auf scram-sha-256 migriert werden. Das bedeutet eine Passwortrotation für betroffene Rollen. Trotzdem durchführen.

Die Backup- und Failover-Infrastruktur auf die clientseitigen Risiken hin überprüfen. Wer pg_dump oder pg_basebackup gegen Datenbanken einer anderen Vertrauensgrenze ausführt – einschließlich Dev-gegen-Prod-Debugging-Sitzungen – sollte den Client-Host bis zum Einspielen des Patches als kompromittiert betrachten.

Wer noch auf Version 14 ist, sollte jetzt eine Kalender-Erinnerung für den Stichtag 12. November setzen und die Upgrade-Planung starten. PostgreSQL 16 oder 17 sind die realistischen Ziele. Dieser Patch markiert den Beginn dieses Migrationsprojekts, nicht das Ende eines Quartals.

Wichtige Erkenntnisse

• Das PostgreSQL-Release vom 14. Mai 2026 schließt 11 CVEs in allen unterstützten Hauptversionen (14 bis 18) sowie über 60 weitere Fehlerbehebungen.
• CVE-2026-6637 (CVSS 8.8) im contrib-Modul refint ermöglicht Remote Code Execution als OS-Benutzer sowie einen sekundären SQL-Injection-Pfad über Cascade-Primary-Keys.
• CVE-2026-6477 und CVE-2026-6475 kehren das Bedrohungsmodell um: Ein bösartiger Server kann Client-Tools und Replikat-Hosts bei regulären pg_dump-, pg_basebackup- oder pg_rewind-Operationen kompromittieren.
• Das Patchen ist ein Binär-Austausch mit Dienstneustart, ohne Dump-und-Reload – es gibt keine Entschuldigung dafür, dies über ein Wartungsfenster hinaus aufzuschieben.
• PostgreSQL 14 erreicht am 12. November 2026 sein End-of-Life. Dieser Patch-Zyklus sollte als Startschuss für eine Migration auf Version 16 oder 17 genutzt werden, nicht nur als Hotfix.

Zurück zum alten Reihenhaus. Die Leitungen wurden diese Woche neu verlegt, der Inspektor hat abgenommen. Aber der Inspektor erinnert auch daran, dass der Mietvertrag für das gesamte Gebäude im November ausläuft. Also: Leitungen patchen – und dann mit dem Einpacken beginnen.