Skip to content
RiverCore
Zurück zu ArtikelnENGINEERING
PostgreSQL veröffentlicht 11 CVEs – darunter RCE im refint-Modul
PostgreSQL CVEdatabase securityRCE vulnerabilityPostgreSQL refint stack overflow RCE fixPostgreSQL 11 CVEs versions 14 to 18

PostgreSQL veröffentlicht 11 CVEs – darunter RCE im refint-Modul

23 Jun 20266 Min. LesezeitAlex Drover

Wer schon einmal einen Postgres-Primary hinter einem Zahlungsdienst betrieben hat, kennt das ungute Gefühl, wenn an einem Montagmorgen ein Sicherheitshinweis eingeht. Man scannt die CVE-Liste, sucht nach „RCE" und „Replication" und plant die Woche gedanklich um. Das Release der PostgreSQL Global Development Group vom 19. Mai ist genau so ein Montag. Elf Sicherheitsfixes, vier davon mit einem CVSS-Score von 8,8 – und ein Weg zu Remote Code Execution über ein Contrib-Modul, das seit Jahrzehnten mit Postgres ausgeliefert wird.

Was passiert ist

Wie GBHackers News berichtete, hat die PostgreSQL Global Development Group neue Minor-Releases für alle unterstützten Branches veröffentlicht: 18.4, 17.10, 16.14, 15.18 und 14.23. Das Bundle behebt 11 Sicherheitslücken und mehr als 60 funktionale Fehler. Jede Version von 14 bis 18 ist von mindestens einigen der Probleme betroffen.

Die Schweregrad-Verteilung macht dieses Release unangenehm. Vier CVEs erreichen auf der CVSS-Skala den Wert 8,8. CVE-2026-6473 ist ein Integer-Wraparound, der Out-of-Bounds-Schreibzugriffe und Server-Abstürze auslöst. CVE-2026-6475 ist ein Symlink-Angriff auf pg_basebackup und pg_rewind, der es einem Angreifer ermöglicht, beliebige Dateien zu überschreiben. CVE-2026-6477 betrifft libpq, wo die lo_*-Large-Object-Funktionen von einem bösartigen Server genutzt werden können, um Speicher im Client-Prozess zu überschreiben. Und CVE-2026-6637 ist das Hauptproblem: ein Stack-Overflow im refint-Modul, der sich mit SQL-Injection kombiniert und mögliche RCE ermöglicht.

Auch die mittelschweren Probleme sind nicht zu vernachlässigen. CVE-2026-6476 ist SQL-Injection in pg_createsubscriber, die beliebiges SQL als Superuser ausführt, bewertet mit 7,2. CVE-2026-6479 ist ein SSL/GSS-Rekursionsfehler mit einer Bewertung von 7,5, der es einem Remote-Aufrufer ermöglicht, den Server über Socket-Verbindungen zu blockieren. CVE-2026-6478 gibt MD5-gehashte Passwörter über einen Timing-Seitenkanal während der Authentifizierung preis.

Zwei Informationslecks (CVE-2026-6474 und CVE-2026-6575) runden die Liste zusammen mit kleineren Injection-Problemen in CREATE TYPE und REFRESH PUBLICATION ab. Das Release enthält außerdem tzdata 2026b, das den Wechsel von British Columbia zu dauerhafter Sommerzeit im November 2026 berücksichtigt.

Technische Analyse

Die Fehlermuster erzählen eine Geschichte darüber, wo Postgres eine breite Angriffsfläche aufgebaut hat. Drei Bereiche stechen hervor.

Replikations- und Backup-Werkzeuge. Fünf der elf CVEs betreffen das operative Tooling, nicht die SQL-Engine selbst. pg_basebackup, pg_rewind, pg_createsubscriber und der REFRESH PUBLICATION-Pfad tauchen alle auf. Diese Tools laufen per Definition mit erhöhten Rechten. Sie greifen auf das Dateisystem zu, koordinieren sich mit Remote-Knoten und führen Superuser-SQL aus. Der Symlink-Angriff in CVE-2026-6475 hat die klassische Form: Ein privilegierter Prozess folgt einem Pfad, den er nicht validiert hat, und ein Angreifer, der Zwischenverzeichnisse kontrolliert, nutzt das für beliebiges Datei-Überschreiben. Die pg_createsubscriber-Injection ist noch gefährlicher, weil sie SQL per Design als Superuser ausführt.

Client-Server-Vertrauensgrenzen. CVE-2026-6477 kehrt das übliche Bedrohungsmodell um. Die meisten Menschen betrachten den Datenbankserver als das zu schützende Asset. Dieser Fehler besagt, dass ein feindlicher Server den Speicher in jedem Client korrumpieren kann, der gegen libpq gelinkt ist. Das betrifft Application-Server, Batch-Worker, BI-Tools und alles andere, das eine Verbindung hält. Wenn man einen Connection-String aus einem Config-Service bezieht und dieser Service kompromittiert wird, wird der eigene App-Prozess zum Ziel.

Contrib-Module, die niemand prüft. Das refint-Modul ist Contrib-Code, der die meisten aktuellen Postgres-Committer überdauert hat. CVE-2026-6637 kombiniert einen Stack-Buffer-Overflow mit SQL-Injection, um RCE zu erreichen. Teams, mit denen ich gearbeitet habe, installieren Contrib-Pakete meist pauschal, ohne zu prüfen, welche Module sie tatsächlich laden. Diese Gewohnheit ist gerade teuer geworden.

Der MD5-Timing-Angriff (CVE-2026-6478) ist die am längsten andauernde Peinlichkeit auf der Liste. MD5-Passwort-Authentifizierung ist seit Jahren als veraltet eingestuft. Die PostgreSQL Global Development Group empfiehlt ausdrücklich den Wechsel zu SCRAM-SHA-256. Wer noch MD5 in seinem Cluster verwendet, bekommt mit diesem CVE den nötigen Anstoß.

Wer betroffen ist

iGaming- und Fintech-Unternehmen sind das offensichtliche Hauptziel. Beide Branchen betreiben Postgres als System of Record unter regulatorischer Aufsicht. Ein CVSS-8.8-RCE auf einer kartendatennahen Datenbank bedeutet ein ungeplantes Änderungsfenster, ein Sicherheitsreview und eine E-Mail an den Regulator. Produktionsvorfälle, die ich bei Patch-Panik erlebt habe, entstehen meist durch übersprungenes Staging, nicht durch den Patch selbst. Der Patch ist langweilig. Das 3-Uhr-Rollback, weil jemand einen Replikations-Slot vergessen hat, ist es nicht.

Crypto- und DeFi-Infrastruktur-Teams, die Indexer und Analytics-Pipelines auf Postgres-Replikaten betreiben, sollten CVE-2026-6477 genau prüfen. Viele dieser Stacks beziehen Daten von öffentlichen oder halb-öffentlichen Node-Providern. Wenn der eigene libpq-Client eine Verbindung zu etwas herstellt, das man nicht vollständig kontrolliert, hat sich die Vertrauensannahme gerade umgekehrt.

Ad-Tech ist durch seine Skalierung exponiert. Replikations-Topologien in dieser Branche neigen dazu, sich auszubreiten: Dutzende Read-Replicas, logische Publikationen, die an Warehouse-Loader verteilt werden, und benutzerdefinierte Subscriber. CVE-2026-6476 und CVE-2026-6638 leben beide in dieser Infrastruktur.

Den härtesten Termin haben alle, die noch auf PostgreSQL 14 sind. Das End-of-Life fällt auf den 12. November 2026. Danach keine Sicherheitsupdates mehr. Das sind grob fünf Monate ab diesem Release, um ein Major-Version-Upgrade zu planen, zu testen und durchzuführen. Für ein Team, das eine Handvoll Cluster mit logischer Replikation und eigenen Extensions betreibt, sind fünf Monate knapp, nicht großzügig. Major-Version-Upgrades sind kein apt upgrade. Sie umfassen Extension-Kompatibilitätsprüfungen, Query-Plan-Regressionen und in der Regel eine pg_upgrade-Generalprobe auf realen Datenmengen.

Meine Einschätzung: Das November-14-EOL wird mehr Teams kalt erwischen als die CVEs. Ein Patch auf 14.23 kauft Zeit, ist aber kein Ziel. Wenn der Roadmap noch kein Postgres-16- oder -17-Migrationsprojekt eingetragen ist, muss das in diesem Quartal passieren.

Playbook für Engineering-Teams

Reihenfolge der Maßnahmen für die nächsten zwei Wochen:

Diese Woche. Den Postgres-Bestand nach Major-Version inventarisieren. Herausfinden, welche Cluster refint laden oder pg_basebackup, pg_rewind oder pg_createsubscriber für Nicht-Admin-Kontexte freigeben. Prüfen, ob MD5-Auth noch irgendwo in pg_hba.conf im Einsatz ist. Falls ja, den Wechsel zu SCRAM-SHA-256 einplanen. Die gepatchten Minor-Versionen (18.4, 17.10, 16.14, 15.18, 14.23) im üblichen Rhythmus durch Staging rollen. Das Minor-Upgrade selbst ist in der Regel ein Neustart, kein Dump-and-Restore.

Nächste zwei Wochen. Rechte auf Replikations- und Subscription-Rollen prüfen. CVE-2026-6476 ist nur relevant, wenn nicht vertrauenswürdiges SQL pg_createsubscriber erreichen kann. Die Rollenvergabe so einschränken, dass das nicht möglich ist. Prüfen, welche Contrib-Extensions tatsächlich genutzt werden. Wenn refint nicht notwendig ist, entfernen. Für Observability: Query- und Crash-Signale in die bestehende Telemetrie einbinden. OpenTelemetry-Instrumentierung rund um den Postgres-Client ermöglicht es, abnormale Query-Muster oder Connection-Churn zu erkennen, die auf Ausnutzungsversuche hinweisen würden.

Dieses Quartal. Wer noch auf Version 14 ist, sollte jetzt mit dem Upgrade-Plan beginnen. Einen pg_upgrade-Trockenlauf gegen einen produktionsgroßen Snapshot aufbauen. Alle Extension-Versionsabhängigkeiten katalogisieren. Die langsamsten Reporting-Queries gegen die neue Version ausführen und auf Plan-Änderungen prüfen.

Der unbequeme Befund: Die meisten Teams werden die Minor-Version patchen, den Erfolg erklären und die Arbeit an Rollen-Rechten und MD5-Hygiene ignorieren. Das sind die Teams, die sich nächstes Jahr in einer Breach-Meldung wiederfinden werden.

Die wichtigsten Erkenntnisse

  • Auf 18.4, 17.10, 16.14, 15.18 oder 14.23 im üblichen Minor-Release-Rhythmus patchen. Vier der 11 CVEs erreichen CVSS 8,8, darunter die refint-RCE-Kette (CVE-2026-6637).
  • Die Angriffsfläche hat sich in Replikations- und Backup-Werkzeuge verlagert. Fünf CVEs betreffen pg_basebackup, pg_rewind, pg_createsubscriber und Publication-Pfade.
  • MD5-Passwort-Authentifizierung abschalten. CVE-2026-6478 gibt gehashte Passwörter über einen Timing-Seitenkanal preis. SCRAM-SHA-256 ist der dokumentierte Ersatz.
  • CVE-2026-6477 kehrt das Client-Server-Vertrauen um. Jeder libpq-gebundene Client, der sich mit einem nicht vertrauenswürdigen Server verbindet, ist jetzt im Scope.
  • PostgreSQL 14 erreicht am 12. November 2026 das End-of-Life. Das Major-Version-Upgrade dieses Quartal planen, nicht im nächsten.

Häufig gestellte Fragen

F: Welche PostgreSQL-Versionen sind vom Sicherheitsrelease vom Mai 2026 betroffen?

Alle unterstützten Branches von PostgreSQL 14 bis 18 sind betroffen. Die behobenen Versionen sind 18.4, 17.10, 16.14, 15.18 und 14.23. Jede ältere Minor-Version bleibt angreifbar.

F: Was ist die schwerwiegendste Schwachstelle in diesem PostgreSQL-Release?

Vier CVEs teilen sich den höchsten Schweregrad mit CVSS 8,8. Die operativ gefährlichste ist CVE-2026-6637, ein Stack-Overflow kombiniert mit SQL-Injection im refint-Modul, der zu Remote Code Execution führen kann. CVE-2026-6475 (Symlink-Angriff in pg_basebackup), CVE-2026-6473 (Integer-Wraparound) und CVE-2026-6477 (libpq-Client-Speicherüberschreibung) erreichen ebenfalls CVSS 8,8.

F: Muss ich sofort von PostgreSQL 14 migrieren?

Nicht sofort, aber die verbleibende Zeit ist knapp. PostgreSQL 14 erreicht am 12. November 2026 das End-of-Life, danach werden keine Sicherheitsupdates mehr ausgeliefert. Ein Patch auf 14.23 deckt den aktuellen Hinweis ab, aber ein Major-Version-Upgrade auf 16 oder 17 sollte innerhalb des nächsten Quartals geplant werden.

AD
Alex Drover
RiverCore Analyst · Dublin, Ireland
TEILEN
// RELATED ARTICLES
StartseiteLösungenProjekteÜber unsKontakt
News06
Dublin, Irland · EUGMT+1
LinkedIn
🇩🇪DE