PostgreSQL: Schwachstelle im Logical Decoding ermöglicht Codeausführung als Benutzer `postgres`

PostgreSQL hat CVE-2026-6471 behoben, eine Schwachstelle im Logical-Decoding-System, über die beliebige Shared Libraries auf dem Datenbankserver geladen werden können.

Dafür sind keine Superuser-Rechte erforderlich. Der Angreifer benötigt jedoch ein PostgreSQL-Konto mit dem Attribut REPLICATION, während der Server mit wal_level = logical konfiguriert sein muss.

Nach dem Laden der Bibliothek wird der Code innerhalb des Backend-Prozesses mit der Identität des Systemkontos ausgeführt, unter dem PostgreSQL läuft – normalerweise postgres. Zu den möglichen Folgen gehören daher der Diebstahl oder die Manipulation von Daten, ein Ausfall des Dienstes, eine Rechteausweitung und die Einrichtung von Persistenz auf dem System.

Die von den Forschern von Cyera PostGREShell getaufte Schwachstelle erreicht einen CVSS-3.1-Score von 7,2 und ist als fehlende Autorisierungskontrolle (CWE-862) klassifiziert. Vladimir Tokarev und Yu Kunpeng wurden vom PostgreSQL Global Development Group als Hinweisgeber genannt. Tokarev veröffentlichte am 1. September eine technische Analyse.

Welche PostgreSQL-Versionen aktualisiert werden müssen

Die am 13. August veröffentlichten Upstream-Releases, die CVE-2026-6471 beheben, sind:

• PostgreSQL 18.6
• PostgreSQL 17.11
• PostgreSQL 16.15
• PostgreSQL 15.19
• PostgreSQL 14.24

Verwundbar sind die jeweils vorherigen Versionen dieser fünf Zweige. Der Advisory des Projekts betrifft damit die weiterhin unterstützten Serien 14 bis 18.

Der Fehler geht jedoch auf die Einführung des Logical Decoding in PostgreSQL 9.4 im Jahr 2014 zurück. Serien vor Version 14 werden im aktuellen Upstream-Hinweis nicht behandelt. Wer sie einsetzt, sollte daher die Migration auf eine unterstützte Version planen, statt das Fehlen in der Liste als Sicherheitsnachweis zu betrachten.

Korrigierte Pakete sind auch für Amazon RDS, Debian, SUSE und Ubuntu verfügbar. Der am 20. August 2026 veröffentlichte Ubuntu-Hinweis USN-8653-1 stellt folgende Versionen bereit:

Ubuntu	Korrigiertes Paket
26.04 LTS	postgresql-18 18.6-0ubuntu0.26.04.1
24.04 LTS	postgresql-16 16.15-0ubuntu0.24.04.1
22.04 LTS	postgresql-14 14.24-0ubuntu0.22.04.1

Ubuntu verlangt nach dem regulären Sicherheitsupdate einen Neustart von PostgreSQL. Das Paket behebt außerdem zahlreiche weitere Schwachstellen, nicht nur die Lücke im Logical Decoding.

PostgreSQL 14 wird zudem ab dem 12. November 2026 keine weiteren Fehlerkorrekturen mehr erhalten. Organisationen, die noch diesen Zweig einsetzen, sollten daher auch den Wechsel auf ein neueres Release in ihre Betriebsplanung aufnehmen.

Vom Plugin-Namen zu dlopen(): So läuft der Angriff ab

Logical Decoding übersetzt die im Write-Ahead-Log aufgezeichneten Änderungen in ein Format, das externe Systeme verarbeiten können. Es wird beispielsweise in Change-Data-Capture-Pipelines und von Tools eingesetzt, die Änderungen an andere Plattformen übertragen.

Beim Erstellen eines Replikations-Slots, auch über CREATE_REPLICATION_SLOT, kann der Client das zu verwendende Output-Plugin angeben. Vor der Behebung prüfte PostgreSQL nicht ausreichend, ob ein Benutzer mit REPLICATION zum Laden der angeforderten Bibliothek berechtigt war.

Der Plugin-Name gelangte dadurch bis zur Funktion für das dynamische Laden. Der Parser des Replikationsprotokolls akzeptierte in Anführungszeichen eingeschlossene Namen mit Verzeichnistrennern, absoluten Pfaden und Traversierungssequenzen wie ../.

Die Folge war ein Aufruf von dlopen() für eine vom Angreifer ausgewählte Datei, sofern sie für das Betriebssystemkonto zugänglich war, unter dem PostgreSQL ausgeführt wird. Die Bibliothek wurde in den Speicherbereich des Backend-Prozesses geladen, und ihr Code erhielt die Rechte des Benutzers postgres.

Die normalen Einschränkungen, die der SQL-Befehl LOAD auf Nicht-Superuser anwendet, galten für diesen Pfad nicht. Eine bereits vorhandene Schutzmaßnahme ließ sich somit über das Replikationsprotokoll umgehen.

Ob die Schadbibliothek verfügbar gemacht werden kann, hängt von der Plattform ab:

• unter Windows kann der Pfad auf eine vom Angreifer kontrollierte SMB-Freigabe zeigen, ohne dass die Datei zuvor auf den Server kopiert werden muss;
• unter Linux und macOS setzt ein vergleichbares Laden über das Netzwerk voraus, dass der NFS-Automount aktiviert ist;
• in allen anderen Szenarien muss der Angreifer bereits über eine Möglichkeit verfügen, die Bibliothek auf die Festplatte des Servers zu schreiben.

In den Tests von Cyera veränderte der geladene Code den Rollenkatalog direkt und machte aus dem Replikationskonto einen PostgreSQL-Superuser. Die Forscher entwickelten außerdem drei Formen von Persistenz, die einen Neustart überstehen können.

Erforderlich ist kein Superuser-Recht, das Privileg bleibt jedoch sensibel

Der vollständige für die Schwachstelle vergebene Vektor lautet CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. Er beschreibt einen aus der Ferne ausführbaren Angriff mit geringer Komplexität und ohne Interaktion des Benutzers, der jedoch erhöhte Rechte voraussetzt.

Die Einstufung PR:H kann im Widerspruch dazu stehen, dass das Konto kein Administrator sein muss. Tatsächlich beschreibt sie eine konkrete Voraussetzung: Das Attribut REPLICATION muss bereits vergeben worden sein.

Dieses Privileg wird häufig technischen Konten zugewiesen, die von Standby-Servern, Backup-Lösungen, CDC-Plattformen und Überwachungssystemen verwendet werden. Die Kompromittierung eines solchen Kontos kann daher in eine Codeausführung auf Betriebssystemebene münden.

Bis zum 4. September wurden in den untersuchten Repositorys keine öffentlichen Proofs of Concept gefunden. Zu diesem Zeitpunkt war CVE-2026-6471 außerdem nicht im Katalog der CISA Known Exploited Vulnerabilities aufgeführt und hatte keine zugehörige KEV-Frist.

Es gibt daher keine öffentlichen Hinweise auf eine aktive Ausnutzung. Die Auswirkungen bleiben dennoch erheblich, insbesondere wenn Dienstkonten gemeinsam genutzt, nur unzureichend überwacht oder zum Verbindungsaufbau aus weitreichenden Netzbereichen berechtigt sind.

Der Patch führt eine Whitelist für Output-Plugins ein

Die Korrektur ergänzt den Serverparameter:

output_plugin_libraries

Der Standardwert autorisiert zwei Bibliotheken:

pgoutput, test_decoding

Nach dem Update müssen Plugins von Drittanbietern wie wal2json und decoderbufs ausdrücklich in die Whitelist aufgenommen werden. Andernfalls können Slots, die diese Plugins verwenden, das Logical Decoding nicht ordnungsgemäß starten.

Vor der Installation des Patches können Administratoren mit folgendem Befehl ermitteln, welche Plugins bereits mit Slots verknüpft sind:

SELECT DISTINCT plugin
FROM pg_replication_slots
WHERE plugin IS NOT NULL;

Die Abfrage gibt Plugins zurück, die mindestens einmal erfolgreich verwendet wurden. Konfigurierte, aber noch nicht aktivierte Integrationen werden damit möglicherweise nicht vollständig erfasst.

Nach der Aktualisierung von PostgreSQL muss jedes zulässige Plugin, das nicht im Standardwert enthalten ist, zu output_plugin_libraries hinzugefügt werden. Die Konfiguration kann anschließend mit folgendem Befehl neu geladen werden:

pg_ctl reload

oder:

SELECT pg_reload_conf();

Die Änderung des Parameters allein erfordert keinen Neustart. Strengere Vorgaben der jeweiligen Distribution bleiben davon unberührt, etwa der nach dem Ubuntu-Update vorgesehene Neustart.

PostgreSQL hat sich für eine Whitelist statt für eine bloße Erweiterung der LOAD-Regeln entschieden. Letztere Lösung hätte erfordert, alle externen Plugins unter $libdir/plugins zu installieren, und zahlreiche bestehende Konfigurationen unterbrochen.

Ein operatives Problem ist weiterhin offen. pg_createsubscriber erstellt Slots mit pgoutput, ohne den neuen Parameter zu prüfen: --dry-run kann erfolgreich sein, während der eigentliche Vorgang fehlschlägt, wenn die Whitelist das Plugin ausschließt. Am 4. September befand sich ein von Hayato Kuroda von Fujitsu eingereichter Patch noch in der Prüfung.

Bei Migrationen von PostgreSQL 17 oder späteren Releases muss die Whitelist des neuen Clusters außerdem vor der Ausführung von

pg_upgrade --check

konfiguriert werden.

Andernfalls kann die Prüfung fehlschlagen, wenn bestehende Slots von nicht autorisierten Plugins abhängen.

Sofortmaßnahmen, Mitigations und zu prüfende Anzeichen

Wenn der Patch nicht sofort eingespielt werden kann, sollten Administratoren REPLICATION von Konten entziehen, für die kein dokumentierter Bedarf besteht, und die in pg_hba.conf für Replikationsverbindungen zugelassenen Adressen einschränken.

Außerdem sollte von den Datenbankservern ausgehender SMB-Datenverkehr über Port 445 und NFS-Datenverkehr über Port 2049 blockiert werden, sofern beides nicht erforderlich ist. autofs sollte auf Systemen deaktiviert werden, die es nicht verwenden.

Nach dem Update erzeugen Versuche, von der Whitelist ausgeschlossene Plugins zu laden, einen Logeintrag mit folgendem Inhalt:

may not be used as an output plugin

Die Meldung kann auf eine noch nicht angepasste legitime Konfiguration hinweisen, aber auch auf den Versuch, eine nicht autorisierte Bibliothek zu laden. Sie sollte daher mit dem Konto, der Quelladresse und dem Namen der angeforderten Datei korreliert werden.

Die Analyse sollte außerdem folgende Punkte umfassen:

• Konten mit dem Attribut REPLICATION;
• in pg_replication_slots aufgeführte Slots;
• mit den Slots verknüpfte Plugins;
• unerwartete Änderungen am Rollenkatalog;
• neue Formen von Persistenz, die vom Betriebskonto der Datenbank angelegt wurden;
• ungewöhnliche SMB- oder NFS-Verbindungen, die vom PostgreSQL-Server ausgehen.

Oberste Priorität hat die Installation eines korrigierten Releases. Die Whitelist reduziert die Angriffsfläche, ohne eine vollständige Neuorganisation der Plugins zu erzwingen. Sie erfordert jedoch ein sorgfältiges Inventar, damit es nicht zu Unterbrechungen in Replikations- und Change-Data-Capture-Pipelines kommt.