Mit CVE-2026-119923 hat AWS eine kritische Sicherheitslücke in Babelfish for PostgreSQL veröffentlicht – der Erweiterung, mit der PostgreSQL und Amazon Aurora PostgreSQL das Protokoll von Microsoft SQL Server sprechen. Laut dem AWS-Sicherheitsbulletin 2026-166-AWS vom 6. November 2026 kann ein entfernter Angreifer ohne Anmeldung über einen präparierten Verbindungsaufbau die Vertraulichkeit, Integrität und Verfügbarkeit des Datenbankprozesses beeinträchtigen. Der CVE-Eintrag bewertet die Lücke mit CVSS 3.1 9,8 und CVSS 4.0 9,3. Eine zweite Schwachstelle, CVE-2026-119924, setzt eine Anmeldung voraus und ist als „hoch“ eingestuft.
Gepatcht ist beides: in den Babelfish-Versionen 4.10, 5.6 und 6.1 sowie in einer langen Liste von Aurora-PostgreSQL-Minor-Versionen. Wer Babelfish nicht aktiviert hat, ist nicht betroffen. Wer es nutzt, sollte prüfen, ob der TDS-Port aus dem Netz erreichbar ist.
Was ist Babelfish – und warum ist der TDS-Port so wichtig?
Babelfish ist ein Open-Source-Projekt, das AWS nach eigenen Angaben besitzt und pflegt. Es baut auf dem Erweiterungsmodell von PostgreSQL auf und soll SQL-Server-Workloads ohne Änderungen an den Anwendungen auf PostgreSQL laufen lassen. Dafür versteht die Datenbank zusätzlich TDS (Tabular Data Stream), das Wire-Protokoll von SQL Server. Anwendungen, die für SQL Server gebaut wurden, können so mit ihren gewohnten Treibern eine Verbindung herstellen.
Genau an dieser Stelle sitzen beide Lücken. TDS lauscht standardmäßig auf Port 1433 – parallel zum normalen PostgreSQL-Port. Wer Babelfish für eine Migration eingeschaltet hat, öffnet damit also eine zweite Tür in die Datenbank, deren Code einen eigenen Parser für ein fremdes Protokoll mitbringt. Fehler in solchen Parsern sind ein klassischer Angriffspunkt, weil sie Daten verarbeiten, bevor überhaupt geprüft wurde, wer da anklopft.
CVE-2026-119923: Heap-Überlauf im Prelogin-Parser
Die Beschreibung im CVE-Eintrag ist deutlicher als das AWS-Bulletin. Demnach handelt es sich um einen Heap-basierten Pufferüberlauf (CWE-122) im TDS-Prelogin-Parser. Der Prelogin ist die allererste Phase des TDS-Handshakes – also noch vor der Authentifizierung. Ein speziell präpariertes, fehlerhaftes Prelogin-Paket an den TDS-Port könnte es laut Beschreibung erlauben, beliebige Betriebssystembefehle mit den Rechten des Datenbankprozesses auszuführen. Der Eintrag fasst zudem einen verwandten Fund zusammen: eine NULL-Pointer-Dereferenzierung im selben Parser.
AWS selbst formuliert zurückhaltender und spricht von einem „memory-safety issue“ in der Verarbeitung des Verbindungs-Handshakes, das einem nicht authentifizierten Akteur erlauben könnte, Vertraulichkeit, Integrität und Verfügbarkeit des Datenbankprozesses zu beeinträchtigen. Das GitHub-Advisory des Babelfish-Projekts (GHSA-vq28-vgj3-r26w) stuft die Lücke als „critical“ ein und nennt dieselben Rahmendaten.
Die Bewertungen im Überblick:
- CVSS 3.1: 9,8 (kritisch) – Angriff über das Netzwerk, geringe Komplexität, keine Rechte, keine Nutzerinteraktion nötig.
- CVSS 4.0: 9,3 (kritisch).
- CISA-Einschätzung (SSVC, 6. November): keine bekannte Ausnutzung, aber „automatisierbar“ und mit „totalem“ technischem Schaden.
- CISA KEV: Die Lücke steht nicht im Katalog der aktiv ausgenutzten Schwachstellen (Stand Katalog-Version 2026.11.06).
Öffentliche Exploit-Details sind in den Primärquellen nicht enthalten. Die Kombination aus „vor der Anmeldung“, „über das Netzwerk“ und „automatisierbar“ ist aber ein Profil, das typischerweise schnell Scans nach erreichbaren Instanzen nach sich zieht.
CVE-2026-119924: Speicher lesen mit Login
Die zweite Lücke steckt im Parser für Remote-Procedure-Calls (RPC) über TDS, genauer beim Auslesen des Prozedurnamens. Es handelt sich um einen Out-of-Bounds-Read (CWE-125). Ein angemeldeter Nutzer mit geringen Rechten könnte über eine fehlerhafte RPC-Anfrage benachbarten Prozessspeicher auslesen oder den Prozess zum Absturz bringen. Der CVE-Eintrag bewertet das mit CVSS 3.1 8,1 und CVSS 4.0 7,2. Laut CISA-SSVC ist auch hier keine Ausnutzung bekannt; die Lücke gilt als nicht automatisierbar.
In den Release Notes der gepatchten Babelfish-Versionen taucht zusätzlich CVE-2026-119922 auf. Diese bereits am 3. November veröffentlichte Lücke betrifft eine fehlerhafte Zugriffskontrolle, über die angemeldete Nutzer ihre Rechte ausweiten könnten (CVSS 3.1 8,8). Sie ist mit denselben Updates behoben.
Betroffene Versionen
Für die Open-Source-Erweiterung nennt AWS die Versionen 1.0–1.5, 2.1–2.15, 3.1–3.12, 4.0–4.8 und 5.1–5.4 als betroffen. Behoben ist das Problem in Babelfish 4.10, 5.6 und 6.1. Laut GitHub wurden diese Releases (für PostgreSQL 16.14, 17.10 und 18.4) am 2. November veröffentlicht – also einige Tage vor dem Advisory.
Bei Aurora PostgreSQL ist die Lage kleinteiliger, weil AWS für viele Minor-Linien eigene Patch-Stände liefert. Beispiele aus der Liste des Bulletins (Aurora-Version, in Klammern die enthaltene Babelfish-Version):
- Aurora PostgreSQL 13: 13.9.16 (1.5.5), 13.23.3 (1.17.2)
- Aurora PostgreSQL 14: unter anderem 14.17.8 (2.12.4), 14.22.3 (2.16.1), 14.23.1 (2.17.0)
- Aurora PostgreSQL 15: unter anderem 15.15.5 (3.12.2), 15.17.3 (3.13.1), 15.18.1 (3.14.0)
- Aurora PostgreSQL 16: unter anderem 16.11.5 (4.8.2), 16.13.3 (4.9.1), 16.14.1 (4.10.0)
- Aurora PostgreSQL 17: unter anderem 17.7.5 (5.4.2), 17.9.3 (5.5.1), 17.10.1 (5.6.0)
- Aurora PostgreSQL 18: 18.3.4 (6.0.2), 18.4.1 (6.1.0)
Die vollständige Liste mit 30 Versionen steht im Bulletin. AWS betont, dass Kunden nach dem Upgrade auch ausstehende Wartungsaktionen („pending maintenance“) anwenden sollen, damit sie wirklich auf dem neuesten Patch-Stand landen. Ein Detail fällt auf: Für Babelfish 5.5.0 nennt AWS keinen „kleiner als“-Bereich, sondern die Version selbst als betroffen; die korrigierte Fassung in dieser Linie ist 5.5.1.
Was Betreiber jetzt tun sollten
Die Prioritäten ergeben sich direkt aus den Angaben von AWS:
- Prüfen, ob Babelfish aktiv ist. Nur Cluster mit eingeschaltetem Babelfish sind betroffen. In Aurora ist das eine Cluster-Einstellung; bei selbst betriebenen PostgreSQL-Servern geht es um die installierte Erweiterung.
- Upgrade einplanen. Auf eine der genannten Aurora-Versionen oder eine neuere wechseln, anschließend ausstehende Wartung anwenden. Selbst gehostete Installationen auf Babelfish 4.10, 5.6 oder 6.1 aktualisieren. Das Babelfish-Projekt empfiehlt außerdem, Forks und abgeleiteten Code mit den neuen Fixes zu versorgen.
- Port 1433 abschotten. Als Übergangslösung empfiehlt AWS, den Netzwerkzugang zum TDS-Port über VPC-Security-Groups auf vertrauenswürdige Quellen zu beschränken. Das ist auch nach dem Patch sinnvoll: Ein Datenbank-Port gehört grundsätzlich nicht ins offene Internet.
Ergänzend – als allgemeine Praxis, nicht als Vorgabe aus dem Bulletin – lohnt ein Blick in die Logs auf ungewöhnliche Verbindungsabbrüche oder Abstürze des Datenbankprozesses, gerade bei Instanzen, deren TDS-Port bislang öffentlich erreichbar war.
Einordnung
Babelfish ist ein Nischenwerkzeug, aber eines mit sensibler Zielgruppe: Es wird typischerweise bei Migrationen von SQL Server zu PostgreSQL eingesetzt, also in Unternehmen mit gewachsenen, oft geschäftskritischen Anwendungen. Der eigentliche Lehrsatz ist älter als diese Lücke: Jede Kompatibilitätsschicht, die ein fremdes Protokoll vor der Authentifizierung parst, vergrößert die Angriffsfläche. Ähnliche Muster haben wir zuletzt bei der SonicWall-Lücke CVE-2026-19868 und bei der OpenSSH-Lücke SSHole auf musl-Systemen gesehen, wo ebenfalls der Weg vor oder rund um den Login das Problem war. Wer sich für Datenbank-Sicherheit im Anwendungsstack interessiert, findet bei den MariaDB-Connector-Lücken ein weiteres Beispiel.
Positiv ist: AWS hat die Patches vor der Veröffentlichung der Advisories ausgeliefert, nennt einen klaren Workaround, und bislang ist keine Ausnutzung bekannt. Das Zeitfenster sollten Betreiber nutzen – bevor sich das ändert.
