PostgreSQL hat ein Sicherheitsupdate veröffentlicht, das eine seit zwölf Jahren bestehende Schwachstelle in der logischen Dekodierung schließt. Die als CVE‑2026‑6471 mit einem CVSS‑Score von 7,2 eingestufte Lücke erlaubt es einem Kontoinhaber mit dem REPLICATION‑Attribut, beliebigen Code auf dem Betriebssystem des Datenbankservers auszuführen. Betroffen sind alle Versionen vor PostgreSQL 18.6, 17.11, 16.15, 15.19 und 14.24 – die Sicherheitslücke existiert seit der Einführung der logischen Dekodierung in PostgreSQL 9.4 im Jahr 2014.
Schwachstelle in der logischen Dekodierung: REPLICATION‑Benutzer können Plugin‑Pfade manipulieren
Die Schwachstelle basiert darauf, dass die logische Dekodierung einen vom Benutzer bereitgestellten Plugin‑Namen aus dem CREATE_REPLICATION_SLOT‑Befehl direkt an die Funktion übergibt, die die Bibliothek lädt. Die bestehende Pfadeinschränkung von PostgreSQL, die Nicht‑Superuser auf ein einziges, vom Administrator kontrolliertes Verzeichnis begrenzt, wird beim Replikationspfad nicht angewendet. Der Parser des Replikationsprotokolls akzeptiert nahezu jedes Zeichen innerhalb eines doppelt‑angeführten Plugin‑Namens, einschließlich Pfadtrennern und ../‑Traversierung. Ein vollständiger Dateisystempfad gelangt daher ungeprüft zum Lader.
Die Sicherheitsforscher Vladimir Tokarev und Yu Kunpeng entdeckten die Lücke und veröffentlichten am 1. September eine detaillierte Analyse unter dem Namen PostGREShell. Für die Ausnutzung ist ein Konto mit dem REPLICATION‑Attribut erforderlich – ein Recht, das Backup‑Tools, Standby‑Server, Change‑Data‑Capture‑Pipelines (CDC) und Überwachungssysteme routinemäßig besitzen. Zudem muss der Server mit wal_level = logical laufen.
Betriebssystemabhängige Angriffspfade
Auf Windows löst der Server den Pfad über Server Message Block (SMB) auf und lädt die Bibliothek von einer Maschine, die der Angreifer kontrolliert – ohne dass eine Datei auf dem Ziel geschrieben werden muss. Unter Linux und macOS erfordert derselbe Effekt, dass Network File System (NFS) per Automount eingebunden ist. In allen anderen Fällen benötigt der Angreifer eine vorhandene Möglichkeit, eine Datei auf die Platte des Servers zu schreiben. Der geladene Code läuft im Datenbank‑Backend‑Prozess mit den Rechten des Betriebssystem‑Benutzers postgres.
Der von Cyera Research entwickelte Test‑Plugin schrieb anschließend direkt in die Rollenkatalog‑Tabelle, um das REPLICATION‑Konto zu einem PostgreSQL‑Superuser zu machen. Zusätzlich installierte der Exploit drei Persistenzmechanismen, die einen Server‑Neustart überleben.
Der Fix: Whitelist für Output‑Plugins
Das am 13. August ausgelieferte Update führt den Server‑Parameter output_plugin_libraries ein. Dieser listet explizit auf, welche Bibliotheken als logische Dekodierungs‑Output‑Plugins geladen werden dürfen. Voreingestellt ist ‚pgoutput, test_decoding‘. Installationen, die andere Output‑Plugins wie wal2json oder decoderbufs verwenden, werden nach dem Update die logische Dekodierung verweigern, bis ein Administrator die entsprechende Bibliothek zur Liste hinzufügt und die Konfiguration neu lädt.
Jacob Champion, der den Fix beisteuerte, erläuterte im Commit, dass eine nachträgliche Anwendung der standardmäßigen LOAD‑Einschränkungen auf den Replikationspfad dazu geführt hätte, dass alle Drittanbieter‑Plugins im $libdir/plugins‑Verzeichnis installiert werden müssten. Die Whitelist‑Lösung vermeidet diesen Bruch mit bestehenden Konfigurationen. Fehlgeschlagene Ladeversuche erscheinen im Server‑Log als ERROR: library „…“ may not be used as an output plugin, zusammen mit einem Hinweis auf den Parameter.
Maßnahmen für Administratoren
Um die Aktualisierung vorzubereiten und durchzuführen, empfiehlt das PostgreSQL‑Projekt vier Schritte:
- Vor dem Update mit SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; ermitteln, welche Output‑Plugins in den vorhandenen Replikations‑Slots verwendet werden – der Befehl zeigt nur Plugins, die tatsächlich erfolgreich genutzt wurden.
- Auf eine der Versionen 18.6, 17.11, 16.15, 15.19 oder 14.24 aktualisieren – oder auf das entsprechende Distributionspaket.
- Nach dem Update jedes nicht‑standardmäßige Plugin zu output_plugin_libraries hinzufügen und die Konfiguration mit pg_ctl reload oder SELECT pg_reload_conf() neu laden. Ein Neustart ist nicht erforderlich.
- Bei einer Migration mit pg_upgrade –check ab Version 17 muss der neue Cluster den Parameter bereits vor dem Prüflauf setzen, da der Check fehlschlägt, wenn die Liste die Plugins des alten Clusters nicht erlaubt.
Die korrigierten Pakete sind über Amazon RDS, Debian, SUSE und Ubuntu verfügbar. Ubuntu lieferte den Fix in USN‑8653‑1 am 20. August aus, erwähnte den neuen Parameter jedoch nicht und wies lediglich auf einen Neustart nach dem Update hin. Debian warnte in seinem Advisory, dass der Fix zusätzliche Konfigurationsänderungen erfordert, falls Erweiterungen wie wal2json oder decoderbufs eingesetzt werden. Das wal2json‑Projekt hat seine Dokumentation aktualisiert und verweist auf die CVE sowie die Notwendigkeit, das Plugin in output_plugin_libraries einzutragen.
Noch offene Lücken und Risiken
Eine Lücke in der aktuellen Fix‑Version ist noch offen: Der Befehl pg_createsubscriber erstellt Replikations‑Slots mit dem Plugin pgoutput, ohne den neuen Parameter zu überprüfen. Hayato Kuroda von Fujitsu wies im pgsql‑hackers‑Mailverteiler darauf hin, dass der Trockenlauf (–dry‑run) erfolgreich sein kann, während die eigentliche Umwandlung fehlschlägt – ein für Administratoren überraschendes Verhalten. Ein Patch für dieses Problem befand sich am 4. September noch in der Überprüfung und war noch nicht übernommen.
CVE‑2026‑6471 war zum 4. September nicht im KEV‑Katalog der US‑Behörde CISA gelistet. Ebenfalls wurde bis zu diesem Datum kein öffentlicher Proof‑of‑Concept‑Code in öffentlichen Repositories gefunden. Bis das Update eingespielt werden kann, empfehlen die Forscher, das REPLICATION‑Attribut auf unbedingt notwendige Konten zu beschränken, die Replikationseinträge in der Datei pg_hba.conf auf bekannte Adressen zu begrenzen, ausgehenden SMB‑ (Port 445) und NFS‑Datenverkehr (Port 2049) von Datenbankservern zu blockieren sowie den Autofs‑Dienst zu deaktivieren, wo er nicht benötigt wird.
Die zwölf Jahre alte Schwachstelle zeigt, wie tief verwurzelte Designentscheidungen in der Replikationsinfrastruktur selbst nach langer Zeit zu kritischen Sicherheitsproblemen führen können. Der gewählte Ansatz – eine explizite Whitelist statt einer nachträglichen Pfadrestriktion – gewährleistet Abwärtskompatibilität, verlangt aber von den Betreibern ein aktives Konfigurationsmanagement. Für Unternehmen, die auf Change Data Capture oder skalierte Backup‑Lösungen angewiesen sind, bleibt die Umstellung eine zeitkritische Aufgabe, bevor erste Exploits in freier Wildbahn auftauchen.
