PostgreSQL nutzt ein eigenes Replikationsprotokoll, um mehrere Repliken einer Primärdatenbank für Backup und Wiederherstellung synchron zu halten. Dafür ist ein Konto mit dem Attribut ‘Replication’ erforderlich — und ein solches erhält in der Praxis jedes angebundene Backup-Werkzeug, jeder Server, jede Pipeline und jedes Monitoring-Tool. Änderungen werden von der lokalen Replikation als Tabellenereignisse aufgezeichnet, damit externe Werkzeuge sie auslesen können. Diese legen dazu einen logischen Replikations-Slot an und benennen ein Ausgabe-Plugin, das PostgreSQL lädt, um den Datenstrom zu formatieren.
Wird ein Plugin geladen, führt PostgreSQL dessen Initialisierungsfunktion mit den Rechten des Serverprozesses aus. Um Missbrauch zu verhindern, sollen Konten ohne Superuser-Status Plugins ausschließlich aus einem vom Administrator kontrollierten Verzeichnis laden dürfen. Genau diese Schranke greift nicht: Cyera stellte fest, dass der Plugin-Name ohne Prüfung oder Bereinigung direkt an den Loader durchgereicht wird. Damit lässt sich ein vollständiger Dateisystempfad übergeben, der an dlopen() weitergegeben wird — jene C/C++-Funktion, die dynamisch gemeinsam genutzte Bibliotheken lädt.
“Der Parser des Replikationsprotokolls akzeptiert innerhalb eines in doppelte Anführungszeichen gesetzten Plugin-Namens nahezu jedes Zeichen: Schrägstriche, umgekehrte Schrägstriche, Punkte, ../-Traversierung, sogar Windows-UNC-Pfade”, so Cyera. Angreifer können auf diesem Weg beliebige Dateien laden und ausführen lassen — mit den Rechten des Systembenutzers postgres.
“Über dlopen() geladener Code läuft im selben Adressraum wie PostgreSQL, ohne Sandbox und ohne Prüfung interner API-Aufrufe. Der Server vertraut jedem geladenen Code schlicht”, erläutert das Unternehmen. Der Angriffsweg führt weiter: “Das Plugin ruft eine interne Funktion auf, um für die Sitzung zum Bootstrap-Superuser zu werden, schreibt dann direkt in pg_authid, die Katalogtabelle, die festlegt, wer Superuser ist, und setzt jedes Berechtigungs-Flag auf wahr.”
Damit besitzt der Angreifer dauerhafte Superuser-Rechte: Zugriff auf jede Tabelle in jeder Datenbank, Ausführung von Betriebssystembefehlen, Auslesen privater Schlüssel und Schreiben von Dateien an jedem Ort, auf den der postgres-Prozess zugreifen kann.
Darüber hinaus kann das Plugin laut Cyera Hintertüren einrichten. Es kann Verbindungen ohne Passwort erlauben, sich selbst an einen stabilen Speicherort kopieren und dafür registrieren, in jedes neue Backend erneut geladen zu werden. Selbst eine Rücknahme der Superuser-Änderung wird auf diesem Weg wieder angewendet.
“PostGREShell verwandelt jene Replikations-Zugangsdaten, um die sich niemand Sorgen macht, in Code-Ausführung, Superuser-Rechte und eine dauerhafte Hintertür in der Datenbank, auf der ein großer Teil des Internets läuft”, fasst Cyera zusammen.
Die Korrekturen stehen mit PostgreSQL 18.6, 17.11, 16.15, 15.19 und 14.24 bereit. Cyera rät Organisationen, ihre Instanzen umgehend zu aktualisieren, die Konten mit Replikationsrechten zu prüfen und das Attribut ‘Replication’ bei allen Konten zu entfernen, die es nicht benötigen.