Eine seit rund zwoelf Jahren unentdeckte Schwachstelle in PostgreSQL erlaubt es, ein simples Replikationskonto in einen vollstaendigen Server-Zugriff zu verwandeln. Die von Cyera-Forscher Vladimir Tokarev entdeckte Luecke CVE-2026-6471, getauft „PostGREShell“, fuehrt von niedrig privilegiertem Replikationszugang zu Codeausfuehrung, dauerhaften Superuser-Rechten und einer persistenten Hintertuer.
Ungeprueftes Plugin landet direkt im dlopen
Der Kern liegt im Logical Decoding von PostgreSQL. Beim Anlegen eines Replikations-Slots waehlt der Client den Namen des Ausgabe-Plugins frei aus. Dieser Name wird laut Advisory ohne jede Pruefung an dlopen() beziehungsweise unter Windows an LoadLibrary() weitergereicht. Ueber Pfad-Traversierung oder UNC-Pfade laesst sich so beliebiger kompilierter Code in den PostgreSQL-Prozess laden, der dann mit den Rechten des Systembenutzers postgres laeuft.
Wichtig ist die Voraussetzung: Ein Angreifer benoetigt ein Konto mit dem Attribut REPLICATION, nicht etwa Superuser-Rechte. Zusaetzlich muss der Server mit wal_level = logical laufen. Unter Windows ist der Angriff ueber SMB voll aus der Ferne moeglich, unter Linux teils ueber automatische NFS-Mounts.
Superuser per Katalog-Manipulation und Persistenz
Der eingeschleuste Code kann die interne Tabelle pg_authid direkt manipulieren und sich so Superuser-Status verschaffen. Fuer Dauerhaftigkeit sorgen laut Cyera das Umschreiben der pg_hba.conf, ein Eintrag in shared_preload_libraries sowie wiederholtes Neusetzen der Rechte. Bei einer Suche auf VirusTotal fanden die Forscher bereits 114 boesartige PostgreSQL-Plugins.
Betroffene Versionen und Gegenmassnahmen
Betroffen ist jede Version von 9.4 bis 18; die Luecke mit CVSS-Wert 7,2 wurde in 18.6, 17.11, 16.15, 15.19 und 14.24 geschlossen. Administratoren sollten zeitnah patchen, das REPLICATION-Attribut von nicht benoetigten Konten entfernen, Replikationseintraege in der pg_hba.conf auf bekannte Adressen begrenzen und ausgehenden SMB- (Port 445) sowie NFS-Verkehr (Port 2049) von Datenbankservern blockieren.
Quellen: Cyera Research · SecurityWeek · PostgreSQL Security
