CVE-2026-6471 in PostgreSQL: Risiko durch logisches Decoding

PostgreSQL hat Sicherheitsupdates veröffentlicht, die die Schwachstelle CVE-2026-6471 (CVSS 7.2) im Mechanismus des logischen Decodings beseitigen. Der Fehler ermöglicht es einem Datenbankkonto mit dem Attribut REPLICATION, eine beliebige Bibliothek zu laden und Code unter dem Systembenutzer auszuführen, unter dem der Server läuft. Betroffen sind alle unterstützten Zweige – PostgreSQL 14, 15, 16, 17 und 18 bis einschließlich der Versionen 14.24, 15.19, 16.15, 17.11 bzw. 18.6. Der Fix, der am 13. August 2026 veröffentlicht wurde, führt einen neuen Konfigurationsparameter ein, der nach dem Update die Funktion externer Plugins stören kann, sofern der Administrator keine zusätzliche Konfiguration vornimmt.

Kern der Schwachstelle und Angriffsvektor

Laut dem offiziellen PostgreSQL-Sicherheitsbulletin wird das Problem als fehlende Autorisierung im Serverkern beim logischen Decoding eingestuft. Ein Benutzer mit der Berechtigung REPLICATION konnte eine beliebige ladbare Bibliothek als Output-Plugin angeben – ohne die Prüfungen, die bei normalen Bibliotheksladungen über den Befehl LOAD angewendet werden.

Der offizielle CVSS-Vektor lautet: AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H – Netzwerkangriff, geringe Ausnutzungskomplexität, aber hohe Anforderungen an die Privilegien. Die Auswirkungen werden für alle drei Parameter – Vertraulichkeit, Integrität und Verfügbarkeit – als hoch bewertet. Für eine Ausnutzung müssen zwei Bedingungen erfüllt sein: ein Konto mit dem Attribut REPLICATION und eine Serverkonfiguration mit dem Parameter wal_level = logical.

Das Attribut REPLICATION wird häufig technischen Dienstkonten zugewiesen: Backup-Werkzeugen, Replikationsservern, Pipelines für Change Data Capture (CDC) und Monitoring-Systemen. Das vergrößert die potenzielle Angriffsfläche, obwohl formal ein hohes Privilegienniveau erforderlich ist.

Behebungsmechanismus: Parameter output_plugin_libraries

Wie in den Release Notes zu PostgreSQL 18.6 angegeben, führt der Fix den Serverparameter output_plugin_libraries ein – eine Whitelist von Bibliotheken, die als Output-Plugins für das logische Decoding geladen werden dürfen. Der Standardwert lautet 'pgoutput, test_decoding'.

Das bedeutet, dass nach dem Update jedes externe Plugin – darunter auch die weit verbreiteten wal2json und decoderbufs – vom Server abgelehnt wird, bis der Administrator es explizit zur Liste hinzufügt und die Konfiguration neu lädt. Im Ablehnungsfall erscheint im Serverlog die Meldung: ERROR: library "..." may not be used as an output plugin mit einem Verweis auf den Parameter output_plugin_libraries.

Der Autor des Fixes, Jacob Champion, erläuterte im Commit, dass die standardmäßigen LOAD-Beschränkungen im Replikationspfad bewusst nicht angewendet wurden: Eine nachträgliche Einführung hätte erfordert, dass alle Drittanbieter-Plugins im Verzeichnis $libdir/plugins installiert werden, was bestehende Installationen beschädigt hätte.

Wer ist gefährdet

Die Schwachstelle betrifft jede PostgreSQL-Installation der Versionen 14–18, bei der gleichzeitig zwei Bedingungen erfüllt sind: Es existiert ein Konto mit dem Attribut REPLICATION und der Server läuft mit wal_level = logical. Dies ist eine typische Konfiguration für:

• Systeme der logischen Replikation zwischen PostgreSQL-Clustern
• CDC-Pipelines (Debezium, Kafka Connect und ähnliche)
• Backup-Werkzeuge mit logischem Decoding
• Monitoring-Plattformen, die Replikations-Slots verwenden

Der im Zuge einer Ausnutzung geladene Code wird innerhalb des Serverprozesses unter dem Systemkonto postgres ausgeführt, was dem Angreifer potenziell vollständige Kontrolle über die Daten und die Möglichkeit zur dauerhaften Etablierung im System verschafft.

Praktische Empfehlungen

Die empfohlene Vorgehensweise beim Update gemäß der PostgreSQL-Dokumentation:

1. Erfassung der Plugins – führen Sie vor dem Update die Abfrage SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; aus. Sie zeigt die Plugins an, die jemals erfolgreich verwendet wurden.
2. Update auf PostgreSQL 18.6, 17.11, 16.15, 15.19 oder 14.24. Pakete sind bei den wichtigsten Distributoren verfügbar: Amazon RDS (ab 25. August), Ubuntu (22.04, 24.04, 26.04 LTS), Debian und SUSE.
3. Hinzufügen externer Plugins zu output_plugin_libraries und Neuladen der Konfiguration mit dem Befehl pg_ctl reload oder SELECT pg_reload_conf(); – ein Neustart des Servers ist nicht erforderlich.
4. Bei Migration von PostgreSQL 17 und neuer über pg_upgrade: Setzen Sie output_plugin_libraries im neuen Cluster vor dem Start von pg_upgrade --check, da die Prüfung andernfalls mit einem Fehler endet, wenn Slots des alten Clusters Plugins verwenden, die nicht in der Liste enthalten sind.

Übergangsmaßnahmen vor dem Update

• Entzug des Attributs REPLICATION von Konten, die es nicht benötigen
• Einschränkung der Replikationseinträge in pg_hba.conf auf bekannte IP-Adressen
• Blockieren des ausgehenden Datenbank-Serververkehrs über die Ports 445 (SMB) und 2049 (NFS)

Status der Ausnutzung und offene Fragen

Zum Zeitpunkt der Veröffentlichung ist eine aktive Ausnutzung von CVE-2026-6471 nicht bestätigt. Öffentlicher Code zum Nachstellen des Angriffs wurde in frei zugänglichen Repositorien nicht gefunden. Die Schwachstelle wurde von den Forschern Vladimir Tokarev und Yu Kunpeng entdeckt, wie im offiziellen Release-Ankündigung angegeben.

Es ist zu beachten, dass PostgreSQL 14 – der letzte betroffene Zweig – ab dem 12. November 2026 keine Sicherheitsupdates mehr erhält. Organisationen, die noch mit dieser Version arbeiten, sollten die Migration auf einen neueren Zweig planen.

Ein Update auf die behobenen PostgreSQL-Versionen sollte mit hoher Priorität erfolgen, insbesondere auf Servern mit wal_level = logical. Es ist entscheidend, sich nicht auf die Installation des Patches zu beschränken: Es muss die Liste der verwendeten Output-Plugins geprüft, diese müssen in output_plugin_libraries eingetragen und Funktionstests durchgeführt werden, um sicherzustellen, dass logische Replikation und CDC-Pipelines nach dem Update weiterarbeiten. Wird dieser Schritt ausgelassen, fällt das logische Decoding aus – ein betriebliches Problem, das jedoch vorhersehbar und leicht zu beheben ist.