Der Kern des Problems liegt darin, dass der in einem CREATE_REPLICATION_SLOT-Befehl angegebene Plugin-Name laut Cyera direkt an jene Funktion weitergereicht wird, die die Bibliothek lädt. Die bereits vorhandene Beschränkung von Plugin-Pfaden, die Nicht-Superuser auf ein einziges vom Administrator kontrolliertes Verzeichnis begrenzt, wird auf dem Replikationspfad nie aufgerufen. Der Parser des Replikationsprotokolls akzeptiert innerhalb eines in doppelte Anführungszeichen gesetzten Plugin-Namens nahezu jedes Zeichen, einschließlich Pfadtrennern und ../-Traversierung — ein vollständiger Dateisystempfad erreicht den Loader also unverändert.
Unter Windows löst der Server laut Cyera einen Netzwerkpfad über SMB auf und holt die Bibliothek von einem Rechner, den der Angreifer kontrolliert, ohne etwas auf dem Zielsystem zu schreiben. Unter Linux und macOS gelingt dasselbe nur bei aktiviertem NFS-Automounting; ansonsten benötigt der Angreifer eine bereits bestehende Möglichkeit, eine Datei auf die Festplatte des Servers zu schreiben. Der so geladene Code läuft im Backend-Prozess der Datenbank als Betriebssystembenutzer postgres. Cyeras Test-Plugin schrieb anschließend direkt in den Rollenkatalog, um das Replikationskonto zum PostgreSQL-Superuser zu machen, und richtete drei Persistenzmechanismen ein, die einen Serverneustart überdauern.
Bei der Einstufung gehen die Beteiligten auseinander: Cyera beschreibt das REPLICATION-Attribut als niedrig privilegierte Backup-Berechtigung, während PostgreSQL die Lücke mit „Privileges Required: High" bewertet — eine Einschätzung, die auch SUSE übernimmt.
Das Projekt lehnte es ab, die bestehende LOAD-Beschränkung auf den Replikationspfad anzuwenden. „REPLICATION-Benutzer unterlagen bisher keinen Beschränkungen für Output-Plugin-Pfade und konnten daher die LOAD-Schutzmechanismen beim Logical Decoding umgehen. Die Standard-LOAD-Beschränkungen jetzt zu ergänzen, würde leider rückwirkend erfordern, dass alle Output-Plugins von Drittanbietern im Verzeichnis $libdir/plugins installiert werden", schrieb Jacob Champion, der den Fix verfasste, in der Commit-Nachricht. In den Release Notes zu 18.6 begründet die PostgreSQL Global Development Group die Whitelist damit, dass ein Replikationsbenutzer zuvor jede ladbare Bibliothek auswählen konnte, was Angriffe verschiedenster Art ermöglichte.
Für Installationen, die andere Output-Plugins nutzen — darunter wal2json und decoderbufs —, wird das Logical Decoding nach dem Update verweigert, bis ein Administrator die Bibliothek in die Liste einträgt und die Serverkonfiguration neu lädt. Fehlgeschlagene Ladevorgänge erscheinen im Serverlog als „ERROR: library “…” may not be used as an output plugin" samt Hinweis auf den Parameter. Debian warnt in seinem Advisory ausdrücklich, dass der Fix zusätzliche Konfigurationsänderungen erfordert, wenn bestimmte Erweiterungen im Einsatz sind, und nennt seine Pakete wal2json und decoderbufs. Ubuntus USN-8653-1, am 20. August für 22.04, 24.04 und 26.04 LTS ausgeliefert, erwähnt den Parameter dagegen nicht und rät lediglich zum Neustart. Das wal2json-Projekt hat seine Dokumentation inzwischen unter Verweis auf die CVE angepasst. Fertige Pakete stehen für alle fünf Zweige auf Amazon RDS sowie bei Debian, SUSE und Ubuntu bereit.
Eine Lücke im Fix ist offen: pg_createsubscriber legt Replikationsslots mit pgoutput an, ohne den neuen Parameter zu prüfen. „Das bedeutet, dass bei nicht im Parameter angegebenem Plugin-Namen der –dry-run-Modus durchläuft, die eigentliche Umwandlung aber scheitert. Das ist für Nutzer sehr überraschend und sollte vermieden werden", schrieb Hayato Kuroda von Fujitsu auf der Mailingliste pgsql-hackers. Ein Patch war in Prüfung, aber noch nicht eingepflegt. CVE-2026-6471 fehlte weiterhin im KEV-Katalog der CISA, und The Hacker News fand keinen öffentlichen Proof-of-Concept-Code.
Das Advisory deckt die unterstützten Zweige 14 bis 18 ab; PostgreSQL 14 erhält bis zum 12. November 2026 Korrekturen. Bis zum Update lässt sich die Angriffsfläche laut Cyera verringern, indem das REPLICATION-Attribut von Konten entfernt wird, die es nicht benötigen, Replikationseinträge in pg_hba.conf auf bekannte Adressen beschränkt werden, ausgehender SMB- (Port 445) und NFS-Verkehr (Port 2049) von Datenbankservern blockiert und autofs deaktiviert wird, wo es nicht gebraucht wird.