Ein PostgreSQL-Backup-Konto kann jetzt Code auf Ihrem Server ausführen. Patchen Sie CVE-2026-6471.

Postgres lieferte am 13. August einen Fix für einen Fehler, der seit 2014 im Code schlummerte. CVE-2026-6471 ermöglicht es jedem Konto mit dem REPLICATION-Attribut – der Art von gering privilegiertem Konto, das Ihr Backup-Tool oder Ihr Read-Replica-Server verwendet –, eine beliebige Shared Library in den Datenbankprozess zu laden und Code als Betriebssystembenutzer auszuführen, der Postgres gehört. Die offizielle Meldung beschreibt es klar: Logical Decoding kann mittels dlopen eine beliebige Datei laden, die vom Replikations-Client ausgewählt wird, ohne Autorisierungsprüfung. Cyera Research, das zusammen mit Yu Kunpeng darüber berichtete, nennt es PostGREShell.

Die technischen Details lohnen sich zu verstehen, denn sie erklären auch den Fix. Wenn ein Replikations-Client einen Logical-Decoding-Slot öffnet, gibt er ein Output-Plugin an, und Postgres lädt dieses Plugin als kompilierten Code in seinen eigenen Prozess. Beim normalen SQL-LOAD beschränkt Postgres Nicht-Superuser auf ein kontrolliertes Plugin-Verzeichnis. Der Replikationspfad übersprang diese Prüfung, sodass der Plugin-Name ein beliebiger Pfad auf der Festplatte sein konnte. Unter Windows wird es schlimmer: Der Loader akzeptiert einen UNC-Pfad, sodass ein Angreifer auf eine DLL auf seiner eigenen SMB-Freigabe verweisen und nie eine Datei auf dem Zielsystem ablegen muss.

Hier ist der Teil, der in manchen Berichten untergegangen ist. Der offizielle CVSS-Wert beträgt 7,2 – hoch, aber nicht kritisch –, und der Grund steht direkt im Vektor: PR:H. Sie benötigen ein Konto, das bereits über REPLICATION verfügt. Dies ist keine unauthentifizierte Lücke, die dem offenen Internet zugewandt ist. Warum sollte man sich also darum kümmern? Weil diese Konten in realen Systemen überall vorhanden sind und niemand sie als gefährlich einschätzt. Jede Streaming-Replik, jeder Backup-Job, jede Change-Data-Capture-Pipeline, jeder Monitoring-Agent, der das Write-Ahead-Log verfolgt, läuft als REPLICATION-Rolle. Sie sind das Betriebsgerüst der Infrastruktur, und solche Gerüste tragen tendenziell schwache, langlebige, weit verbreitete Anmeldedaten.

Bei Cloud-Sicherheitsüberprüfungen stoßen wir immer wieder auf dasselbe Muster: ein Replikationsbenutzer, dessen Passwort in drei Env-Dateien und einer Terraform-Variable lebt, wiederverwendet in Staging und Produktion, erreichbar von mehr Teilen des Netzwerks als beabsichtigt. Für sich allein liest sich das wie ein geringfügiger Fund – ein überprivilegiertes Dienstkonto. Dieses CVE verwandelt genau dieses Konto in Remote-Code-Execution auf dem Datenbankhost. Die Lehre gilt nicht wirklich für Postgres. Sie lautet: „Gering privilegierte“ Dienstanmeldedaten bleiben nur so lange gering privilegiert, bis jemand einen Mechanismus findet, der sie aufwertet.

Der Fix ist ein neuer Serverparameter, output_plugin_libraries, hinzugefügt von Jacob Champion. Es handelt sich um eine Allowlist. Standardmäßig erlaubt sie nur die zwei Plugins, die mit Postgres ausgeliefert werden: pgoutput und test_decoding. Ein Replikations-Client kann daher keine beliebige Bibliothek mehr angeben. Wenn Sie einen Drittanbieter-Decoder wie decoderbufs verwenden (Debezium-Nutzer, das betrifft Sie), müssen Sie diesen nach dem Upgrade explizit wieder hinzufügen, sonst bricht die logische Replikation zusammen. Ab Version 17 verweigert pg_upgrade --check den Fortschritt, wenn die Allowlist des neuen Clusters die Plugins Ihrer bestehenden Slots nicht abdeckt. Das ist eine nützliche Sicherheitssperre – und eine Migrationsfalle, die Sie einplanen sollten.

Was diese Woche zu tun ist

1. Patchen Sie auf 18.6, 17.11, 16.15, 15.19 oder 14.24. Ältere Branches haben das End-of-Life überschritten und erhalten diesen Fix nicht. Wenn Sie Version 13 oder früher einsetzen, ist dies ein weiterer Grund für einen Wechsel.
2. Überprüfen Sie, wer REPLICATION innehat. Führen Sie eine echte Bestandsaufnahme durch, keine Schätzung. Jedes menschliche Konto mit diesem Attribut sollte es wahrscheinlich verlieren, und jedes Dienstkonto, das es behält, benötigt ein rotiertes, eindeutiges Passwort.
3. Blockieren Sie ausgehende SMB- und NFS-Verbindungen von Ihren Datenbankhosts. Der Windows-Remote-DLL-Pfad setzt voraus, dass die Datenbank die Dateifreigabe eines Angreifers erreicht. Ihr Postgres-Server hat keinen Grund, ausgehende SMB-Verbindungen zu öffnen. Sperren Sie diese an der Firewall.
4. Wenn Sie output_plugin_libraries manuell festlegen, listen Sie genau die von Ihnen verwendeten Decoder auf – und nichts anderes.

Eine Sache ist prüfenswert, eine andere kann ignoriert werden. Die Bedrohungsanalyse von Cyera fand 114 bösartige Postgres-Plugins auf VirusTotal: Trojaner, Miner, Reverse Shells. Das ist eine Erinnerung daran, dass das Plugin-Laden ein beliebtes Angriffsziel ist, aber keines dieser Beispiele wurde mit der Ausnutzung dieses spezifischen CVE in Verbindung gebracht. Lesen Sie es also nicht als Beweis, dass Sie betroffen waren. Ignorieren Sie hingegen: die Rahmung „zwölf Jahre ungepatcht“. Die Schwachstelle war lange real, aber ihre Ausnutzung erfordert immer noch ein REPLICATION-Konto. Wenn Sie diese gesichert gehalten haben, waren Sie nie so exponiert wie die Überschrift vermuten lässt.

Wir verbringen viel Zeit dort, wo Datenbankhärtung auf Netzwerkrichtlinien trifft – von PHP- und Docker-Stacks auf AWS bis hin zu Cloudflare- und Firewall-Regeln, die bestimmen, was ein kompromittierter Server überhaupt erreichen kann. Das Muster, das Teams immer wieder erwischt, ist fast immer ein zu sehr vertrauenswürdiges internes Konto plus Egress, den niemand gesperrt hat. Wenn ein vergessenes Replikationskonto mit einem gemeinsamen Passwort nach etwas klingt, das in Ihrer Infrastruktur schlummert, sprechen wir miteinander.