With CVE-2026-119923, AWS has disclosed a critical vulnerability in Babelfish for PostgreSQL, the extension that lets PostgreSQL and Amazon Aurora PostgreSQL speak Microsoft SQL Server’s wire protocol. According to AWS security bulletin 2026-166-AWS, published on November 6, 2026, a remote, unauthenticated actor could use a crafted connection handshake to affect the confidentiality, integrity and availability of the database process. The CVE record scores the flaw at 9.8 under CVSS 3.1 and 9.3 under CVSS 4.0. A second flaw, CVE-2026-119924, requires authentication and is rated high.
Both are patched: in Babelfish versions 4.10, 5.6 and 6.1 and in a long list of Aurora PostgreSQL minor versions. If you have not enabled Babelfish, you are not affected. If you have, check whether the TDS port is reachable from the network.
What Babelfish is and why the TDS port matters
Babelfish is an open source project that AWS says it owns and maintains. It uses PostgreSQL’s extension model and is designed to run SQL Server workloads on PostgreSQL without changing applications. To make that work, the database also understands TDS (Tabular Data Stream), SQL Server’s wire protocol. Applications built for SQL Server can then connect with their usual drivers.
That is exactly where both flaws live. TDS listens on port 1433 by default, alongside the regular PostgreSQL port. Anyone who turned on Babelfish for a migration has therefore opened a second door into the database, one that brings its own parser for a foreign protocol. Bugs in parsers like this are a classic target because they process data before anyone has checked who is knocking.
CVE-2026-119923: heap overflow in the prelogin parser
The CVE record is more explicit than the AWS bulletin. It describes a heap-based buffer overflow (CWE-122) in the TDS prelogin parser. Prelogin is the very first phase of the TDS handshake, before authentication takes place. According to the description, a specially crafted, malformed prelogin packet sent to the TDS port might allow remote attackers to execute arbitrary operating system commands as the database process user. The record also consolidates a related finding: a NULL pointer dereference in the same parser.
AWS itself uses more cautious language, describing a “memory-safety issue” in the connection-handshake handling that could allow an unauthenticated actor to affect the confidentiality, integrity and availability of the database process. The Babelfish project’s GitHub advisory GHSA-vq28-vgj3-r26w rates it critical and lists the same key data.
The ratings at a glance:
- CVSS 3.1: 9.8 (critical): network attack, low complexity, no privileges and no user interaction required.
- CVSS 4.0: 9.3 (critical).
- CISA assessment (SSVC, November 6): no known exploitation, but “automatable” with “total” technical impact.
- CISA KEV: the flaw is not in the catalog of known exploited vulnerabilities (catalog version 2026.11.06).
The primary sources contain no public exploit details. Still, the combination of “before login”, “over the network” and “automatable” is the kind of profile that typically draws quick scans for reachable instances.
CVE-2026-119924: reading memory after login
The second flaw sits in the parser for remote procedure calls (RPC) over TDS, specifically where the procedure name is read. It is an out-of-bounds read (CWE-125). A logged-in user with low privileges could send a malformed RPC request to read adjacent process memory or crash the process. The CVE record scores it at 8.1 under CVSS 3.1 and 7.2 under CVSS 4.0. CISA’s SSVC entry lists no known exploitation and rates it as not automatable.
The release notes of the patched Babelfish versions also mention CVE-2026-119922. Published on November 3, it covers improper access control that could let authenticated users elevate their privileges (CVSS 3.1 8.8). It is fixed by the same updates.
Affected versions
For the open source extension, AWS lists versions 1.0–1.5, 2.1–2.15, 3.1–3.12, 4.0–4.8 and 5.1–5.4 as affected. The issue is fixed in Babelfish 4.10, 5.6 and 6.1. According to GitHub, those releases (for PostgreSQL 16.14, 17.10 and 18.4) were published on November 2, a few days before the advisory.
For Aurora PostgreSQL the picture is more granular, because AWS ships its own patch level for many minor lines. Examples from the bulletin’s list (Aurora version, with the included Babelfish version in parentheses):
- Aurora PostgreSQL 13: 13.9.16 (1.5.5), 13.23.3 (1.17.2)
- Aurora PostgreSQL 14: including 14.17.8 (2.12.4), 14.22.3 (2.16.1), 14.23.1 (2.17.0)
- Aurora PostgreSQL 15: including 15.15.5 (3.12.2), 15.17.3 (3.13.1), 15.18.1 (3.14.0)
- Aurora PostgreSQL 16: including 16.11.5 (4.8.2), 16.13.3 (4.9.1), 16.14.1 (4.10.0)
- Aurora PostgreSQL 17: including 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)
The complete list of 30 versions is in the bulletin. AWS stresses that customers should also apply any pending maintenance after upgrading so they actually end up on the latest patch. One detail stands out: for Babelfish 5.5.0, AWS does not give a “less than” range but lists the version itself as affected; the fixed release in that line is 5.5.1.
What operators should do now
The priorities follow directly from AWS’s guidance:
- Check whether Babelfish is enabled. Only clusters with Babelfish turned on are affected. In Aurora this is a cluster setting; on self-managed PostgreSQL servers it is about the installed extension.
- Schedule the upgrade. Move to one of the listed Aurora versions or a later one, then apply pending maintenance. Update self-hosted installations to Babelfish 4.10, 5.6 or 6.1. The Babelfish project also recommends bringing forks and derivative code up to date with the new fixes.
- Lock down port 1433. As a workaround, AWS recommends restricting network access to the TDS port to trusted sources with VPC security groups. That makes sense after patching, too: a database port does not belong on the open internet.
In addition, and as general practice rather than guidance from the bulletin, it is worth checking logs for unusual connection drops or database process crashes, especially on instances whose TDS port has been publicly reachable.
Context
Babelfish is a niche tool, but one with a sensitive user base: it is typically used for SQL Server to PostgreSQL migrations, which means companies with mature and often business-critical applications. The real lesson is older than this flaw: every compatibility layer that parses a foreign protocol before authentication widens the attack surface. We saw similar patterns recently with the SonicWall flaw CVE-2026-19868 and the OpenSSH SSHole login bypass on musl systems, where the path before or around the login was also the problem. For another example of database security in the application stack, see the MariaDB Connector/Node.js flaws.
The good news: AWS shipped the patches before publishing the advisories, it names a clear workaround, and no exploitation is known so far. Operators should use that window before it closes.
