Zwölf Jahre. So lange hat eine Lücke in PostgreSQL überlebt, die einem Konto mit einem Nebenrecht die Kontrolle über den Datenbank-Server gibt. Sie trägt die Kennung CVE-2026-6471, die Forscher von Cyera nennen sie PostGREShell.
Das Bemerkenswerte ist nicht der Schweregrad — die 7,2 CVSS-Punkte sind solide Mittelklasse. Bemerkenswert ist, wie unauffällig das Recht ist, das ausreicht.
WAS DAS REPLIKATIONSRECHT WIRKLICH KANN
In PostgreSQL gibt es ein Attribut namens REPLICATION. Man vergibt es an Konten, die einen Datenstrom für Backups oder für ein zweites System abgreifen sollen. Es ist ausdrücklich kein Superuser-Recht, und genau deshalb vergeben Admins es gern großzügig.
Cyera hat gezeigt: Wenn wal_level auf logical steht, reicht dieses Konto aus, um eine beliebige Bibliothek zu laden und Code als der Betriebssystem-Benutzer auszuführen, unter dem die Datenbank läuft. In der Regel ist das postgres.
DER FEHLER: Eine Prüfung, die auf diesem Weg nie stattfindet
Beim Anlegen eines Replikationsslots übergibst du den Namen eines Ausgabe-Plugins. Dieser Name ging ungeprüft an den Bibliotheks-Lader. Die Pfadbeschränkung, die PostgreSQL beim normalen LOAD-Befehl durchsetzt, greift auf dem Replikationspfad schlicht nie.
Dazu kommt ein zweiter Schnitzer: Setzt man den Namen in doppelte Anführungszeichen, akzeptiert der Parser fast jedes Zeichen — Pfadtrenner und ../ eingeschlossen.
Die Lücke stammt aus PostgreSQL 9.4, also aus dem Jahr, in dem Logical Decoding eingeführt wurde. Sie ist seitdem in jeder Version mitgewandert.
WIE NAH DER ANGREIFER SEIN MUSS
Hier lohnt Genauigkeit, weil die Bewertungen sonst schnell zu dramatisch klingen:
- Windows-Server: Die Bibliothek lässt sich per SMB direkt von der Maschine des Angreifers laden. Auf dem Datenbank-Server muss nichts geschrieben werden.
- Linux und macOS: Das geht nur, wenn NFS-Automounting aktiv ist. Sonst braucht der Angreifer vorher Schreibzugriff auf das Dateisystem des Servers.
Zum Beweis hat Cyera ein Test-Plugin gebaut, das das Replikationskonto zum Superuser befördert und drei Wege einrichtet, um dauerhaft im System zu bleiben.
DER FIX — UND WARUM DANACH ETWAS KAPUTT IST
Die Sicherheitsreleases vom 13. August 2026 bringen einen neuen Parameter: output_plugin_libraries. Er enthält eine vom Administrator freigegebene Liste erlaubter Ausgabe-Plugins. Der Standardwert ist 'pgoutput, test_decoding'.
Und genau da liegt die Falle. Wenn du wal2json, decoderbufs oder ein anderes Plugin einsetzt — etwa für Change-Data-Capture zu einem anderen System — funktioniert es nach dem Update nicht mehr, bis du es in diese Liste einträgst.
Deshalb die Reihenfolge, die tatsächlich funktioniert:
- Vorher erfassen, was im Einsatz ist:
SELECT DISTINCT plugin FROM pg_replication_slots; - Auf 18.6, 17.11, 16.15, 15.19 oder 14.24 aktualisieren
- Die eigenen Plugins in
output_plugin_librarieseintragen - Mit
SELECT pg_reload_conf();übernehmen — ein Neustart ist nicht nötig
Wenn du pg_upgrade --check laufen lässt, setze den Parameter vorher. Sonst meldet der Check Probleme, die keine sind.
EIN LOCH BLEIBT NOCH OFFEN
Das Werkzeug pg_createsubscriber ignoriert die neue Einstellung. Ein Patch von Hayato Kuroda (Fujitsu) liegt vor, war zum Berichtszeitpunkt aber noch nicht übernommen.
WIE DRINGEND IST DAS FÜR DEIN HOMELAB?
Ehrliche Einordnung: Stand 4. September gibt es keinen öffentlichen Angriffscode, und die Lücke steht nicht im KEV-Katalog der CISA. Kein Grund, den Feierabend zu opfern.
Aber: Wenn du Nextcloud, Immich, Paperless oder eine ähnliche Anwendung selbst betreibst, läuft darunter mit hoher Wahrscheinlichkeit ein PostgreSQL. Fixes sind bei Amazon RDS, Debian, SUSE und Ubuntu bereits durch — Ubuntu hat sie am 20. August als USN-8653-1 für 22.04, 24.04 und 26.04 ausgeliefert. Ein apt upgrade erledigt das nebenbei.
Wenn du nicht sofort aktualisieren kannst, hilft Zwischenzeug: das REPLICATION-Attribut von Konten entfernen, die es nicht brauchen, die pg_hba.conf für Replikationsverbindungen einschränken, ausgehend SMB (Port 445) und NFS (Port 2049) blockieren und autofs deaktivieren.
Ein Termin gehört noch in den Kalender: PostgreSQL 14 erreicht am 12. November 2026 sein Support-Ende. Wer dort noch steht, plant den Wechsel besser jetzt.