PostgreSQL Sicherheitslücke CVE-2026-6471: Replikationskonto wird zur Root-Shell

Zwölf Jahre lang hatte eine der meistgenutzten Datenbanken der Welt eine offene Hintertür für Replikationskonten. Die PostgreSQL Sicherheitslücke CVE-2026-6471 – von den Entdeckern „PostGREShell” getauft – erlaubt es einem Account mit dem Attribut REPLICATION, beliebigen Code als Betriebssystem-Benutzer des Datenbankservers auszuführen. Der Patch ist seit dem 13. August da; die technische Analyse von Cyera Research vom 1. September und ein Bericht von The Hacker News vom 4. September zeigen jetzt, wie einfach der Angriff ist – und warum das Update allein nicht reicht.

Was passiert ist

Die Lücke steckt im Logical Decoding, das mit PostgreSQL 9.4 im Jahr 2014 eingeführt wurde. Beim Anlegen eines Replikations-Slots gibt der Client den Namen des Output-Plugins an – einer Bibliothek, die der Server dann lädt. Genau dieser Name wurde laut Cyera ungeprüft an den Loader durchgereicht. Die vorhandene Beschränkung auf ein Plugin-Verzeichnis greift auf dem Replikationspfad nicht, und der Parser akzeptiert in Anführungszeichen fast jedes Zeichen, auch Pfadtrenner und „../”. Ergebnis: ein vollständiger Dateipfad landet beim Loader, und die Bibliothek wird im Datenbankprozess ausgeführt.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

Unter Windows löst der Server sogar UNC-Pfade auf und holt die Bibliothek per SMB von einem Rechner des Angreifers, ohne dass etwas auf die Platte des Ziels geschrieben wird. Unter Linux und macOS braucht es entweder NFS-Automount oder einen anderen Weg, eine Datei auf dem Server abzulegen. Cyeras Test-Plugin schrieb anschließend direkt den Rollenkatalog um und machte das Replikationskonto zum Superuser.

Das PostgreSQL-Projekt bewertet die Lücke mit CVSS 7.2 (Privileges Required: High). Betroffen sind alle Versionen vor 18.6, 17.11, 16.15, 15.19 und 14.24. Der Fix führt den neuen Parameter output_plugin_libraries ein – eine Positivliste erlaubter Plugins mit dem Standardwert 'pgoutput, test_decoding'. Eine Ausnutzung in freier Wildbahn ist bislang nicht bekannt: Die CVE steht laut The Hacker News (Stand 4. September) nicht im CISA-KEV-Katalog, und öffentlicher Exploit-Code wurde nicht gefunden.

Was das für dich bedeutet

Die Bewertung „Privileges Required: High” täuscht in der Praxis. REPLICATION gilt bei vielen Teams als harmloses Backup-Recht – es steckt in Konten für pg_basebackup, Standby-Server, CDC-Pipelines wie Debezium und Monitoring-Tools. Genau diese Konten haben oft schwache, selten rotierte Passwörter und dürfen sich in pg_hba.conf von zu vielen Adressen anmelden. Aus meiner Erfahrung mit Identity-Themen ist das der klassische Fall eines „technischen Kontos”, das niemand als privilegiert führt, obwohl es das ist. Wer so ein Konto kompromittiert, bekommt mit PostGREShell den kompletten Server.

Der zweite Punkt betrifft das Patch-Management: Dieses Update ist kein „einspielen und fertig”. Wer wal2json, decoderbufs oder ein anderes Nicht-Standard-Plugin nutzt, dem verweigert PostgreSQL nach dem Update das Logical Decoding, bis der Administrator die Bibliothek in die Positivliste einträgt. Genau das erwähnen manche Distributions-Hinweise nicht – Ubuntus USN-8653-1 spricht laut The Hacker News nur von einem Neustart. Wer das Update ungeprüft in der Nacht durchlaufen lässt, hat morgens stehende CDC-Pipelines. Zudem gibt es noch eine offene Kante: pg_createsubscriber prüft den neuen Parameter nicht, der --dry-run läuft durch, die echte Umstellung scheitert. Ein Patch dafür war am 4. September noch in Prüfung.

Praxis-Tipps: So gehst du das Update an

• Erst inventarisieren: Vor dem Update SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; ausführen. Das zeigt alle Output-Plugins, die je erfolgreich genutzt wurden.
• Dann updaten: Auf 18.6, 17.11, 16.15, 15.19 oder 14.24 beziehungsweise das entsprechende Distributionspaket. PostgreSQL 14 bekommt ab 12. November 2026 keine Fixes mehr – wer noch darauf läuft, sollte die Migration einplanen.
• Positivliste pflegen: Alle Nicht-Standard-Plugins in output_plugin_libraries eintragen und mit SELECT pg_reload_conf(); nachladen. Ein Neustart ist nicht nötig. Im Serverlog erkennst du Blockaden an der Meldung „library … may not be used as an output plugin”.
• Replikationskonten aufräumen: Das REPLICATION-Attribut von allen Konten entfernen, die es nicht zwingend brauchen. Verbliebene Konten in pg_hba.conf auf feste Quelladressen beschränken und starke Passwörter oder Zertifikate erzwingen.
• Netzwerk härten: Ausgehendes SMB (Port 445) und NFS (Port 2049) von Datenbankservern blockieren, autofs deaktivieren, wo es nicht gebraucht wird. Das verhindert genau den Windows-Angriffspfad ohne Dateiablage.
• Backups gegenprüfen: Da Backup-Tools oft die betroffenen Konten nutzen, lohnt ein Blick, ob diese Zugänge nur von Backup-Hosts aus erreichbar sind. Zum Thema Datensicherung siehe auch unseren Ratgeber zu verschlüsselten USB-Sticks und externen SSDs 2026.

Eine ähnlich alte Lücke in weit verbreiteter Infrastruktur haben wir im Juli beschrieben: HollowByte – OpenSSL-Sicherheitslücke lähmt Server mit 11 Bytes.

Fazit

PostGREShell ist kein Zero-Day mit laufenden Angriffen, sondern ein Lehrstück über unterschätzte Servicekonten. Das Update gehört auf die Liste – aber mit Inventur davor und Positivliste danach. Und die Frage „Wer hat bei uns eigentlich REPLICATION?” sollte man sich unabhängig von dieser CVE einmal im Jahr stellen.

Quellen

• PostgreSQL Security Advisory: CVE-2026-6471 – logical decoding can dlopen arbitrary file
• PostgreSQL: 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released (13. August 2026)
• Cyera Research: PostGREShell – The database powering much of the internet had an open door for 12 years (1. September 2026)
• The Hacker News: PostgreSQL Fixes 12-Year-Old Logical Decoding Flaw (4. September 2026)