PostgreSQL CVE-2026-6460: Datenbankbenutzer, die Objekte anlegen können, können Code auf dem Server ausführen

Was passiert ist

Am 12. November 2026 hat die PostgreSQL Global Development Group PostgreSQL 18.7, 17.12, 16.16, 15.20 und 14.25 veröffentlicht. Laut The Hacker News beheben diese Versionen 52 Sicherheitslücken. Die schwerwiegendste ist CVE-2026-6460 (CVSS 8.8), ein Fehler durch Typverwechslung im Kernserver.

Ein Datenbankbenutzer, der Objekte anlegen kann, kann mit ALTER ... SET DATA TYPE erreichen, dass der Server einen veralteten Wert so liest, als hätte er einen neuen Typ. Andere DDL-Anweisungen können dasselbe bewirken, zum Beispiel ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN. Dadurch kann der Benutzer beliebigen Code als Betriebssystembenutzer ausführen, unter dem PostgreSQL läuft. Die Korrektur ergänzt Versionsprüfungen, damit der Server Werte erkennen kann, die nicht mehr zu ihrem Typ passen.

Der Sicherheitsforscher Mehmet Ince hat einen technischen Bericht mit einem funktionierenden Exploit veröffentlicht, den er auf PostgreSQL 18.6 vorgeführt hat. Der Bericht enthält das SQL, das einen ungepatchten Server zum Absturz bringt, sowie einen Schritt, der Speicheradressen preisgibt. Der letzte Schritt, der einen Befehl ausführt, ist nicht enthalten. Er schrieb, dass er den Absturz mit einer Anmelderolle mit den geringsten Rechten auslösen konnte. Die Quellen sagen nicht, ob ein Konto mit nur den Standardrechten weiter gehen und Code ausführen kann. Red Hat nennt als Voraussetzung, dass ein Angreifer eine Datenbankanmeldung benötigt, die Objekte anlegen oder ändern kann.

Das PostgreSQL-Projekt hat keine Angriffe gemeldet, die diese Lücke nutzen, und die CISA führt sie nicht als ausgenutzt.

Dieselben Versionen beheben weitere Schwachstellen, darunter CVE-2026-116322, mit der ein nicht authentifizierter Client erzwingen kann, dass PostgreSQL-18-Server neu starten. Außerdem werden Schwachstellen in Client-Werkzeugen behoben: Ein präpariertes Archiv kann dazu führen, dass pg_restore Code als der ausführende Benutzer ausführt, und ein kompromittierter Quellserver kann psql über das Wiederherstellungsskript in der tar-Ausgabe von pg_dump Code ausführen lassen.

Wen es betrifft

• PostgreSQL 18 vor 18.7, 17 vor 17.12, 16 vor 16.16, 15 vor 15.20 und 14 vor 14.25.
• Ältere Hauptversionen sind ebenfalls betroffen und erhalten kein Update. PostgreSQL 14 ist inzwischen end of life, 14.25 ist die letzte Version.
• Das Risiko ist am höchsten auf Servern, auf denen Personen Datenbankanmeldungen besitzen, denen Sie nicht vollständig vertrauen und die Objekte anlegen oder ändern können. Dazu gehören Shared Hosting, an Kunden übergebene Datenbanken und Webanwendungen, deren Datenbankkonto das eigene Schema besitzt. Wenn ein Angreifer eine solche Anwendung übernimmt, etwa über SQL-Injection, kann er das Datenbankkonto unter Umständen auf diese Weise nutzen.
• Verwaltete Dienste: Der Forscher hat Proofs of Concept an AWS (RDS, Aurora), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks und Ubicloud weitergegeben. Deren aktueller Patchstand ist nicht bekannt. Prüfen Sie die Hinweise Ihres Anbieters.
• Server, auf denen kein PostgreSQL läuft, sind nicht betroffen. MySQL und MariaDB sind nicht betroffen.

Was Sie jetzt tun sollten

1. Sichern Sie Ihre PostgreSQL-Konfiguration (zum Beispiel postgresql.conf und pg_hba.conf) und stellen Sie sicher, dass Sie ein aktuelles Datenbank-Backup haben.
2. Aktualisieren Sie den Server auf die korrigierte Version für Ihre Hauptversion: 18.7, 17.12, 16.16, 15.20 oder 14.25. Wenn Sie Pakete Ihrer Distribution (Debian, Ubuntu, RHEL und Derivate) verwenden, installieren Sie die korrigierten Pakete aus der Sicherheitsmitteilung Ihrer Distribution, sobald sie verfügbar sind. Verwenden Sie danach den Paketmanager wie gewohnt (apt update && apt upgrade oder dnf upgrade).
3. Aktualisieren oder bauen Sie jede C-Erweiterung zugleich mit dem Server neu. Die RPM-Betreuer des Projekts warnen, dass Erweiterungen, die gegen ältere Versionen gebaut wurden, zwar weiterhin geladen werden, aber möglicherweise nicht geschützt sind. Einige Erweiterungen benötigen außerdem Änderungen am Quellcode. Erweiterungspakete in den PostgreSQL-RPM-Repositories setzen jetzt die neue Minor-Version voraus.
4. Starten Sie PostgreSQL neu. Läuft es außerhalb der eigenen Service-Unit des Pakets, etwa unter Patroni, starten Sie es direkt nach dem Update manuell neu.
5. Folgen Sie den Reindexierungsschritten in der offiziellen Ankündigung der Version. Wenn Sie inkrementelle Backups verwenden, erstellen Sie ein neues vollständiges Backup und basieren Sie künftige inkrementelle Backups darauf.
6. Aktualisieren Sie Client-Werkzeuge wie pg_dump, pg_restore, psql, reindexdb und vacuumdb auf jedem Rechner, der sie verwendet, einschließlich Backup-Hosts und Administrations-Arbeitsplätzen.
7. Verwenden Sie die neue Einstellung composite_type_mismatch nicht, um die neuen Prüfungen abzuschalten. Das Projekt weist darauf hin, dass dies Sicherheitsrisiken birgt.
8. Wenn Sie nicht sofort aktualisieren können, beachten Sie, dass das Projekt keine Workaround-Lösung anbietet. Prüfen Sie bis dahin, welche Konten Objekte anlegen oder ändern können, besonders Konten von Webanwendungen oder solche, die an Kunden vergeben wurden, und stellen Sie sicher, dass PostgreSQL nur dann aus dem Internet erreichbar ist, wenn es nötig ist.
9. Wenn Sie noch PostgreSQL 14 oder eine noch ältere Version betreiben, planen Sie ein Upgrade auf eine unterstützte Hauptversion.

So prüfen Sie, ob Sie betroffen sind

• Prüfen Sie die laufende Serverversion mit psql -c 'SELECT version();' oder SHOW server_version;. Versionen unterhalb von 18.7, 17.12, 16.16, 15.20 oder 14.25 innerhalb ihrer Hauptversionsreihe sind betroffen.
• Prüfen Sie die installierten Binärdateien und Pakete mit postgres -V, dpkg -l | grep postgresql oder rpm -qa | grep postgresql. Starten Sie den Server neu, wenn die laufende Version älter ist als die installierte.
• Listen Sie installierte Erweiterungen mit SELECT extname, extversion FROM pg_extension; in jeder Datenbank auf. Stellen Sie sicher, dass jede C-Erweiterung für die neue Version aktualisiert oder neu gebaut wurde.
• Prüfen Sie die PostgreSQL-Logs auf unerwartete Abstürze von Backend-Prozessen, etwa Serverprozesse, die durch ein Signal beendet wurden. Der veröffentlichte Exploit bringt ungepatchte Server zum Absturz, daher lohnt es sich, solche Abstürze genauer zu prüfen.

Quellen

• https://nvd.nist.gov/vuln/detail/CVE-2026-6460
• https://www.postgresql.org/support/security/CVE-2026-6460/