PostgreSQL schließt 52 Lücken, darunter 22 Jahre alten Typfehler mit Codeausführung

Angriffe über die Lücke hat das PostgreSQL-Projekt bisher nicht gemeldet. Auch die CISA stuft die Ausnutzung im CVE-Eintrag als „keine“ ein.

Der Fehler betrifft zusammengesetzte Typen (Composite Types). Sie bestehen aus benannten Feldern, von denen jedes einen eigenen Datentyp hat. Der Typ eines Feldes lässt sich ändern, während an anderen Stellen im Server noch ältere Werte dieses Typs vorgehalten werden. In diesem Fall kann der Server einen alten Wert so lesen, als hätte er bereits den neuen Typ. Laut den Release Notes des Projekts führt der Fix Versionsprüfungen ein, mit denen der Server Werte erkennt, die nicht mehr zu ihrem Typ passen.

Der Sicherheitsforscher Mehmet Ince hat in dieser Woche eine technische Analyse mit einem funktionierenden Exploit veröffentlicht, den er auf PostgreSQL 18.6 vorführt. Dafür bereitet er eine Abfrage vor, die einen Wert enthält, ändert den Typ eines Feldes dieses Wertes und führt die Abfrage anschließend aus. Seine Analyse enthält das SQL, mit dem sich ein ungepatchter Server auf diese Weise zum Absturz bringen lässt, sowie einen zweiten Schritt, über den Speicheradressen preisgegeben werden. Das SQL für den letzten Schritt, mit dem der Server einen Befehl ausführt, veröffentlicht er nicht. Nach eigenen Angaben konnte Ince den Absturz „mit der Login-Rolle mit den geringsten Rechten auslösen“.

Die Sicherheitsmitteilung des Projekts beschreibt den Angreifer lediglich als jemanden, der Objekte anlegen kann, und nennt keine konkreten Rechte. Red Hat liefert PostgreSQL-Pakete aus und schreibt in seiner CVE-Bewertung, ein Angreifer benötige ein Datenbank-Login mit der Berechtigung, Objekte anzulegen oder zu ändern. Ob ein Konto mit Standardrechten über den Absturz hinaus auch Code ausführen kann, geht aus keiner dieser Angaben hervor.

Ince führt den Ursprung des Fehlers auf den 5. Mai 2004 zurück. An diesem Tag erhielt PostgreSQL die Möglichkeit, den Typ einer Spalte zu ändern. Seine Technik zur Codeausführung stützt sich auf eine spätere Änderung vom 14. Mai 2015. Im August hat er den Exploit für verwaltete PostgreSQL-Dienste angepasst und Proof-of-Concepts vertraulich an deren Sicherheitsteams übergeben. Darunter waren AWS (Aurora und RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks und Ubicloud. Wie weit die einzelnen Dienste inzwischen gepatcht sind, gibt er nicht an. Das Projekt nennt für CVE-2026-6460 mehr als ein Dutzend Melder, darunter Ince. Ihm werden außerdem fünf weitere Lücken in diesem Release zugeschrieben.

32 der 52 Lücken bewertet das Projekt mit 8.8, dem höchsten Wert in diesem Release. Gemessen an den Bewertungen im Schwachstellenverzeichnis des Projekts gibt es nur eine Serverlücke, die weder ein Login noch eine Aktion eines Nutzers voraussetzt: CVE-2026-116322. Über sie kann ein nicht authentifizierter Client einen Neustart von PostgreSQL-18-Servern auslösen. Mehrere weitere Korrekturen betreffen Client-Werkzeuge. So kann ein präpariertes Archiv pg_restore dazu bringen, Code mit den Rechten des aufrufenden Nutzers auszuführen. Ein kompromittierter Quellserver kann psql über das Wiederherstellungsskript in der tar-Ausgabe von pg_dump Code ausführen lassen.

Für Administratoren ergeben sich daraus folgende Schritte:

• Den Server passend zur Hauptversion auf 18.7, 17.12, 16.16, 15.20 oder 14.25 aktualisieren.
• Alle C-Erweiterungen zusammen mit dem Server neu bauen oder aktualisieren. Erweiterungen, die gegen ältere Releases gebaut wurden, laden zwar weiterhin, sind laut einem Hinweis der RPM-Paketbetreuer des Projekts aber „möglicherweise nicht vor den in diesem Release behobenen Schwachstellen geschützt“. Einige Erweiterungen brauchen zudem Änderungen am Quellcode. Neu gebaute Erweiterungen laden auf älteren Servern unter Umständen nicht mehr. Die Erweiterungspakete in den RPM-Repositorys des Projekts setzen inzwischen das neue Minor-Release voraus.
• PostgreSQL direkt nach dem Update neu starten, wenn es außerhalb der Service-Unit des Pakets läuft, etwa unter Patroni. Das empfiehlt ein Betreuer der RPM-Pakete in einem Blogbeitrag.
• Client-Werkzeuge wie pg_dump, pg_restore, reindexdb und vacuumdb auf allen Rechnern aktualisieren, auf denen sie laufen.
• Die neuen Prüfungen nicht über die Einstellung composite_type_mismatch abschalten. Das Projekt warnt, dass dies Sicherheitsrisiken mit sich bringt.
• Nach dem Update die Schritte zur Neuindizierung aus der Release-Ankündigung ausführen. Wer inkrementelle Backups nutzt, sollte ein neues Voll-Backup anlegen und spätere inkrementelle Sicherungen darauf aufbauen.

Für Server, die sich noch nicht aktualisieren lassen, nennen weder die Sicherheitsmitteilung noch die Release Notes einen Workaround. Für PostgreSQL 14 endet mit Version 14.25 die Unterstützung. Ältere Hauptversionen sind ebenfalls betroffen, erhalten aber kein Update.