Artikel teilen

Ein Datenbank-Login mit niedrigen Rechten genügt, um auf dem Server fremden Code auszuführen. Die Wurzel des Fehlers liegt laut dem Forscher Mehmet Ince im Jahr 2004, das PostgreSQL-Projekt hat ihn am 12. November in fünf Versionen behoben. Dazu kommen 51 weitere Sicherheitslücken im selben Update.

Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügen
Inhalt 4 Abschnitte
  1. Wie funktioniert der Angriff?
  2. Welche Betreiber sind betroffen?
  3. Was sollten Betreiber jetzt tun?
  4. Mehr Newshunger?

Das PostgreSQL-Projekt hat am 12. November die Versionen 18.7, 17.12, 16.16, 15.20 und 14.25 veröffentlicht. Die Updates schließen CVE-2026-6460, eine schwere Sicherheitslücke im Kern des Datenbankservers mit dem CVSS-Wert 8,8.[1] Entdeckt hat sie der Sicherheitsforscher Mehmet Ince, der seinen Fund am 9. November beschrieb.[2]

Auf einen Blick

Das Wichtigste in Kürze

  • Betroffen sind alle Versionen vor 18.7, 17.12, 16.16, 15.20 und 14.25.
  • Ursache ist eine Typverwechslung nach einem Typwechsel.
  • Das Update schließt 52 Sicherheitslücken und verlangt bei einigen Indizes einen Neuaufbau.
  • PostgreSQL 14 erhält mit 14.25 sein letztes Update.

Wie funktioniert der Angriff?

Geschlossener Metallsafe mit Drehschloss, Hebelgriff und Prüfplakette „Geprüft 2004“ auf hellorangem Grund
PostgreSQL interpretiert Bytes falsch, wenn ALTER TABLE den Feldtyp ändert, während vorbereitete Abfragen noch alte Werte halten

Die Ursache ist eine Typverwechslung. PostgreSQL speichert Werte ohne Typkennzeichnung: Welcher Datentyp zu den Bytes gehört, steht nur im Systemkatalog.[2] Ändert jemand mit ALTER … SET DATA TYPE den Typ eines Feldes, obwohl eine vorbereitete Abfrage noch einen Wert im alten Typ hält, liest der Server dessen Bytes später als neuen Typ.[1]

Ince legte einen zusammengesetzten Datentyp mit UUID-Feld an, stellte es auf bytea um und führte die vorbereitete Abfrage aus: Der Server stürzte ab. Aus 48 selbst gewählten UUID-Bytes baute er ein gefälschtes Array und konnte nach eigenen Angaben auf PostgreSQL 18.6 fremden Code ausführen. Die Technik beruht auf einem Commit von 2004.[2]

Ince meldete 21 weitere Fälle derselben Fehlerklasse.[2] Nach einer Zählung der Liste in der Ankündigung nennen 28 der 52 Einträge im Titel Codeausführung, zehn eine Typverwechslung.[3] Dass die Zahl der Funde steigt, hatte schon die Verspätung von PostgreSQL 19 gezeigt.

Welche Betreiber sind betroffen?

Laut CVSS-Vektor genügt ein Zugang über das Netz mit niedrigen Rechten, eine Handlung des Opfers braucht der Angriff nicht.[1] Für Webanwendungen folgt daraus: Gelingt Angreifern eine SQL-Injection, könnte aus dem Datenbankzugriff ein Zugriff auf den Server werden.

Bei gemieteten Datenbankdiensten läuft das Update über den Anbieter. Ince berichtet, AWS und Microsoft Azure hätten Mitte August Berichte samt funktionierendem Exploit erhalten.[2] Wie weit die Dienste mit dem Update sind, müssen Kunden beim Anbieter erfragen.

Ein Fehler von 2004 zeigt: Der Datenbankserver gehört in den Patchplan wie jede Website.

Markus Seyfferth, Chefredakteur Dr. Web
Zitat teilen
PostgreSQL-Sicherheitslücke CVE-2026-6460 in Zahlen
Einstufung, Umfang des Updates und Zeitplan vom Commit bis zur Korrektur
8,8
CVSS-Wert (hoch), Angriff über das Netz mit niedrigen Rechten
52
Sicherheitslücken schließt das Update vom 12. November
28 von 52
Einträge nennen im Titel Codeausführung (eigene Zählung)
22 Jahre
liegt der Commit zurück, auf dem der Angriff aufbaut
Vom Commit zum Update
05.05.2004
Ein Commit macht Zeilentypen nachträglich änderbar
Mitte August
AWS und Azure erhalten Berichte samt funktionierendem Exploit
09.11.
Mehmet Ince beschreibt den Fund
12.11.
PostgreSQL veröffentlicht 18.7, 17.12, 16.16, 15.20 und 14.25

Was sollten Betreiber jetzt tun?

SELECT version(); zeigt den Stand. Liegt er unter den fünf Versionen, genügt innerhalb der Hauptversion ein Wartungsupdate mit Neustart. Danach brauchen pg_trgm-GiST-Indizes und B-Tree-Indizes auf bpchar-Spalten einen Neuaufbau, nach inkrementellen Backups ist ein neues Vollbackup fällig.[3]

PostgreSQL 14 bekommt keine Sicherheitskorrekturen mehr, der Umstieg gehört deshalb jetzt in die Planung.[3] Eine bekannte Sicherheitslücke wochenlang offen zu lassen, verträgt sich schlecht mit dem Stand der Technik nach Artikel 32 DSGVO. Wie lange ein Update dauern kann, zeigte ein kritisches Linux-Update, das nach 19 Tagen noch im Test steckte.

Quellen

3 Quellen anzeigenQuellen ausblenden
  1. PostgreSQL Global Development GroupCVE-2026-6460: PostgreSQL type confusion after ALTER … SET DATA TYPE executes arbitrary code12.11.2026
  2. Mehmet IncePart 3/6 | How I Ended Up Turning a 22-Year-Old PostgreSQL Type-Confusion Primitive into RCE (CVE-2026-6460)09.11.2026
  3. PostgreSQL Global Development GroupPostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25, and 19 RC 2 Released!12.11.2026

Mehr Newshunger?

4,4 10 Bewertungen

Wie hat Ihnen dieser Artikel gefallen?

Dr. Web Newsletter

Jede Woche ein bisschen klüger.

Der Dr. Web Newsletter: die besten Artikel, Anbieter-Tipps und neue Tools, kompakt zusammengefasst, jeden Donnerstag. Kostenlos und jederzeit abbestellbar.