PostgreSQL CVE-2026-2005 und 2026-2006: Warum die einzige verlässliche Verteidigung „nicht öffentlich erreichbar“ ist

Diese Woche zwei PostgreSQL-Schwachstellen mit Remote Code Execution als Konsequenz: CVE-2026-2005 in der pgcrypto-Extension (Heap Buffer Overflow, RCE als Datenbank-Prozess-User) und CVE-2026-2006 (fehlende Multibyte-Character-Length-Validation, RCE als OS-User der Datenbank, CVSS 8.8). Patches sind verfügbar: PostgreSQL 18.2, 17.8, 16.12, 15.16 und 14.21. Das eigentliche Problem zeigt sich bei jedem Audit erneut: trotz dieser CVE-Realität laufen MariaDB, PostgreSQL, MongoDB oder Elasticsearch in Mittelstand-Stacks regelmäßig öffentlich erreichbar — manchmal sogar ohne Authentifizierung. Wer Sicherheit von Aufmerksamkeit abhängig macht, baut Sicherheit auf Zufall. Wir setzen auf deterministische Defaults: keine öffentliche Erreichbarkeit, Infrastructure as Code, Security in der Pipeline, Least Privilege.

Was die zwei CVEs konkret bedeuten

CVE-2026-2005 ist ein Heap Buffer Overflow in der pgcrypto-Extension. Ausnutzbar als regulärer Datenbank-User mit Zugriff auf pgcrypto-Funktionen — also etwa in Multi-Tenant-Datenbanken oder Anwendungen, die nutzergelieferte verschlüsselte Daten verarbeiten. Erfolgreicher Angriff bedeutet Remote Code Execution mit den Rechten des Datenbank-Prozess-Users.

CVE-2026-2006 ist die kritischere von beiden, mit CVSS 8.8. Eine fehlende Multibyte-Character-Length-Validation lässt sich über speziell präparierte Queries zu einem Buffer Overrun ausweiten — und der erlaubt arbitrary code execution mit den Rechten des Betriebssystem-Users, unter dem PostgreSQL läuft. Das ist nicht nur „der Angreifer hat die Datenbank“ — das ist „der Angreifer hat den Host“.

Patches sind verfügbar: PostgreSQL 18.2, 17.8, 16.12, 15.16, 14.21. Wer auf einer der älteren Minor-Versionen sitzt, hat den nächsten Wartungs-Slot diese Woche.

Warum die zwei CVEs in einem zweiten Schritt das eigentliche Problem zeigen

Pre-Auth-Exploits gibt es selten. Beide hier diskutierten CVEs verlangen erst einmal Authentifizierung — vermeintlich also kein Problem für ein gut konfiguriertes Setup. Die Realität ist anders.

In jedem Pen-Test, in jedem CI/CD-Audit, in jedem Mandanten-Onboarding sehen wir dieselbe Lage: öffentlich erreichbare Datenbank-Endpunkte. MariaDB auf Port 3306. PostgreSQL auf Port 5432. MongoDB auf Port 27017. Elasticsearch auf Port 9200. Manchmal mit schwacher Authentifizierung, manchmal mit Default-Credentials, in den schlimmsten Fällen ganz ohne Authentifizierung. Suchmaschinen wie Shodan und Censys indizieren diese Endpunkte permanent — automatisierter Zugriff folgt in Sekunden, nicht in Tagen.

Sobald ein authentifizierter PostgreSQL-Endpunkt öffentlich erreichbar ist, reicht ein einziger schwacher Account oder eine wiederverwendete Credential-Liste, um aus CVE-2026-2005 oder 2006 einen erfolgreichen Angriff zu machen. Und CVE-2026-2006 endet nicht an der Datenbank-Grenze, sondern auf dem OS.

Das eigentliche Problem ist nicht die Schwachstelle. Es ist die Erreichbarkeit, die sie ausnutzbar macht.

Warum das kein technisches Versagen ist

Eine Datenbank lässt sich nicht „aus Versehen“ ins Internet hängen, wenn die Infrastruktur sauber gebaut ist. Wenn es passiert, sind die Ursachen fast immer dieselben: ein System wurde schnell aufgesetzt, weil „nur kurz getestet“ werden sollte. Es gab keine Netzwerksegmentierung, weil der Firewall-Default „alles erlaubt“ hieß. Es gab kein Infrastructure as Code, also auch keine Code-Review-Möglichkeit für die Konfiguration. Und es gab kein automatisiertes Security-Scanning, das den Fehler binnen Stunden gemeldet hätte.

Anders ausgedrückt: Es fehlten Standards. Und ohne Standards ist Sicherheit Zufall.

Vier Standards, die wir konsequent fahren

1. Default: keine öffentliche Erreichbarkeit. Datenbanken laufen bei uns grundsätzlich in privaten Netzwerken, ohne Public IP, mit strikt definierten Zugriffspfaden. Zugriff erfolgt entweder über den Application-Layer, über einen Bastion Host mit kurzlebigen Zugängen, oder über VPN beziehungsweise Zero-Trust-Network-Access. Bei PostgreSQL konkret: listen_addresses = 'localhost' in der postgresql.conf, plus pg_hba.conf mit explizitem Allow-Listing der Application-Subnets — keine 0.0.0.0/0-Einträge, keine host all all 0.0.0.0/0 md5-Bequemlichkeiten.

2. Infrastructure as Code. Manuelle Konfiguration ist ein Risiko. Deshalb wird jede Infrastruktur deklarativ beschrieben und im Git versioniert — egal ob es ein NixOS-Modul für die Datenbank-Hosts ist, ein Terraform- oder OpenTofu-Plan für AWS-/Hetzner-Cluster, oder eine Ansible-Rolle für klassische Mittelstand-Setups. Eine versehentliche Public-IP an einer Postgres-Instanz fällt im Plan-Output sofort auf — bevor sie produktiv wird.

3. Security in der Pipeline. Wir prüfen nicht am Ende. Sicherheit ist Teil des Deployments: Port-Scans im CI/CD-Lauf gegen die geplante Konfiguration, Policy-Checks per OpenPolicyAgent, die offene DB-Ports schlicht blockieren, Container- und Image-Scanning, Netzwerkregeln als Code-Tests validiert. Plus: SBOM-Monitoring gegen NVD und OSV als nightly Cron — eine PostgreSQL-CVE wie diese Woche taucht damit als Issue im Repo auf, bevor irgendjemand morgens den Kaffee aufgesetzt hat.

4. Least Privilege. Selbst intern gilt: Services bekommen nur exakt die Rechte, die sie brauchen. Keine Admin-Zugriffe für Applikationen. Rotierende Credentials aus Vault oder OpenBao mit kurzlebigen Tokens. Im Kontext von CVE-2026-2005: wer die pgcrypto-Extension überhaupt nicht aktiviert hat oder nur Service-Accounts mit eingeschränkten Rollen besitzen, hat eine zusätzliche Schicht zwischen sich und dem Exploit.

Wie wir das selbst handhaben

Eine Empfehlung ohne eigene Praxis-Erfahrung ist hohle Beratung. Wir nutzen, was wir bauen.

In jedem Customer-Stack, den wir betreuen, läuft die Datenbank-Schicht hinter privaten Netzwerken. Public Endpoints sind in unseren Terraform- und OpenTofu-Plänen nicht möglich, weil eine OPA-Policy das beim Apply blockiert. NixOS-Module für Datenbank-Hosts haben strict-Network-Settings als Default. Bastion-Hosts sind zeitlich begrenzte Zugänge mit kurzlebigen Zertifikaten. Datenbank-Credentials kommen aus Vault/OpenBao mit automatischer Rotation. Und ein nightly Cron-Job prüft alle unsere Hosts gegen die externen Such-Indizes.

Beim Eingang der CVE-Meldungen am Veröffentlichungs-Tag haben wir die betroffenen PostgreSQL-Versionen in unseren Customer-Stacks per CycloneDX-SBOM-Abgleich in unter zehn Minuten lokalisiert — und die Patch-Reihenfolge nach Exposition und Schweregrad priorisiert. Mittwoch waren alle Instanzen gepatcht.

Drei Maßnahmen-Tiefen für Ihren Stack

Kurzfristig (diese Woche):

• Inventar: alle PostgreSQL-Instanzen identifizieren und gegen die Patch-Versionen 18.2, 17.8, 16.12, 15.16, 14.21 prüfen. Updates einspielen, nicht aufschieben.
• Externe Bestandsaufnahme: welche Ihrer öffentlichen IPs sprechen auf typischen DB-Ports (3306, 5432, 27017, 9200, 6379)? Tools wie Shodan oder ein eigener nmap-Scan über die eigenen IP-Ranges decken das in 30 Minuten auf.
• Default-Passwörter für administrative Datenbank-Accounts rotieren und in einen zentralen Secret-Store überführen.

Mittelfristig (nächstes Quartal):

• Infrastructure as Code etablieren — Terraform/OpenTofu für Cloud, Ansible/Puppet für klassische Setups, NixOS für eigene Linux-Hosts.
• Security-Policy-Gates in die CI/CD-Pipeline einbauen: keine Public-IPs für DB-Ports, keine offenen Default-Configs, keine ungescannten Images.
• Secret-Management aus dem Code-Repository entfernen und in Vault/OpenBao verlagern.

Strategisch (nächstes Jahr):

• Zero-Trust-Netzwerkdesign etablieren: keine direkten Internet-Exposures kritischer Services, segmentierte VPN-Zonen, mTLS zwischen Services.
• Externe Bestandsprüfung als Routine — quartalsweise Pen-Test, jährlicher Architektur-Review.
• Lifecycle-Disziplin: Test-Umgebungen automatisch nach 7 Tagen abbauen, damit nicht „kurz mal aufgesetzt“ zur dauerhaften Schatten-Infrastruktur wird.