Kritische PostgreSQL-Schwachstellen ermöglichen Codeausführung und SQL-Injection

Zwar beheben die Updates elf CVEs (Common Vulnerabilities and Exposures) sowie über 60 weitere Fehler, die im vergangenen Monat gemeldet wurden, doch ein Wechsel auf eine neuere Hauptversion ist nicht zwingend erforderlich, um das Risiko zu eliminieren. Alle unterstützten Zweige 14 bis 18 sind ücken betroffen.

Für Administratoren ist ein Upgrade auf laufenden Systemen ohne Datenverlust möglich. Es ist weder ein kompletter Dump/Restore-Prozess noch der Einsatz von pg_upgrade notwendig.

Stattdessen genügt es, den PostgreSQL-Dienst zu stoppen und die Binärdateien zu aktualisieren. ## Schwere Risiken durch Codeausführung Die schwerwiegendste Lücke, CVE-2026-6637, befindet sich im Modul `refint`, das für die Durchsetzung referentieller Integrität zuständig ist.

Technischer Hintergrund

Ein Stack-Buffer-Overflow in diesem Modul ermöglicht es einem nicht privilegierten Datenbankbenutzer, beliebigen Code als das Betriebssystemkonto auszuführen, unter dem PostgreSQL läuft. Dies würde eine vollständige Kompromittierung des Servers bedeuten.

Ein weiteres Angriffsszenario entsteht, wenn eine Anwendung eine benutzerkontrollierte Spalte als Primärschlüssel für `refint-cascade` exponiert und Benutzern erlaubt, diesen zu aktualisieren. Eine speziell gestaltete nderung des Primrschlssels knnte hier eine SQL-Injection auslsen.

Der Angreifer könnte dann beliebige SQL-Befehle mit den Rechten der aktualisierenden Rolle ausführen. ## SQL-Injection in Replikationskomponenten Auch die Funktionen der logischen Replikation enthalten mehrere Angriffspfade, die zur Privilegien-Eskalation missbraucht werden können. CVE-2026-6476 betrifft das Tool `pg_createsubscriber`.

Sicherheitslage und Risiko

Ein Angreifer mit entsprechenden Rechten könnte SQL-Befehle einschleusen, die mit Superuser-Rechten ausgeführt werden, sobald das Tool aufgerufen wird. Zusätzlich betrifft CVE-2026-6638 den Befehl `ALTER SUBSCRIPTION... REFRESH PUBLICATION`.

Ein Ersteller könnte Tabellennamen so konstruieren, dass beliebiger SQL-Code mit den Berechtigungen der Publish-Seite ausgeführt wird, sobald der Refresh-Befehl erneut aufgerufen wird.

Laut der PostgreSQL-Entwicklung betreffen diese Schwachstellen vor allem Umgebungen mit Versionen 16 bis 18, die logische Replikation nutzen. ## Weitere Sicherheitslücken und Speicherprobleme Neben den Codeausführungs-Risiken betreffen weitere CVEs die Speichersicherheit, Denial-of-Service-Angriffe und Client-Tools.

Sicherheitslage und Risiko

CVE-2026-6473 beschreibt Integer-Überlaufprobleme, die zu zu kleinen Speicherzuweisungen führen. Dies ermöglicht Schreibzugriffe außerhalb der vorgesehenen Grenzen und kann bei speziell konstruierten Eingaben zu Speicherzugriffsfehlern (Segmentation Faults) führen. CVE-2026-6477 betrifft die Client-Bibliothek `libpq`.

Durch die unsichere Verwendung der Funktion `PQfn` in Hilfsfunktionen für große Objekte wie `lo_export()` und `lo_read()` kann ein Server-Superuser überdimensionierte Antworten senden. Dies könnte den Stapelspeicher in Client-Tools wie `psql` oder `pg_dump` überschreiben und potenziell zur Ausführung führen. Auch Backup-Tools sind gefährdet.

CVE-2026-6475 ermöglicht es den Tools `pg_basebackup` (Plain-Format) und `pg_rewind`, symbolische Links zu. Dadurch könnten beliebige lokale Dateien, die vom Ursprungssuperuser ausgewählt wurden – etwa Shell-Profile – überschrieben werden.

Sicherheitslage und Risiko

Zusätzlich wurden Schwachstellen identifiziert, die eine Umgehung (CVE-2026-6472), Lecks (CVE-2026-6474), das Überschreiben (CVE-2026-6475), SQL-Injection als Superuser (CVE-2026-6476), die Ausführung (CVE-2026-6477), ein Zeitbasiertes Leck von MD5-Zugangsdaten (CVE-2026-6478), Denial-of-Service bei SSL/GSS (CVE-2026-6479) sowie begrenzte Speicheroffenlegungen (CVE-2026-6575) und SQL-Injection in der logischen Replikation (CVE-2026-6638) ermöglichen. ## Empfehlung für Administratoren PostgreSQL Version 14 wird am 12.

November 2026 das Lebensende erreichen und erhält danach keine weiteren Sicherheitsupdates. Organisationen, die noch Version 14 betreiben, sollten umgehend auf Version 14.23 aktualisieren und parallel einen Migrationsplan für eine neuere, langfristig unterstützte Version erstellen.

Angesichts der Kombination aus Codeausführung, SQL-Injection, Speicher-Korruption und Client-seitigen Risiken sollten diese Updates als dringend behandelt werden. Dies gilt insbesondere für internetexponierte oder mehrtenantfähige PostgreSQL-Installationen.

Teams sollten die Priorität auf das Upgrade zu den neuesten Minor-Versionen legen und im Rahmen ihrer Hardening-Maßnahmen den Einsatz von `refint`, der logischen Replikation sowie Client-Tools überprüfen.