PostgreSQL-Lücke: SQL-Rechte können zur Codeausführung reichen

PostgreSQL hat eine Sicherheitslücke geschlossen, über die angemeldete Datenbanknutzer mit passenden Rechten zum Erstellen von Objekten beliebigen Code mit den Betriebssystemrechten des Datenbankservers ausführen können. Für Betreiber reicht es allerdings nicht in jedem Fall, nur den Server zu aktualisieren: Zum vollständigen Schutz müssen auch eingesetzte C-Extensions neu gebaut werden. Einige Erweiterungen benötigen zusätzlich Änderungen am Quellcode.

Die als CVE-2026-6460 geführte Typkonfusion betrifft Composite-Typen, also zusammengesetzte Werte mit mehreren typisierten Feldern. Das offizielle Advisory nennt Ersteller von Datenbankobjekten als mögliche Angreifer. Superuser-Rechte oder eine Benutzerinteraktion sind nach dem ausgewiesenen Angriffsmodell nicht erforderlich. PostgreSQL bewertet die Lücke mit einem CVSS-3.0-Basiswert von 8,8. Damit wird aus begrenzten SQL-Berechtigungen ein möglicher Zugriff auf die Ausführungsumgebung des Servers. (PostgreSQL Security Advisory CVE-2026-6460)

Wenn alte Bytes einen neuen Typ bekommen

Die technische Ursache liegt darin, wie PostgreSQL gespeicherte Werte und ihre Typbeschreibung zusammenführt. Intern können Werte als sogenannte Datum-Werte ohne eigene Typkennung vorliegen. Wie ihre Bytes zu lesen sind, ergibt sich aus dem zugehörigen Typ. Ändert sich die Beschreibung eines Composite-Attributs, während eine vorbereitete Anweisung noch einen alten Wert hält, können dieselben Bytes anschließend unter falschen Annahmen verarbeitet werden.

Der Sicherheitsforscher Mehmet Ince beschreibt dafür in einem am 9. November 2026 veröffentlichten Beitrag einen kurzen Ablauf: Ein temporärer Composite-Typ enthält zunächst ein UUID-Feld. Eine vorbereitete Anweisung hält einen Wert dieses Typs. Danach wird das Attribut auf den Binärdatentyp bytea geändert und die Anweisung ausgeführt. Nach seiner Darstellung interpretiert PostgreSQL Teile der UUID daraufhin als Verwaltungsinformationen und Speicherzeiger. Sein Absturzbeispiel endet mit einem ungültigen Speicherzugriff.

Für Codeausführung geht Inces beschriebene Angriffskette weiter. Kontrollierte Daten geben sich als interne Objektstruktur mit einer Methodentabelle aus. Ein indirekter Funktionsaufruf lässt sich dadurch nach seiner Darstellung auf system() umlenken. Eine weitere Variante derselben Typverwechslung soll Speicheradressen offenlegen und damit die Adressraum-Randomisierung ASLR umgehen.

Dass die Schwachstelle grundsätzlich beliebige Codeausführung erlaubt, bestätigt das PostgreSQL-Advisory. Die konkrete Exploit-Kette einschließlich der ASLR-Umgehung ist dagegen die Darstellung des Forschers; eine unabhängige Bestätigung dieser vollständigen Kette liegt in den vorliegenden Quellen nicht vor.

Die relevante Grenze liegt zwischen SQL und Betriebssystem

Für die Risikobewertung ist entscheidend, welche Nutzer eigene Datenbankobjekte anlegen können. Ince gibt an, den Absturz mit einer minimal berechtigten Login-Rolle ausschließlich über SQL im temporären Namensraum pg_temp ausgelöst zu haben, ohne zusätzliche Extensions. Eine Anwendung muss dem Angreifer demnach keine reguläre Funktion zur Ausführung von Betriebssystembefehlen bereitstellen.

Das betrifft besonders Umgebungen, in denen Datenbankzugänge bewusst an unterschiedliche Nutzer oder Kunden vergeben werden. Deren SQL-Rechte sollen innerhalb der Datenbank bleiben. Codeausführung als Betriebssystembenutzer des Datenbankservers überschreitet diese Grenze. Welche weiteren Daten und Ressourcen dann erreichbar wären, hängt von den Rechten des Serverprozesses und seiner Isolation ab. Root-Rechte oder ein Ausbruch aus einem Container folgen daraus nicht automatisch.

Ince berichtet, seinen lokal funktionierenden Exploit auf nahezu jede ihm bekannte Managed-PostgreSQL-Plattform portiert und den jeweiligen Sicherheitsteams reproduzierbare Beispiele übergeben zu haben. Das ist keine bestätigte Bestandsaufnahme aller Anbieter. Für Kunden verwalteter Datenbanken folgt daraus vor allem eine konkrete Prüfaufgabe: Sie benötigen Auskunft über den tatsächlich eingespielten Patchstand ihres Dienstes. Welche Anbieter bereits eigene Sicherheitsmeldungen oder Patch-Bestätigungen veröffentlicht haben, ist hier nicht geklärt.

Der Patch verändert auch den Umgang mit Erweiterungen

Die am 12. November 2026 veröffentlichten Versionen PostgreSQL 18.7, 17.12, 16.16, 15.20 und 14.25 enthalten die Korrekturen. Frühere Versionen der jeweiligen Reihen sind betroffen. Das Release enthält neben CVE-2026-6460 weitere Sicherheitskorrekturen und behebt zahlreiche gemeldete Fehler. CVE-2026-6460 ist dabei ein Sammel-Fix für mehrere verwandte Composite-Typ-Probleme.

Die Reparatur setzt an der Zuordnung zwischen Wert und Typbeschreibung an. Eine Versionierung von Composite-Datum-Werten soll erkennen, wenn ein Wert nicht zu dem Tupeldeskriptor passt, mit dem der Server ihn interpretieren will. Hinzu kommen Sperren gegen ALTER TYPE auf noch nicht committeten Typen sowie strengere Regeln für Typänderungen an Spalten mit bestehenden Abhängigkeiten.

Diese Eingriffe haben Folgen für den Betrieb: Die Release Notes verlangen für vollständigen Schutz den Neubau von C-Extensions; bei einigen sind Quellcode-Anpassungen nötig. Der Serverparameter composite_type_mismatch kann die neuen Prüfungen abschalten. PostgreSQL warnt ausdrücklich vor den damit verbundenen Sicherheitsrisiken. Kompatibilitätsprobleme auf diesem Weg zu umgehen, kann den vorgesehenen Schutz daher schwächen. (PostgreSQL 18.7 Release Notes)

Updateplanung braucht einen Blick auf den gesamten Bestand

Betreiber sollten das Update deshalb zusammen mit einer Bestandsaufnahme der nativen Erweiterungen planen. Entscheidend ist, ob diese für die korrigierte Version neu gebaut wurden und ob erforderliche Anpassungen verfügbar sind. Ebenso gehört zur Kontrolle nach dem Update, dass die neuen Prüfungen nicht aus Kompatibilitätsgründen deaktiviert wurden.

Für Installationen der Reihe 14 kommt eine weitere Aufgabe hinzu: PostgreSQL 14.25 ist deren letzte unterstützte Version. Sie schließt die aktuelle Lücke, danach erhält diese Reihe aber keine weiteren Sicherheits- und Fehlerkorrekturen. Das kurzfristige Einspielen des Updates und der Wechsel auf eine weiter gepflegte Hauptversion sind hier zwei getrennte Arbeitsschritte.

Der unmittelbare Handlungsbedarf hängt damit nicht davon ab, ob eine Datenbank öffentlich im Internet erreichbar ist. Auch ein regulär vergebener SQL-Zugang kann die nötige Ausgangsposition liefern. Bis die korrigierte Version samt angepassten Erweiterungen läuft, bleibt insbesondere die Vergabe von Rechten zum Erstellen eigener Datenbankobjekte sicherheitsrelevant. Eine bestätigte Alternative zum Patch ergibt sich aus den verfügbaren Angaben nicht.