CVE-2026-6471: Kritische PostGREShell-Lücke in PostgreSQL erlaubt Codeausführung über Logical Decoding

Unter dem Namen PostGREShell wurde eine Schwachstelle in PostgreSQL öffentlich, die als CVE-2026-6471 geführt wird und laut Security Affairs sowie Cyera mit einem CVSS-Wert von 7.2 bewertet ist. Betroffen sind alle PostgreSQL-Versionen vor 18.6, 17.11, 16.15, 15.19 und 14.24. Auch die älteren, nicht mehr regulär unterstützten Reihen 9.4 bis 13 sind historisch betroffen, erhalten aber keine offiziellen Patches mehr. Der Angriffspfad führt über das Logical-Decoding-Feature: Ein Datenbankkonto ohne Superuser-Rechte, das lediglich das REPLICATION-Attribut besitzt, kann einen frei wählbaren Pfad für ein Output-Plugin angeben. PostgreSQL lädt diese Bibliothek per dlopen unter Linux beziehungsweise LoadLibrary unter Windows, ohne die Herkunft ausreichend zu prüfen. Dadurch lässt sich beliebiger Code im Kontext des PostgreSQL-Serverprozesses ausführen.

Gesichert ist laut den zitierten Herstellerangaben, dass die Lücke seit 2014 im Code vorhanden ist und eine gültige REPLICATION-Rolle mit Zugriff auf Logical Decoding beziehungsweise Replication-Funktionen voraussetzt. Ebenfalls gesichert ist, dass die betroffene Bibliothek für das Betriebssystemkonto, unter dem PostgreSQL läuft, lesbar sein muss, was den Angriff auf Umgebungen mit laxer Dateisystemtrennung oder mehrstufigen Anwendungen begünstigt. Unsicher beziehungsweise nicht bestätigt ist bislang eine aktive Ausnutzung in freier Wildbahn, keine der genannten Quellen berichtet von konkreten Exploit-Kampagnen. Die Dringlichkeit ist dennoch hoch, da die Folgen bei erfolgreicher Ausnutzung gravierend sind und Patches bereits verfügbar sind. Administratoren sollten umgehend prüfen, welche Konten REPLICATION-Rechte besitzen, ob Logical-Decoding-Funktionen aktiv genutzt werden, und danach zügig auf die reparierten Versionen aktualisieren.

Was ist PostGREShell konkret?

PostGREShell bezeichnet eine fehlende Autorisierungsprüfung im Logical-Decoding-Subsystem von PostgreSQL. Logical Decoding erlaubt es, Änderungen am Write-Ahead-Log in ein lesbares Format zu übersetzen, etwa für Replikation oder Change-Data-Capture-Lösungen. Dafür können Nutzer sogenannte Output-Plugins angeben, die als geladene Bibliotheken arbeiten. Der Fehler liegt darin, dass PostgreSQL nicht ausreichend validiert, ob der angegebene Plugin-Pfad tatsächlich vertrauenswürdig ist. Ein Konto mit REPLICATION-Attribut, aber ohne Superuser-Status, kann dadurch eine beliebige, für das PostgreSQL-Betriebssystemkonto sichtbare Bibliothek referenzieren und laden lassen.

Wer ist betroffen?

Die Schwachstelle betrifft PostgreSQL-Installationen der folgenden Versionslinien vor dem jeweiligen Patch-Release:

Wichtig ist die Voraussetzung: Ein Angreifer benötigt bereits ein Datenbankkonto mit REPLICATION-Rolle und Zugriff auf Logical-Decoding- oder Replication-Funktionen. Ohne diese Vorbedingung lässt sich die Lücke nicht ausnutzen. In der Praxis betrifft das vor allem Umgebungen, in denen Replikationskonten breiter vergeben wurden als nötig, etwa für Monitoring-Tools, ETL-Pipelines oder Change-Data-Capture-Systeme wie Debezium.

Angriffsablauf im Überblick

• Angreifer verfügt über ein Datenbankkonto mit dem Attribut REPLICATION
• Zugriff auf Logical-Decoding-Funktionen oder Replication-Slots ist gegeben
• Angreifer gibt beim Erzeugen eines Replication-Slots einen frei gewählten Output-Plugin-Namen beziehungsweise Pfad an
• PostgreSQL lädt die referenzierte Bibliothek per dlopen unter Linux oder LoadLibrary unter Windows
• Die Bibliothek muss lediglich für das Betriebssystemkonto des PostgreSQL-Prozesses lesbar sein
• Beim Laden wird der Code der Bibliothek im Kontext des PostgreSQL-Serverprozesses ausgeführt
• Der ausgeführte Code läuft mit den Rechten des Datenbankprozesses, nicht mit denen des angreifenden Kontos

Mögliche Folgen einer Ausnutzung

Da PostgreSQL-Prozesse häufig mit weitreichenden Rechten auf dem Host laufen und direkten Zugriff auf sensible Daten haben, sind die potenziellen Folgen erheblich:

• Ausführung beliebigen Codes im Betriebssystemkontext des Datenbankservers
• Eskalation auf Superuser-Rechte innerhalb der Datenbank
• Einrichtung einer persistenten Backdoor im Datenbanksystem
• Zugriff auf alle Tabelleninhalte, kryptografische Schlüssel und Dateien im Prozesskontext
• Kompromittierung angebundener Systeme, sofern die Datenbank als Sprungbrett dient
• Datenexfiltration und Manipulation von Datenbeständen ohne reguläre Protokollierung

Wie lässt sich die eigene Umgebung prüfen?

Vor dem Patchen empfiehlt sich eine kurze Bestandsaufnahme, um das tatsächliche Risiko in der eigenen Umgebung einzuschätzen und verdächtige Aktivitäten frühzeitig zu erkennen.

• Alle Rollen mit dem Attribut REPLICATION per pg_roles auflisten und Notwendigkeit prüfen
• Aktive Replication-Slots und deren zugeordnete Output-Plugins kontrollieren
• PostgreSQL-Serverlogs auf ungewöhnliche Slot-Erstellungen oder Plugin-Namen durchsuchen
• Dateisystem auf unbekannte oder kürzlich veränderte Bibliotheken im Suchpfad des Servers prüfen
• pg_hba.conf und Netzwerkzugriffsregeln für Replication-Verbindungen dokumentieren

Empfohlene Sofortmaßnahmen

Da für alle unterstützten Versionslinien bereits Patches vorliegen, sollte die Aktualisierung priorisiert erfolgen. Ergänzend dazu sind folgende Maßnahmen sinnvoll:

• Umgehendes Update auf PostgreSQL 18.6, 17.11, 16.15, 15.19 oder 14.24, je nach eingesetzter Versionslinie
• Inventarisierung aller Konten mit REPLICATION-Attribut und Entzug bei nicht zwingender Notwendigkeit
• Einschränkung des Netzzugriffs auf Replication-Verbindungen über pg_hba.conf und Firewall-Regeln
• Überprüfung genutzter Output-Plugins und bestehender Replication-Slots auf Plausibilität
• Kontrolle von Logs und Dateisystem auf Anomalien im Umfeld der Datenbankprozesse
• Rotation von Zugangsdaten und Zertifikaten bei Verdacht auf Kompromittierung
• Migration von Alt-Instanzen auf Versionen 9.4 bis 13 auf unterstützte Releases, da diese keine Patches mehr erhalten

Einordnung und Ausblick

PostGREShell zeigt, wie lange Autorisierungsluecken in weit verbreiteter Infrastruktur unentdeckt bleiben können, die Schwachstelle existiert nach aktuellem Kenntnisstand seit 2014. Die Voraussetzung eines bereits vorhandenen REPLICATION-Kontos senkt zwar die unmittelbare Breitenwirkung, macht die Lücke aber besonders relevant für Umgebungen mit vielen Integrationen, in denen Replikationsrechte großzügig vergeben wurden. Wer PostgreSQL im eigenen Rechenzentrum oder als verwaltete Instanz betreibt, sollte die Patch-Verfügbarkeit als Anlass nehmen, sämtliche Rollen und Zugriffsrechte grundsätzlich zu überprüfen. Weiterführende Hinweise zur sicheren Installation und zum Betrieb von PostgreSQL unter Ubuntu bietet der Beitrag zur nativen Installation und Absicherung über PGDG-Repositories. Für den Ernstfall einer notwendigen Wiederherstellung nach einem Sicherheitsvorfall lohnt sich ein Blick auf Backup- und Migrationsstrategien mit pg_dump und pg_restore. Wer im Zuge der Überprüfung auch die Performance der eigenen Instanz im Blick behalten möchte, findet Grundlagen im Artikel zum Performance-Tuning für Einsteiger.

Quellen

• PostgreSQL Security Advisory zu CVE-2026-6471
• Security Affairs: PostgreSQL hit by 12 year old vulnerability
• The Hacker News: PostgreSQL fixes 12 year old logical decoding flaw