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ügenInhalt 4 Abschnitte
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]
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?

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
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
- PostgreSQL Global Development GroupCVE-2026-6460: PostgreSQL type confusion after ALTER … SET DATA TYPE executes arbitrary code
- Mehmet IncePart 3/6 | How I Ended Up Turning a 22-Year-Old PostgreSQL Type-Confusion Primitive into RCE (CVE-2026-6460)
- PostgreSQL Global Development GroupPostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25, and 19 RC 2 Released!
Mehr Newshunger?
- PostgreSQL 19 verspätet sich, weil viel mehr Fehler gefunden werden
- Apache HTTP Server: Kritische Sicherheitslücke im HTTP/2-Modul
- Ubuntu-Update für kritische Linux-Sicherheitslücke steckt nach 19 Tagen noch im Test
- VulnCheck: Nur 2 von 442 Anthropic-CVEs werden ausgenutzt
- Kritische Brotli-Sicherheitslücke: WordPress-Websites über Pingbacks angreifbar
- Kritische Sicherheitslücke in FortiManager und FortiAnalyzer
