PostgreSQL-Lücke: Zum vollständigen Schutz Erweiterungen neu bauen

PostgreSQL hat eine Sicherheitslücke geschlossen, über die authentifizierte Ersteller von Datenbankobjekten beliebigen Code mit den Betriebssystemrechten des Datenbankdienstes ausführen können. Die am 12. November 2026 veröffentlichten Versionen 18.7, 17.12, 16.16, 15.20 und 14.25 beheben CVE-2026-6460. Für Betreiber mit C-Erweiterungen reicht die Aktualisierung des Servers allein allerdings nicht zum vollständigen Schutz: Diese Erweiterungen müssen neu gebaut werden, einige benötigen außerdem Änderungen am Quellcode.

Der Fehler betrifft den Umgang mit zusammengesetzten Datentypen, sogenannten Komposittypen. Seine praktische Bedeutung liegt im Übergang von Datenbankrechten zu nativer Codeausführung. Wer innerhalb der Datenbank bestimmte Objekte anlegen und verändern darf, kann laut PostgreSQL-Advisory die Rechte des Betriebssystembenutzers erlangen, unter dem der Server läuft. Das Projekt bewertet die Lücke mit einem CVSS-Score von 8,8. Eine Authentifizierung ist erforderlich, eine weitere Benutzerinteraktion nicht. Betroffen sind die Versionen vor den genannten Wartungsständen. (PostgreSQL Security Advisory CVE-2026-6460)

Wenn ein gespeicherter Wert nicht mehr zu seinem Typ passt

Ein Komposittyp fasst mehrere Felder zu einem strukturierten Wert zusammen. Damit PostgreSQL diesen Wert korrekt verarbeiten kann, müssen dessen tatsächlicher Aufbau und die Beschreibung seiner Felder zusammenpassen. Genau diese Zuordnung wurde bislang nicht ausreichend nachverfolgt, wenn sich Typdefinitionen änderten.

Nach Angaben des Advisories konnten veraltete typisierte Werte unter anderem in Einträgen des Data Dictionary und in PL/pgSQL-Variablen verbleiben. Wird ein solcher Wert anschließend anhand einer nicht mehr passenden Typbeschreibung interpretiert, entsteht eine Typkonfusion: Der Server verarbeitet den vorhandenen Inhalt unter falschen Annahmen über dessen Struktur.

Der Sicherheitsforscher Mehmet Ince beschreibt dazu einen Ablauf, bei dem er einen Wert eines Komposittyps ablegt, den Typ eines Feldes ändert und den zuvor gespeicherten Wert wieder auslesen lässt. Das Advisory reicht über diesen einzelnen Ablauf hinaus. Neben ALTER ... SET DATA TYPE nennt es weitere Wege über Änderungen an Datenbankstrukturen, darunter die Abfolge ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN.

Die Lücke lässt sich damit nicht auf einen einzelnen gefährlichen Befehl reduzieren. PostgreSQL behandelt CVE-2026-6460 als Sammelproblem einer breiteren Familie von Fehlern bei Komposittypen. Entsprechend muss die Absicherung an der Konsistenz zwischen Wert und Typbeschreibung ansetzen.

Die entscheidende Grenze verläuft hinter dem Login

CVE-2026-6460 ist nach dem Advisory kein Angriff ohne Zugangsdaten. Voraussetzung ist eine authentifizierte Rolle mit den erforderlichen Möglichkeiten zur Erstellung und Veränderung von Datenbankobjekten. Der CVSS-Wert allein sagt deshalb noch wenig darüber aus, wie offen ein konkretes System für diesen Angriff ist. Entscheidend ist, welche Rechte die dort verwendeten Rollen tatsächlich besitzen.

Für die Risikobewertung sollten Betreiber deshalb besonders Konten prüfen, die eigene Datenbankobjekte erstellen dürfen. Das betrifft etwa Umgebungen, in denen Anwendungsteams oder Kunden solche Befugnisse erhalten. Die Rechtevergabe innerhalb von PostgreSQL ist hier eine Sicherheitsgrenze: Eine Rolle kann weit unterhalb eines Datenbankadministrators angesiedelt sein und dennoch die für eine Schwachstelle relevanten Operationen ausführen dürfen.

Gelingt die Ausnutzung, läuft der eingeschleuste Code laut Advisory als Betriebssystembenutzer der Datenbank. Das bedeutet nicht automatisch Root-Zugriff auf den Host. Welche Dateien, Dienste oder weiteren Ressourcen erreichbar wären, hängt von den Rechten dieses Kontos und der Isolation der Umgebung ab. Restriktive Betriebssystemrechte können mögliche Folgen begrenzen; sie beheben die Typkonfusion jedoch nicht.

Ob die Lücke bereits aktiv ausgenutzt wurde, geht aus den vorliegenden Quellen nicht hervor. Auch die Verfügbarkeit öffentlichen Exploit-Codes und die Zuverlässigkeit einer Ausnutzung in Standardkonfigurationen sind nicht verifiziert. Aus der technischen Beschreibung lässt sich daher keine laufende Angriffswelle ableiten.

Der Fix betrifft auch den Erweiterungsbestand

Die strukturelle Gegenmaßnahme führt eine Versionierung für Kompositwerte ein. PostgreSQL kann dadurch erkennen, wenn ein solcher Wert nicht zu dem Tuple-Deskriptor passt, mit dem er interpretiert werden soll. Dieser Deskriptor beschreibt den erwarteten Aufbau des Datensatzes. Die Prüfung setzt damit an der fehlerhaften Zuordnung an, bevor ein Wert unter unpassenden Strukturannahmen weiterverarbeitet wird.

Für vollständigen Schutz verlangen die Release Notes ausdrücklich einen Neubau der C-Erweiterungen. Bei einigen sind zusätzlich Quellcodeänderungen erforderlich. Außerdem gibt es mit composite_type_mismatch einen neuen Serverparameter, über den sich die Prüfungen abschalten lassen. Die Release Notes warnen, dass dies Sicherheitsrisiken mit sich bringt. (PostgreSQL Release Notes 18.7)

Für den Betrieb wird aus dem Sicherheitsupdate dadurch auch eine Aufgabe der Erweiterungsverwaltung. Neben der installierten Serverversion müssen die eingesetzten C-Erweiterungen, ihre aktualisierten Builds und gegebenenfalls notwendige Anpassungen geprüft werden. Eine aktuelle Versionsnummer des Servers allein belegt bei solchen Installationen noch keinen vollständigen Schutz.

Falls nach der Aktualisierung Kompatibilitätsprobleme auftreten, sollte das Abschalten der neuen Prüfungen nicht als harmlose Übergangslösung gelten. Es nimmt gerade den Schutz zurück, den der Fix einführt. Bei verwalteten PostgreSQL-Angeboten sollten Kunden deshalb auch klären, ob der Anbieter die betroffenen Erweiterungen berücksichtigt hat. Ein bereits erfolgter Rollout bei einzelnen Anbietern ist durch die vorliegenden Informationen nicht belegt.

PostgreSQL 14 braucht zusätzlich einen Migrationsplan

Die Veröffentlichung umfasst nach Angaben des PostgreSQL-Projekts weitere Sicherheitskorrekturen und zahlreiche Fehlerbehebungen. Zu den geschlossenen Lücken zählen weitere Typkonfusionen, etwa CVE-2026-116306 bei der Feldzuweisung von Kompositwerten. Ein Aufschub betrifft damit mehr als den hier beschriebenen Angriffsweg.

Für PostgreSQL 14 ist Version 14.25 zugleich die letzte reguläre Wartungsveröffentlichung: Mit diesem Release endet der Support der Hauptversion. Betreiber sollten die verfügbare Korrektur daher von der notwendigen Migration unterscheiden. Das Update schließt die jetzt behobenen Lücken; weitere Sicherheits- und Fehlerkorrekturen erhält dieser Versionszweig nicht mehr.

Die im Zusammenhang mit CVE-2026-6460 verbreitete Altersangabe von 22 Jahren stammt von Ince. Er führt die veränderbare Zeilentyp-Primitive auf einen Commit vom 5. Mai 2004 zurück, seine verwendete Ausnutzungstechnik auf einen weiteren vom 14. Mai 2015. Daraus folgt kein Nachweis einer seit 22 Jahren unverändert möglichen oder tatsächlich erfolgten Ausnutzung. Für die aktuelle Absicherung zählen die korrigierten Versionsstände, der Neubau der C-Erweiterungen und die aktivierten Konsistenzprüfungen.