PostgreSQL-Schwachstellen: Codeausführung möglich — was Administratoren jetzt tun sollten

Das CERT-Bund hat eine aktualisierte Sicherheitswarnung der Stufe „hoch“ für PostgreSQL veröffentlicht: Mehrere Schwachstellen erlauben es Angreifern, beliebigen Code auszuführen, einen Denial-of-Service-Angriff durchzuführen, Informationen offenzulegen oder Dateien zu manipulieren. Wer PostgreSQL im Einsatz hat — ob als Datenbankserver, als Unterbau für Webanwendungen oder als Teil einer Cloud-Infrastruktur — sollte jetzt handeln.

PostgreSQL ist keine Nischendatenbank. Sie läuft unter anderem hinter WordPress-Installationen, ERP-Systemen, eigenen Webapplikationen und nicht zuletzt hinter SaaS-Lösungen, die viele Unternehmen täglich nutzen. Das macht Schwachstellen in PostgreSQL zu einem breit wirksamen Risiko — nicht nur für Systemadministratoren, sondern für jeden, der auf eine dieser Anwendungen angewiesen ist.

Was ist bekannt?

Die aktualisierte CERT-Bund-Meldung (WID-SEC-2026-1544) listet mehrere Schwachstellen in PostgreSQL mit einer Gesamtbewertung „hoch“. Das Risiko ist dabei vielschichtig:

• Codeausführung: Ein Angreifer kann unter Umständen beliebigen Programmcode ausführen. Das ist die schwerste Kategorie — sie bedeutet im Worst Case vollständige Kontrolle über den betroffenen Datenbankserver.
• Denial of Service: Dienste können gezielt zum Absturz gebracht oder unbrauchbar gemacht werden.
• Informationsoffenlegung: Inhalte, die nicht für Angreifer bestimmt sind, könnten ausgelesen werden — Datenbankdumps, Konfigurationsdetails, Anmeldedaten.
• Dateimanipulation: Unter bestimmten Voraussetzungen ist das Lesen oder Schreiben von Dateien auf dem zugrunde liegenden System möglich.

Die genauen CVEs und betroffenen Versionen sind in der verlinkten CERT-Bund-Meldung aufgeführt — dort lässt sich prüfen, welche konkrete PostgreSQL-Version im eigenen Umfeld betroffen ist.

Warum das relevant ist — auch wenn Sie kein DBA sind

Ein häufiger Denkfehler: „Wir haben PostgreSQL nicht im Einsatz.“ Stimmt das wirklich? PostgreSQL steckt in vielen Produkten, die gar nicht explizit als „PostgreSQL-basiert“ vermarktet werden. Managed-Hosting-Plattformen, PaaS-Angebote, Kollaborationstools, Monitoring-Lösungen — sie alle können PostgreSQL als Unterbau nutzen. Ein Blick auf die eingesetzten Systeme lohnt sich.

Gleiches gilt für On-Premise-Installationen: Wer PostgreSQL selbst betreibt — direkt auf einem Linux-Server, als Container oder als Teil einer Webanwendung — trägt die Verantwortung für das Update selbst.

Einordnung

Aus unserer Sicht ist die Einstufung als „hoch“ berechtigt. Eine Kombination aus möglicher Codeausführung und Informationsoffenlegung ist kein theoretisches Risiko — das sind exakt die Angriffsvektoren, die in realen Vorfällen genutzt werden. Besonders kritisch wird es, wenn PostgreSQL direkt aus dem Internet erreichbar ist oder wenn Webapplikationen direkten Datenbankzugriff erlauben.

Was Sie jetzt prüfen sollten

1. Bestandsaufnahme: Welche Systeme in Ihrem Netz laufen auf PostgreSQL? Direkte Installationen, aber auch eingebettete Instanzen in Anwendungen.
2. Version prüfen: `psql –version` oder `SELECT version();` in der Datenbankkonsole — stimmt die Versionsnummer mit einer betroffenen Version aus der CERT-Bund-Meldung überein?
3. Update einspielen: PostgreSQL stellt in solchen Fällen gepatchte Versionen bereit. Die Updateprozedur ist gut dokumentiert und in den meisten Fällen ohne Datenverlust durchführbar.
4. Netzwerkzugang prüfen: Ist der PostgreSQL-Port (Standard: 5432) von außen erreichbar? Wenn ja, sofort schließen oder per Firewall-Regel absichern — Datenbankserver haben im öffentlichen Netz nichts zu suchen.
5. Managed-Dienste: Wer PostgreSQL über einen Cloud-Anbieter oder Managed-Hoster bezieht, sollte prüfen, ob und wann der Anbieter patcht — und im Zweifel nachfragen.

Abwarten ist bei einer Einstufung als „hoch“ keine gute Option. Patchen.

Quellen: CERT-Bund — „[UPDATE] [hoch] PostgreSQL: Mehrere Schwachstellen“ (https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-1544)