PostgreSQL schließt 22 Jahre alten Fehler, über den Datenbanknutzer Code ausführen können

Das PostgreSQL-Projekt hat am 12. November die Updates 18.7, 17.12, 16.16, 15.20 und 14.25 veröffentlicht. Laut Projekt schließen sie 52 Sicherheitslücken und beheben mehr als 140 weitere Fehler. Am meisten diskutiert wird CVE-2026-6460 mit einer Bewertung von 8,8 von 10: Ein Datenbanknutzer, der Objekte anlegen darf, kann eigenen Code auf dem Server ausführen, mit den Rechten des Betriebssystemnutzers, unter dem PostgreSQL läuft. Dieselbe Bewertung hat das Projekt 31 weiteren Lücken in diesem Release gegeben. Angriffe über CVE-2026-6460 sind bisher nicht bekannt.

Warum der Fehler 22 Jahre alt ist

Die Lücke betrifft zusammengesetzte Typen, also Typen aus mehreren benannten Feldern. Der Typ eines Feldes lässt sich ändern, während ältere Werte noch an anderen Stellen im Server liegen, und der Server liest dann einen alten Wert so, als hätte er schon den neuen Typ. In der Sicherheitsmeldung räumt das Projekt ein, dass das System Werttypen unzureichend verfolgt hat. Der Forscher Mehmet Ince, der einen funktionierenden Exploit auf Version 18.6 gezeigt hat, führt das Problem auf den 5. Mai 2004 zurück, als PostgreSQL das Ändern von Spaltentypen erlaubte, berichtet The Hacker News.

Ince zufolge konnte er einen ungepatchten Server schon mit der Rolle mit den geringsten Rechten zum Absturz bringen. Ob ein solches Konto auch Code ausführen kann, sagt keine der Quellen. Im August hat er den Exploit für verwaltete Datenbanken angepasst und an die Sicherheitsteams von AWS, Microsoft Azure, Google, Supabase, Databricks und Ubicloud weitergegeben. Ob alle inzwischen gepatcht haben, ist nicht bekannt.

Wen es betrifft

Vor allem alle, die fremde Menschen in dieselbe Datenbank lassen: Hoster, Cloud-Dienste und jedes Projekt, das Kunden ein eigenes PostgreSQL-Konto gibt. Spricht nur die eigene Anwendung mit der Datenbank, müsste ein Angreifer von außen dort erst Rechte bekommen. Auch Client-Werkzeuge wurden repariert: Ein präpariertes Archiv kann pg_restore dazu bringen, Code auf dem Rechner dessen auszuführen, der es einspielt. Nur eine der 52 Lücken funktioniert ohne Anmeldung, sie erlaubt einen Neustart von PostgreSQL-18-Servern.

Es ist nicht das einzige Server-Update dieser Woche, das man zügig einspielen sollte: Kürzlich haben wir über eine HTTP/2-Lücke in Apache berichtet.

Was zu tun ist

• Aktualisieren Sie den Server passend zur Hauptversion auf 18.7, 17.12, 16.16, 15.20 oder 14.25. Dump und Reload sind nicht nötig.
• Bauen oder aktualisieren Sie alle C-Erweiterungen zur selben Zeit. Alte Builds laden weiter, sind aber laut den Betreuern der RPM-Pakete womöglich nicht geschützt.
• Aktualisieren Sie pg_dump, pg_restore, reindexdb und vacuumdb auf allen Rechnern, auf denen sie laufen.
• Läuft PostgreSQL außerhalb der Service-Unit des Pakets, etwa unter Patroni, starten Sie es direkt nach dem Update neu.
• Schalten Sie die neuen Prüfungen nicht über die Einstellung composite_type_mismatch ab: Das Projekt warnt vor Sicherheitsrisiken.
• Folgen Sie den Schritten im Abschnitt „Updating“ der Release-Meldung: betroffene Indizes neu aufbauen (GIN, GiST mit pg_trgm, B-Tree auf bpchar-Spalten) und bei inkrementellen Backups ein neues Vollbackup anlegen.
• Wenn Sie Version 14 oder älter nutzen, planen Sie den Umstieg: Nach 14.25 gibt es keine Korrekturen mehr.