PostGREShell: Eine PostgreSQL-Schwachstelle macht Replikationskonten zum Sprungbrett für die Codeausführung

Eine Schwachstelle im logischen Replikationssystem von PostgreSQL ermöglicht es einem Konto mit dem Attribut REPLICATION, beliebigen Code in den Datenbankprozess zu laden. Der als CVE-2026-6471 geführte und von Cyera PostGREShell getaufte Fehler erhielt einen CVSS-Score von 7.2.

Für den Angriff sind keine anfänglichen PostgreSQL-Superuser-Rechte erforderlich. Benötigt wird jedoch ein für die Replikation autorisiertes Konto – eine Berechtigung, die häufig an Backup-Software, Standby-Server, Pipelines und Monitoring-Plattformen vergeben wird.

Nach dem Laden wird der Schadcode mit den Rechten des Betriebssystemkontos ausgeführt, unter dem PostgreSQL läuft. Von dort aus kann er auch interne Mechanismen der Datenbank manipulieren und sich dauerhaft Superuser-Rechte verschaffen.

Mit Stand vom 4. September 2026 liegen keine Informationen vor, die eine Einstufung von CVE-2026-6471 als Schwachstelle im Known Exploited Vulnerabilities-Katalog der CISA ermöglichen. Eine CISA-Frist für die Behebung ist daher nicht bekannt.

Die Schwachstelle liegt in der Auswahl des Logical-Decoding-Plugins

Die Schwachstelle betrifft das Logical Decoding – eine Funktion, die von der logischen Replikation verwendet wird, um in der Datenbank protokollierte Änderungen in einen von externen Anwendungen interpretierbaren Datenstrom umzuwandeln.

Wenn ein Client eine Sitzung für die logische Replikation öffnet, erstellt er einen Slot und gibt an, welches Output-Plugin die Ereignisse verarbeiten soll. PostgreSQL muss daraufhin die entsprechende Bibliothek finden und laden.

Das Problem ist eine fehlende Autorisierungsprüfung, die als CWE-862, Missing Authorization klassifiziert wird. Ein Benutzer ohne Superuser-Rechte, der über das Attribut REPLICATION verfügt, kann anstelle eines regulären, autorisierten Plugins eine beliebige Datei angeben.

Laut der technischen Analyse von Cyera akzeptiert der Protokollparser im Namen des in doppelte Anführungszeichen gesetzten Plugins verschiedene Zeichen, mit denen sich ein Pfad erzeugen lässt:

• Schrägstriche und Backslashes;
• Punkte;
• Verzeichnis-Traversal-Sequenzen wie ../;
• UNC-Pfade, wie sie in Windows-Umgebungen verwendet werden.

Der Name wird ohne ausreichende Validierung an den Loader weitergegeben. Ein Angreifer kann dadurch einen vollständigen Pfad an dlopen() übergeben, anstatt sich auf den Namen einer in der Konfiguration vorgesehenen Bibliothek zu beschränken.

Die Payload wird in denselben Adressraum wie der PostgreSQL-Prozess geladen. Eine dedizierte Sandbox kommt nicht zum Einsatz, und der Code kann mit den Rechten des laufenden Prozesses auf interne Datenbank-APIs zugreifen.

Ein Konto darf daher nicht allein deshalb als vertrauenswürdig gelten, weil es kein Superuser ist. In diesem Szenario wird REPLICATION zu einer Fähigkeit zur Codeausführung.

Von der Codeausführung im Prozess zur Änderung von pg_authid

Die unmittelbare Auswirkung betrifft das Betriebssystemkonto, unter dem PostgreSQL läuft. Eine schädliche Bibliothek kann alles lesen und verändern, worauf dieser Prozess zugreifen darf, und außerdem direkt in den Betrieb der Datenbank eingreifen.

Cyera beschreibt auch einen Weg zur Erlangung von PostgreSQL-Superuser-Rechten. Das Plugin kann interne Funktionen aufrufen, um als Bootstrap-Superuser zu agieren und pg_authid direkt zu ändern – den Katalog, der sensible Attribute der Konten enthält.

Durch das Setzen der entsprechenden Flags kann der Angreifer eine bestehende Identität dauerhaft in einen Superuser umwandeln. Die Kompromittierung bleibt somit nicht auf die für den Angriff verwendete Replikationssitzung beschränkt.

Mit diesen Rechten werden unter anderem folgende Aktionen möglich:

• Zugriff auf die Tabellen aller gehosteten Datenbanken;
• Änderung von Konfigurationen, Rollen und Objekten;
• Auslesen privater Schlüssel, auf die der PostgreSQL-Prozess zugreifen kann;
• Schreiben von Dateien in für das Betriebskonto zugängliche Pfade;
• Ausführen von Befehlen auf dem Betriebssystem;
• Installieren von Persistenzmechanismen.

Zur Persistenz können das Aktivieren passwortloser Zugänge, das Kopieren der Payload an einen dauerhaften Speicherort und deren Registrierung für das Laden in neuen Backend-Prozessen gehören. Der Code kann Änderungen an den Berechtigungen außerdem nach einem Wiederherstellungsversuch erneut anwenden.

Die alleinige Entziehung der kompromittierten Rolle reicht daher nicht aus. Wurde bereits eine Bibliothek installiert oder registriert, müssen auch das Betriebssystem und die Startmechanismen von PostgreSQL überprüft werden.

Betroffene Versionen und zu installierende Releases

Die Schwachstelle betrifft PostgreSQL. Laut NVD-Beschreibung sind jeweils die Versionen vor den folgenden korrigierten Releases betroffen:

PostgreSQL-Zweig	Erste korrigierte Version
18	18.6
17	17.11
16	16.15
15	15.19
14	14.24

SecurityWeek grenzt den betroffenen Bereich auf PostgreSQL 9.4 bis 18 ein und berichtet, dass Cyera das Problem auch in Version 18.2 verifiziert hat. Es handelt sich somit um eine Schwachstelle, die in Releases vorhanden ist, die seit 2014 verteilt werden.

Eine der CVE-Meldung zugeordnete Zusammenfassung nennt die engere Formulierung postgresql postgresql < 14.24. Diese Angabe steht jedoch im Widerspruch zu den Details des Advisories, das ausdrücklich Korrekturen für die Zweige 15, 16, 17 und 18 aufführt.

Für den operativen Umgang sollten daher folgende Versionen als betroffen betrachtet werden:

• Versionen 18 vor 18.6;
• Versionen 17 vor 17.11;
• Versionen 16 vor 16.15;
• Versionen 15 vor 15.19;
• Versionen 14 vor 14.24.

Für die Zweige 9.4 bis 13 ist kein spezifisches korrigiertes Release angegeben. Organisationen, die diese Versionen einsetzen, müssen dies in ihrer Update-Planung berücksichtigen und dürfen das Fehlen eines aufgeführten Patches nicht als Hinweis darauf interpretieren, dass die Schwachstelle nicht vorhanden ist.

Warum REPLICATION-Konten das Hauptziel sind

Der CVSS-Vektor lautet CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. Der Angriff ist über das Netzwerk erreichbar, weist eine geringe Komplexität auf und erfordert keine Benutzerinteraktion.

Die Anforderung PR:H weist auf die Notwendigkeit weitreichender Berechtigungen hin. Im Fall von PostGREShell bedeutet dies jedoch nicht, dass der Angreifer bereits Datenbankadministrator sein muss: Er muss ein Konto mit dem Attribut REPLICATION kontrollieren.

Solche Zugangsdaten können sich in Backup-Systemen, Pipeline-Secrets, Standby-Servern oder Konfigurationen von Observability-Tools befinden. Eine Organisation könnte sie daher weniger streng schützen als Konten, die ausdrücklich als administrative Konten eingestuft sind.

Die Auswirkungen betreffen sowohl lokale Installationen als auch Datenbanken, die über Unternehmensnetzwerke oder Cloud-Infrastrukturen erreichbar sind. Für die Ausnutzung sind jedoch geeignete Zugangsdaten und die Möglichkeit erforderlich, eine Sitzung für die logische Replikation zu starten oder zu verwenden.

Spezifische Indicators of Compromise wie Hashes, Payload-Namen oder Netzwerkadressen wurden nicht veröffentlicht. Außerdem ist nicht bekannt, ob die Schwachstelle bereits bei realen Angriffen eingesetzt wird.

Update, Rollenprüfung und Suche nach ungewöhnlichen Ladevorgängen

Die wichtigste Maßnahme besteht darin, abhängig vom eingesetzten Zweig PostgreSQL 18.6, 17.11, 16.15, 15.19 oder 14.24 zu installieren. Eine offizielle alternative Umgehungslösung wurde nicht angegeben.

Administratoren sollten anschließend alle Konten mit REPLICATION erfassen und prüfen, ob diese Berechtigung durch einen dokumentierten betrieblichen Bedarf gerechtfertigt ist. Wo sie nicht benötigt wird, sollte sie entzogen werden.

Die Erkennung sollte sich unter anderem auf folgende Aktivitäten konzentrieren:

• ungewöhnliches Erstellen oder Verwenden von Slots für die logische Replikation;
• Replikationssitzungen von unerwarteten Adressen oder Systemen;
• Plugin-Namen mit Pfadtrennzeichen, ../ oder UNC-Pfaden;
• Laden von Bibliotheken aus nicht vorgesehenen Verzeichnissen;
• ungewöhnliche Änderungen an Rollen und Attributen in pg_authid;
• Änderungen an Authentifizierungsregeln, einschließlich passwortloser Verbindungen;
• neue oder veränderte Dateien in Verzeichnissen, auf die der PostgreSQL-Prozess zugreifen kann;
• Konfigurationen, die das dauerhafte Laden von Bibliotheken in neuen Backend-Prozessen bewirken.

Ergeben sich Hinweise auf eine Ausnutzung, sollte die Reaktion nicht auf eine Änderung der Passwörter beschränkt bleiben. Als potenziell kompromittiert gelten die Datenbank, das PostgreSQL-Betriebskonto und alle von diesem Prozess lesbaren Secrets.

Die Rotation der Zugangsdaten muss mit einer Überprüfung geladener Bibliotheken, veränderter Dateien, von Superuser-Rollen und Authentifizierungseinstellungen einhergehen. Erst nach dieser Bereinigung kann das Update den Angriffsvektor schließen, ohne bereits installierte Persistenzmechanismen aktiv zu lassen.