PostgreSQL-Sicherheitslücken: Arten und Maßnahmen zu ihrer Abwehr

Wichtigste Erkenntnisse

• Die Sicherheitslücken in PostgreSQL lassen sich in vier Muster einteilen: SQL-Injection, Ausweitung von Berechtigungen und Codeausführung, fehlerhafte Zugriffskontrolle sowie Missbrauch von Backup-Tools.
• Mit der Veröffentlichung vom 13. August 2026 wurden 28 CVEs auf einmal behoben, von denen die Hälfte eine Bewertung von 8,8 erhielt.
• Das schlimme Ergebnis ist nicht eine offengelegte Tabelle, sondern eine Exploit-Kette, die bis zum Host-Betriebssystem reicht.
• Installieren Sie Patches umgehend, beschränken Sie Zugriffsrechte, binden Sie Ihre Parameter und lassen Sie keine Version, deren Lebenszyklus abgelaufen ist, ohne Patches laufen.
• Falls Sie dachten, die in PostgreSQL integrierten Escaping-Funktionen hätten das Problem der SQL-Injection gelöst, dann sagt beweist das Gegenteil.

PostgreSQL kann auf eine wirklich beeindruckende Sicherheitsbilanz zurückblicken und verfügt – wie andere weit verbreitete SQL-Datenbanken in vorhersehbaren Abständen koordinierte Sicherheitshinweise heraus, doch einige der jüngsten Fehler waren besonders schwerwiegend, und bei einigen wenigen ist es sogar bis zur Codeausführung auf dem Host gekommen.

Die 2026 Sicherheitshinweise deuten nicht darauf hin, dass sich das Tempo verlangsamen wird. Im Februar wurden fünf CVEs geschlossen, im Mai elf und am 13. August wurden in einer einzigen koordinierten Veröffentlichung 28 geschlossen, wobei Fehler mit hohem Schweregrad im Kernserver, in Contrib-Modulen und in Client-Tools auftraten. Hier finden Sie eine Übersicht über die Arten von Sicherheitslücken, auf die Sie tatsächlich stoßen werden, was passiert, wenn Sie sie ignorieren, und wie sich die Lücke schließen lässt.

Arten von PostgreSQL-Sicherheitslücken

Ein Hinweis zu den unten aufgeführten Versionsbereichen: In den Sicherheitshinweisen von PostgreSQL werden die unterstützten Zweige aufgeführt, die überprüft wurden; dies ist jedoch nicht gleichbedeutend mit einer Unbedenklichkeitsbescheinigung für alle älteren Versionen. Ein Teil dieses Codes wird von mehreren Zweigen gemeinsam genutzt, ein anderer Teil hingegen nicht. Daher muss eine EOL-Version wie PostgreSQL 13 eigenständig bewertet werden, anstatt sie pauschal als anfällig oder sicher einzustufen. Sicher ist, dass niemand aus dem Upstream-Bereich diese Bewertung mehr für Sie vornimmt. Der CVE-Tracker von TuxCare ist der schnellste Weg, um zu sehen, was für eine EOL-Version tatsächlich geprüft wurde und ob bereits ein Patch über den Endless Lifecycle Support verfügbar ist.

SQL-Einschleusung

Es ist noch nicht vorbei, egal wie viele ORMs das Gegenteil versprechen. CVE-2025-1094, eine von Rapid7 entdeckte SQL-Injection-Sicherheitslücke mit hohem Schweregrad und im Februar 2025 behoben wurde, zeigte, dass selbst ordnungsgemäß maskierte Eingaben unter den falschen Kodierungsbedingungen zu einer Injektion führen können. Das Grundproblem bestand darin, dass die Quoting-Funktionen von libpq (PQescapeLiteral, PQescapeIdentifier, PQescapeString und PQescapeStringConn) die Quoting-Syntax in Text, der die Kodierungsvalidierung nicht bestand, nicht neutralisieren konnten. Es handelte sich um dieselbe Art von Fehler, die man in einer nachlässig programmierten Webanwendung finden würde, nur eine Ebene tiefer verborgen. Und die Korrektur selbst führte auf andere Weise zu Fehlern in diesen Funktionen: Sie ignorierten nun ihre Parameter für die Zeichenfolgenlänge und ließen einige aufrufende Programme abstürzen, was erst eine Woche später in einem weiteren Release behoben wurde.

Vor kurzem wurde das Modul „refint contrib“ durch die Sicherheitslücke CVE-2026-6637 (CVSS 8,8) betroffen, bei der es zu einem Stack-Pufferüberlauf kam, der es einem nicht privilegierten Datenbankbenutzer ermöglicht, beliebigen Code als der Betriebssystembenutzer auszuführen, unter dem die Datenbank läuft.

Es gibt einen zweiten, enger gefassten Angriffsweg im Rahmen desselben Fehlers: Wenn eine Anwendung eine benutzergesteuerte Spalte als „refint cascade“-Primärschlüssel deklariert, kann derjenige, der den Aktualisierungswert für diesen Schlüssel bereitstellt, eine SQL-Injection auslösen. Beide Angriffswege betreffen die Versionen 14 bis 18. CVE-2026-6638 fügt einen Injektionsvektor über Tabellennamen in `ALTER SUBSCRIPTION … REFRESH PUBLICATION` hinzu, wodurch ein Tabellenersteller auf der Abonnentenseite SQL-Befehle mit den Anmeldedaten der Publikationsseite ausführen kann, obwohl dieser in der Praxis weitaus eingeschränkter ist (CVSS 3,7, nur Versionen 16 bis 18).

Im August gab es eine weitere erwähnenswerte Schwachstelle. CVE-2026-15741 (CVSS 8,8) ist eine SQL-Injection in der EXTRACT()-Deparsing-Funktion, bei der ein Objektbesitzer über eine bösartige Objektdefinition beliebige SQL-Befehle als Superuser ausführt; die Schwachstelle tritt überall dort auf, wo deparsierte Ausdrücke verarbeitet werden, einschließlich pg_dump, psql-Befehlen wie \sf und Nicht-Core-Tools, die dasselbe tun. Das Muster ist bei allen identisch: Eingaben, die eigentlich harmlos sein sollten, werden letztendlich ausführbar.

Achtung: CVE-2025-1094 weist zwei unterschiedliche Auslösewege auf. Bei den Quoting-Funktionen von libpq entsteht das Risiko, wenn deren Ausgabe als Eingabe an psql weitergeleitet wird. Bei den Befehlszeilen-Dienstprogrammen ist der konkrete Auslöser eine BIG5-Client-Kodierung in Kombination mit EUC_TW oder MULE_INTERNAL auf dem Server. Wenn Ihr Stack verschiedene Kodierungen mischt oder die Abfrageausgabe irgendwo per Pipe an psql weiterleitet, sollten Sie den Client patchen.

Rechteausweitung und Remote-Codeausführung

Die Erweiterungen der prozeduralen Sprache sind leistungsstark, und genau das macht sie zu einem lohnenden Angriffsziel. CVE-2024-10979 (CVSS 8,8) ermöglichte es einem nicht privilegierten Datenbankbenutzer, über PL/Perl sensible Prozessumgebungsvariablen zu ändern, darunter auch PATH – was oft schon ausreicht, um die Ausführung von beliebigem Code zu erreichen, selbst wenn der Angreifer kein Betriebssystemkonto auf dem Rechner besitzt. Die Schwachstelle betraf alle Zweige von 12 bis 17, sodass auch eine aktuelle Version keinen Schutz bot. Im August 2026 tauchte PL/Perl erneut auf, diesmal mit CVE-2026-14670 (CVSS 8,8), einem Heap-Pufferüberlauf bei der Rückgabe eines gebundenen Hashes, der es dem Eigentümer einer Funktion ermöglichte, über einen speziell gestalteten Funktionskörper Code als Betriebssystembenutzer der Datenbank auszuführen.

Die Februar-2026-Ausgabe erweiterte diese Kategorie weit über prozedurale Sprachen hinaus. CVE-2026-2006 (CVSS 8,8) ist auf eine fehlende Validierung der Länge von Multibyte-Zeichen bei der Kerntextverarbeitung zurückzuführen, bei der ein gewöhnlicher Datenbankbenutzer manipulierte Abfragen ausführt, einen Puffer überläuft und schließlich Code als Betriebssystembenutzer ausführt. Für diesen Fall ist keine Erweiterung erforderlich. CVE-2026-2005 (CVSS 8,8) ist ein Heap-Pufferüberlauf in pgcrypto, der von jedem ausgenutzt werden kann, der der Erweiterung Chiffretext übergeben kann. Dies ist schwerwiegender, als es zunächst klingt, da pgcrypto eine vertrauenswürdige Erweiterung ist – das bedeutet, dass ein Nicht-Superuser mit CREATE-Rechten für die Datenbank sie mit dem Befehl CREATE EXTENSION installieren kann. CVE-2026-2004 (CVSS 8,8) betrifft „intarray“ aufgrund einer fehlenden Typüberprüfung bei der Eingabe für den Selektivitätsschätzer. Hinzu kommt CVE-2026-2007, ein Heap-Überlauf in „pg_trgm“ in Version 8.2, der PostgreSQL 18 betrifft – damit gibt es vier Fehler mit hohem Schweregrad in einer Version mit fünf CVEs, drei davon in Contrib-Modulen.

Es ist anzumerken, dass ein CVSS-Wert mehr als eine praktische Auswirkung abdecken kann. CVE-2026-6473 aus der Mai-Ausgabe hat einen Wert von 8,8 und betrifft einen Integer-Wraparound, der es einem nicht privilegierten Datenbankbenutzer ermöglicht, eine Zuweisung zu klein zu dimensionieren und außerhalb des zulässigen Bereichs zu schreiben. Laut PostgreSQL kann dies zur Ausführung von beliebigem Code als Datenbank-OS-Benutzer führen, während Anwendungen, die Eingaben im Gigabyte-Bereich an die betroffenen Funktionen übergeben, dem Eingabebereich stattdessen möglicherweise einen Segmentierungsfehler verursachen. Es ist sinnvoller, den Sicherheitshinweis zu lesen, als nur den Wert zu betrachten.

Bei den schwerwiegenden Fällen lässt sich ein Muster erkennen: Der Zugriff auf Datenbankebene wandelt sich unbemerkt in einen Zugriff auf Host-Ebene um. Die beste Verteidigungsstrategie ist die ordnungsgemäße Anwendung des Prinzips der geringsten Berechtigungen. Das bedeutet, dass man einschränken muss, wer Funktionen und Objekte erstellen darf, dass man Erweiterungen entfernt, die Ihre Anwendungen nie nutzen, und dass man die Angriffsfläche klein hält. Verwechseln Sie das jedoch keinesfalls mit einem Ersatz für Patches, denn nichts davon verhindert einen Fehler in der Speichersicherheit bei der Verarbeitung von Kerntext.

Fehler in der Zugriffskontrolle und bei der Zeilensicherheit

Nicht jeder Fehler macht sich bemerkbar. CVE-2024-10976 entstand durch eine unvollständige Nachverfolgung von Tabellen mit Sicherheit auf Zeilenebene, sodass ein wiederverwendeter Abfrageplan möglicherweise Zeilen zurückgab oder änderte, auf die er eigentlich keinen Zugriff haben durfte. Betroffen sind nur Datenbanken, die tatsächlich „CREATE POLICY“ verwenden, weshalb man das Problem leicht abtun könnte – bis man sich daran erinnert, welche der eigenen Anwendungen von dieser Funktion abhängig sind. CVE-2026-14666 ist die Version vom August 2026 desselben Problems: Hier überdauern zwischengespeicherte Sicherheitsrichtlinien auf Zeilenebene Änderungen an der Rollenzugehörigkeit, den Rollenattributen und den Datenbankbesitzverhältnissen, sodass ein Benutzer weiterhin Lese- und Schreibvorgänge ausführt, die vor einem Moment noch zulässig waren, nun aber nicht mehr.

CVE-2024-10978 gehört ebenfalls in diese Kategorie. Bei einer Anwendung, die „SET ROLE“ oder „SET SESSION AUTHORIZATION“ verwendet, könnte eine Abfrage mit der falschen Benutzer-ID ausgeführt werden, wodurch ein Benutzer mit geringeren Berechtigungen Zeilen einsehen oder ändern könnte, die eigentlich für jemand anderen bestimmt sind. Es handelt sich zwar nicht um Codeausführung, aber genau um die Art von Problem, die ein Multi-Tenant-Modell unbemerkt untergräbt. Das sind die stillen Schwachstellen – anwendungsspezifisch und leicht zu übersehen, da nichts abstürzt. Die Daten sickern einfach durch die Hintertür nach außen.

CVE-2026-6478 (CVSS 6,5) ist wieder eine ganz andere Art von Schwachstelle. Ein verdeckter Timing-Kanal beim Vergleich von Passwörtern mit MD5-Hash ermöglicht es einem Angreifer, Anmeldedaten wiederherzustellen, die für die Authentifizierung ausreichen. Scram-SHA-256, das bereits seit einiger Zeit in jeder unterstützten Version als Standard verwendet wird, ist davon nicht betroffen. Allerdings enthalten viele Produktionsdatenbanken nach wie vor MD5-Hashes, die aus einem Upgrade von PostgreSQL 13 oder früheren Versionen stammen. Diese Datenbanken sind tatsächlich gefährdet. Betroffen sind die Versionen 14 bis 18; die Fehlerbehebung erfolgte im Mai 2026.

Tools für Datensicherung und -wiederherstellung

Diese Sicherheitslücke entspricht nicht dem üblichen Vorurteil über Schwachstellen in Datenbanken, und genau deshalb verdient sie eine eigene Kategorie.

CVE-2025-8714 und CVE-2025-8715 (beide CVSS 8,8) wurden im August 2025 in pg_dump entdeckt. CVE-2025-8714 ermöglicht es einem böswilligen Superuser auf dem Ursprungsserver, psql-Metabefehle in den Datensatz einzuschleusen, die bei einer Wiederherstellung unter dem Konto des Client-Betriebssystems ausgeführt werden. CVE-2025-8715 funktioniert ähnlich über einen Zeilenumbruch in einem speziell gestalteten Objektnamen und ist wohl die schwerwiegendere der beiden Schwachstellen: Hier reicht bereits ein Benutzer des Ursprungsservers anstelle eines Superusers aus, und derselbe Angriff kann zudem eine SQL-Injection als Superuser auf dem Wiederherstellungsziel bewirken. pg_dumpall, pg_restore und pg_upgrade sind alle betroffen. CVE-2012-0868 hatte diese Art von Fehler bereits einmal behoben, doch in Version 11.20 wurde er stillschweigend wieder eingeführt.

Dann musste der Fix selbst behoben werden. CVE-2026-18408 (CVSS 8,8, August 2026) deckte einen weiteren Weg über die Eingabeerweiterung auf, der den für CVE-2025-8714 eingeführten \restrict-Schutz umging, wobei \unrestrict allein ausreichte, um den ursprünglichen Angriff zum Zeitpunkt der Wiederherstellung wieder funktionsfähig zu machen. Im Mai-Update war bereits CVE-2026-6477 (CVSS 8,8) hinzugefügt worden, bei dem ein Server-Superuser den Stack-Speicher in psql oder pg_dump über die Funktion lo_read() von libpq überschreibt.

CVE-2026-6475 (CVSS 8,8) erweitert das Problem auf pg_basebackup und pg_rewind, wo das Verfolgen von Symlinks es einem Superuser am Ursprungsrechner ermöglicht, nicht damit in Zusammenhang stehende lokale Dateien – beispielsweise /var/lib/postgres/.bashrc – zu überschreiben und das Betriebssystemkonto zu kapern. PostgreSQL grenzt diese Schwachstelle sorgfältig ein, und das sollten Sie auch tun: Durch das Starten des Servers nach diesen Befehlen wird dem ursprünglichen Superuser bereits implizit über Mechanismen wie `shared_preload_libraries` vertraut, sodass das praktische Risiko in Arbeitsabläufen liegt, bei denen die resultierenden Dateien verschoben, als Snapshot gesichert oder anderweitig bearbeitet werden, bevor der Server hochfährt.

Der rote Faden, der sich durch diesen gesamten Abschnitt zieht, ist, dass die Angriffsfläche nicht Ihre Anwendung oder Ihr Verbindungspool ist, sondern Ihr Backup-Job – etwas, das oft mit erhöhten Berechtigungen ausgeführt wird und selten derselben genauen Prüfung unterzogen wird wie die Hauptdatenbankkonfiguration. Dies macht auch deutlich, dass ein Großteil dieser CVEs clientseitig auftritt. PostgreSQL ordnet sie der Client-Komponente zu, und das Patchen des Servers bringt in diesem Fall nichts. Die Rechner, auf denen psql, pg_dump, pg_basebackup und pg_createsubscriber laufen, müssen eigenständig gepatcht werden.

Risiken bei der Nichtbehebung von PostgreSQL-Sicherheitslücken

Das ist keine Entscheidung, bei der man sagt: „Das machen wir im nächsten Sprint.“ Die negativen Folgen reichen von einem peinlichen Datenleck bis hin zu einem vollständig in fremden Händen befindlichen Host.

Ein Sicherheitsverstoß, der richtig ins Geld geht

Der IBM-Bericht „Cost of a Data Breach“ aus dem Jahr 2026 beziffert den weltweiten Durchschnitt auf 4,99 Millionen US-Dollar – ein Rekordwert und ein Anstieg von 12 % gegenüber dem Vorjahr, wobei die Erkennung, Eskalation und entgangene Umsätze den größten Teil des Anstiegs ausmachten. Die Zahl, die jeden beunruhigen sollte, der einen langsamen Patch-Zyklus betreibt, ist die Zeit. Die durchschnittliche Zeit bis zur Identifizierung und Eindämmung einer Sicherheitsverletzung stieg auf 247 Tage, womit sich der fünfjährige Trend der Verbesserung umkehrte; Sicherheitsverletzungen, die länger als 200 Tage andauerten, verursachten etwa ein Drittel höhere Kosten als solche, die früher behoben wurden.

Unternehmen, die KI und Automatisierung in den Bereichen Prävention, Erkennung, Untersuchung und Reaktion einsetzen, konnten Sicherheitslücken etwa zwei Monate schneller schließen und zahlten 1,93 Millionen US-Dollar weniger als Unternehmen, die darauf verzichteten. All dies untermauert die These, dass diese Automatisierung im Bereich des Schwachstellenmanagements eingesetzt werden sollte – also bei der Suche und Behebung von Schwachstellen, bevor jemand diese ausnutzen kann.

Vollständige Kompromittierung des Servers, nicht nur Datenverlust

CVE-2025-1094 steht in direktem Zusammenhang mit der BeyondTrust-Sicherheitslücke CVE-2024-12356, die bei dem vielbeachteten Angriff auf das US-Finanzministerium als Zero-Day-Exploit ausgenutzt wurde. In jedem von Rapid7 getesteten Szenario war für die erfolgreiche Ausnutzung der BeyondTrust-Sicherheitslücke die Ausnutzung von CVE-2025-1094 erforderlich, um die Ausführung von Code aus der Ferne. Sobald jemand Shell-Befehle auf dem Datenbankhost ausführt, ist die Datenbank selbst das geringste Problem – eine laterale Bewegung über den Rest Ihrer Linux-Umgebung wird möglich.

Teams, die PostgreSQL als Teil anderer Produkte einsetzen, sind sich oft gar nicht bewusst, dass sie einer Sicherheitslücke ausgesetzt sind. PostgreSQL wird als Abhängigkeit in vielen Programmen von Drittanbietern mitgeliefert, und wenn eine CVE veröffentlicht wird, kann es passieren, dass man eine Datenbank patcht, von der man gar nicht mehr wusste, dass man sie hat.

Eine EOL-Version ohne Patches ausführen

Sobald eine Hauptversion das Ende ihres Lebenszyklus erreicht, stellt der Upstream-Entwickler die Bereitstellung von Sicherheitspatches dafür ein. Es werden weiterhin neue CVEs entdeckt – sie werden jedoch in diesem Zweig nicht mehr behoben. Mehrere der oben genannten 2026 Fehler betreffen jeden unterstützten Zweig von 14 bis 18, und das Schlimme daran ist, dass für PostgreSQL 14 ab dem 12. November 2026 keine Patches mehr bereitgestellt werden – die heute unterstützte Version ist also bereits das Problem des nächsten Quartals. Wenn Sie PostgreSQL 13 verwenden, wird Ihre Version in der Sicherheitsmitteilung nicht aufgeführt, und Sie erhalten ohnehin keinen Patch vom Upstream-Entwickler.

Genau das ist es, was der „Endless Lifecycle Support“ von TuxCare genau dafür konzipiert ist. Er portiert CVE-Korrekturen für PostgreSQL 13 zurück und wendet sie über Ihren üblichen Paketmanager an, wobei die Unterstützung für PostgreSQL 14 bereits vor dessen EOL-Datum angekündigt wurde. So bleiben Sie schon jetzt auf dem neuesten Stand und können auf eine unterstützte Version umsteigen, wann immer es tatsächlich in Ihre Roadmap passt.

So schützen Sie sich vor PostgreSQL-Sicherheitslücken

Die Sicherheit von PostgreSQL ist vor allem eine Frage der Disziplin und keine Heldentat. Mit drei Gewohnheiten lässt sich ein Großteil der praktischen Risiken abdecken.

Patches umgehend installieren und CVEs nachverfolgen

PostgreSQL veröffentlicht koordinierte Sicherheitsupdates für alle unterstützten Zweige gleichzeitig. Mit dem Update-Paket vom November 2024 wurden die Sicherheitslücke CVE-2024-10979 und damit verbundene Probleme in den Versionen 17.1, 16.5, 15.9, 14.14, 13.17 und 12.21 am selben Tag behoben. Die Release-Reihe vom Mai 2026 brachte elf Korrekturen gleichzeitig für die Versionen 18.4, 17.10, 16.14, 15.18 und 14.23, und am 13. August wurden 28 Korrekturen für die Versionen 18.6, 17.11, 16.15, 15.19 und 14.24 veröffentlicht. Abonnieren Sie die Sicherheitshinweise und betrachten Sie Updates der Nebenversion als routinemäßige Wartungsmaßnahme und nicht als Projekt, für das ein Business Case erforderlich ist.

Profi-Tipp: Führen Sie nach einem Minor-Version-Upgrade folgenden Befehl aus: SELECT version(); in psql aus, um sicherzustellen, dass der Server tatsächlich die von Ihnen erwartete Version verwendet. Ein Paket, dessen Upgrade zwar erfolgreich verlief, für das jedoch kein Neustart des Dienstes erfolgte, meldet weiterhin die alte Version. Überprüfen Sie anschließend separat die Client-Seite, da SELECT version() gibt keinen Aufschluss über psql, pg_dump, pg_basebackup oder libpq auf den Rechnern, auf denen diese Programme ausgeführt werden. Eine Besonderheit bei PostgreSQL 18: 18.5 wurde nie veröffentlicht, da nach Abschluss der Paketierung eine Regression auftrat; daher springt die August-Version direkt von 18.4 auf 18.6.

Berechtigungen und die Erstellung von Erweiterungen einschränken

Zahlreiche Angriffswege auf PostgreSQL führen nach wie vor über Berechtigungen auf Datenbankebene, Rechte zur Objekterstellung oder den Zugriff auf eine bestimmte Erweiterung, weshalb sich das Prinzip der geringsten Berechtigungen nach wie vor bewährt. Beschränken Sie, wer Funktionen in PL/Perl und PL/Python erstellen darf, entfernen Sie nicht genutzte Erweiterungen und gestalten Sie Rollen generell restriktiv.

Die jüngsten Fehler in refint, pgcrypto, intarray und pg_trgm sind ein gutes Argument dafür, diese Erweiterungsliste noch in dieser Woche statt erst im nächsten Quartal zu überprüfen. Diese Einschränkungen hätten die Sicherheitslücke CVE-2024-10979 geschlossen und mehrere andere eingeschränkt, doch sie verhindern keinen Fehler in der Speichersicherheit bei der Textverarbeitung im Kern, sodass sie zusätzlich zu den Patches erfolgen und diese nicht ersetzen.

Eingaben validieren und parametrisierte Abfragen verwenden

Das „Escaping“ ist eine Sicherheitsmaßnahme, keine eigenständige Strategie. Verwenden Sie parametrisierte Abfragen immer dann, wenn Werte aus nicht vertrauenswürdigen Eingaben stammen, damit diese Eingaben niemals zu ausführbarem SQL werden können. Für die Teile einer Anweisung, die nicht als Parameter gebunden werden können – also Bezeichner, Tabellennamen, Sortierrichtung und alle anderen strukturellen Elemente –, sollten Sie stattdessen strikte Whitelists verwenden. Kombinieren Sie beides mit einer Validierung am Rand.

Bewährte Verfahren zur Vermeidung von PostgreSQL-Sicherheitslücken

Diese Kontrollmaßnahmen schließen einzelne Angriffswege ab. Der nächste Schritt besteht darin, die Erkennung und Behebung von Problemen zu systematisieren, damit diese erkannt und behoben werden, bevor jemand sie ausnutzen kann.

Kontinuierliche Schwachstellenprüfung durchführen

Man kann nicht beheben, was man nicht sieht, und gebündelte PostgreSQL-Instanzen lassen sich gut verbergen – manchmal sogar vor denjenigen, die sie betreiben. Führen Sie kontinuierliche Scans statt vierteljährlicher durch, damit eine neue CVE bereits innerhalb weniger Stunden auf Ihrem Radar erscheint und nicht erst beim nächsten Audit. Wenn ein Scanner etwas meldet, vergewissern Sie sich zunächst, dass es sich um einen echten Befund handelt, bevor Sie in Panik geraten, denn die Suche nach einem Fehlalarm kostet Zeit, die Sie nie wieder zurückbekommen.

Patches automatisieren und den gesamten Stack abdecken

Der zeitaufwändige Teil beim Patchen besteht in der Regel nicht darin, den Fix zu finden, sondern im Wartungsfenster. Automatisierte Patches verkürzt die Zeitspanne zwischen Bekanntgabe und Bereitstellung – also den Zeitraum, in dem eine bekannte Sicherheitslücke weiterhin ausnutzt werden kann, obwohl bereits ein Fix verfügbar ist. Hier zeigt sich auch der Nutzen der End-of-Life-Abdeckung: TuxCare portiert Sicherheitspatches auf unterstützte EOL-PostgreSQL-Versionen sowie auf abgedeckte direkte und transitive Abhängigkeiten zurück, sodass auch eine nicht mehr unterstützte Version weiterhin gepatcht wird.

Insider-Tipp: Legen Sie den SLA für Ihr Patch-Programm anhand des CVE-Veröffentlichungsdatums fest, nicht anhand des Datums, an dem jemand die Schwachstelle zufällig entdeckt hat. Schwachstellen, die aus dem Internet zugänglich sind, ziehen in der Regel schon kurz nach einer öffentlichen Warnung Scan- und Ausnutzungsversuche nach sich; daher sollte Ihre Frist erst dann beginnen, wenn die öffentliche Warnung veröffentlicht wird.

Harden-Konfiguration und Protokollüberwachung

Standardwerte sind ein Ausgangspunkt, keine fertige Konfiguration. Erzwingen Sie TLS für Client-Verbindungen und erstellen Sie Regeln in der Datei „pg_hba.conf“, in denen die Datenbanken, Rollen, Netzwerke und Authentifizierungsmethoden namentlich genannt werden, die tatsächlich Zugriff benötigen, anstatt pauschale Einträge stehen zu lassen. Entfernen Sie nicht verwendete „contrib“-Erweiterungen oder überspringen Sie deren Installation, und behalten Sie die Protokolle im Auge, um ungewöhnliche SQL-Fehler oder wiederholte Fehler im Stil von Injektionsangriffen zu erkennen. Angesichts der Tatsache, dass viele der jüngsten Fehler speziell in „contrib“ aufgetreten sind, lohnt es sich, diese Liste lieber jetzt zu bereinigen als erst bei der nächsten geplanten Überprüfung.

Schützen Sie PostgreSQL mit TuxCare vor der Ausnutzung von Sicherheitslücken

Sicherheitslücken in PostgreSQL lassen sich in den Griff bekommen, allerdings nur, wenn Sie Patches rechtzeitig installieren und keine Version, deren Support abgelaufen ist, ohne Sicherheitsupdates in der Produktion belassen. PostgreSQL 13 hat am 13. November 2025 das Ende des Community-Supports erreicht und erhält keine offiziellen CVE-Korrekturen mehr; PostgreSQL 14 folgt am 12. November 2026.

Falls eines davon noch in Ihrem Stapel liegt, bietet der „Endless Lifecycle Support“ von TuxCare portiert diese Korrekturen für Sie zurück, die über normale Updates des Paketmanagers statt über einen separaten Patching-Workflow angewendet werden. So müssen Sie sich nicht zwischen einem anhaltenden Sicherheitsrisiko und einer Migration nach dem Zeitplan eines anderen entscheiden. Prüfen Sie zunächst, wo Ihre PostgreSQL-Bereitstellungen tatsächlich stehen, und schließen Sie dann die Lücken in der Patch-Abdeckung.

Zusammenfassung

Artikel Name

PostgreSQL-Sicherheitslücken: Arten und Maßnahmen zu ihrer Abwehr

Beschreibung

Erfahren Sie mehr über PostgreSQL-Sicherheitslücken, gängige Angriffsmethoden und bewährte Vorgehensweisen, um Ihre Datenbank vor potenziellen Sicherheitsbedrohungen zu schützen.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers