Introduction
Babelfish gives PostgreSQL and Amazon Aurora a SQL Server-compatible front door, and CVE-2026-119923 sits right at that door. A malformed TDS prelogin packet, sent before any login takes place, might let a remote attacker execute arbitrary operating system commands as the database process user. The vulnerable parser is reachable without credentials on the TDS listener (default TCP 1433), so any affected deployment that exposes that port to untrusted networks should be treated as a critical remediation priority.
Babelfish for PostgreSQL is an open-source project, owned and maintained by AWS, that uses PostgreSQL's extension model to let applications written for Microsoft SQL Server run on PostgreSQL with fewer application changes. It is available under the Apache 2.0 and PostgreSQL licenses. AWS announced general availability for Aurora PostgreSQL on October 28, 2021. The feature adds an endpoint that speaks Tabular Data Stream (TDS), the SQL Server wire protocol, on port 1433 alongside the normal PostgreSQL endpoint on 5432. The material we reviewed does not establish an installed base or market share, but AWS's launch announcement cites Tyler Technologies moving a mission-critical application from SQL Server to Aurora with minimal changes, which places Babelfish squarely in the migration path for organizations leaving SQL Server.
One note on attribution: the CVE record lists the vendor as Unknown, but the affected software belongs to AWS and the Babelfish project, and AWS published the advisory (bulletin 2026 166 AWS).
Technical information
Where the bug lives
The flaw is in the parser for the TDS PRELOGIN message, implemented in the babelfish_tds extension (source file contrib/babelfishpg_tds/src/backend/tds/tdslogin.c). PRELOGIN is the first message a SQL Server-style client sends after the TCP connection opens. Babelfish's own protocol documentation describes it as a "knock on the door" that negotiates connection attributes before LOGIN7. This code therefore runs before authentication, which is why AWS describes the attacker as unauthenticated.
A PRELOGIN message is a list of option headers, each containing a token, an offset and a length, followed by the option data. The Babelfish headers (tds_int.h) define these option tokens:
VERSION 0x00ENCRYPTION 0x01INSTOPT 0x02THREADID 0x03MARS 0x04TRACEID 0x05FEDAUTHREQUIRED 0x06NONCEOPT 0x07TERMINATOR 0xFF
The same headers define TDS_DEFAULT_INIT_PACKET_SIZE 4096, the default initial packet size.
Root cause
The assigned weakness is CWE-122, Heap Based Buffer Overflow, which MITRE defines as a buffer overflow involving memory allocated on the heap. The CVE record also consolidates a related NULL pointer dereference in the same prelogin parser, without separately describing that finding's failure behavior.
The public disclosures are thin on internals. Neither the CVE record nor the AWS bulletin provides packet bytes, the precise overwritten field, an allocation size, a vulnerable function name, or a demonstrated exploit chain, and no fixing commit or diff has been published. What we can say from the current parser source is which inputs it now refuses. The current tdslogin.c rejects:
- prelogin option lengths larger than
TDS_DEFAULT_INIT_PACKET_SIZE(4096 bytes), with the messageinvalid prelogin option length: %u - prelogin requests that contain no option headers at all, with the message
Prelogin request contained no options - a malformed ENCRYPTION option length, with the message
invalid prelogin ENCRYPTION option length: <n>
Each of these ends the connection through ereport(FATAL, ...) with ERRCODE_PROTOCOL_VIOLATION. The oversized length check matches overflow-style input, and the empty option list matches the edge case behind the consolidated NULL pointer finding. The general fix for this bug class is to validate client-supplied length and offset fields against the real packet buffer before copying or reading, and to reject missing or malformed option entries instead of dereferencing them. AWS has not published its exact change, so treat this as the pattern for the bug class rather than a description of AWS's diff.
Attack flow
Based on the disclosures, the supported exploitation sequence is short:
- The attacker reaches a Babelfish TDS listener, by default on TCP 1433.
- The attacker opens a TCP connection and sends a specially crafted, malformed PRELOGIN packet. No username, password, or SQL statement is involved, because this happens before
LOGIN7. - The vulnerable prelogin parser processes the malformed option data and triggers the heap overflow (or, for the consolidated finding, a NULL pointer dereference).
- The potential outcome is execution of arbitrary operating system commands as the database process user. A failed attempt on an unpatched server would most likely crash the database process.
The public description does not establish operating system administrator privileges or any escape from cloud isolation. The impact boundary is the database process user, and AWS describes confidentiality, integrity and availability effects on that process.
Severity
- CVSS 3.1 (CVE record): 9.8 Critical,
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - CVSS 4.0 (CVE record): 9.3 Critical,
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N - NVD display: shows the AMZN CNA score of 9.3 Critical. NVD has not yet provided its own assessment.
The two scores come from two different scoring systems and do not conflict. The vectors describe network access, low complexity, no privileges and no user interaction. They do not prove that a working exploit exists publicly.
Exploitation status
The reviewed disclosures do not confirm active exploitation, and they name no threat actor, campaign, victim, or incident. No working public exploit or proof of concept is established. The retrieved CISA KEV catalog snapshot is dated November 4, 2026, two days before publication, so it cannot tell us whether this CVE has been listed since. All of this is missing evidence, and it does not show that exploitation has not happened. VulDB maps the likely path to MITRE ATT&CK T1190 (Exploit Public Facing Application) and T1059 (Command and Scripting Interpreter).
Patch information
AWS fixed CVE-2026-119923 by shipping new Babelfish releases rather than a standalone source patch. Both AWS bulletin 2026 166 AWS and the NVD entry name Babelfish for PostgreSQL 4.10, 5.6 and 6.1 as the fixed versions, and each is a public GitHub release. The fixed releases address both the heap overflow and the consolidated NULL pointer dereference. They also fix the separate sibling issue CVE-2026-119924, a memory safety issue in TDS remote procedure call (RPC) request handling.
Fixed upstream releases
- 4.x (PostgreSQL 16): Babelfish 4.10.0, tag
BABEL_4_10_0__PG_16_14, published November 2, 2026 - 5.x (PostgreSQL 17): Babelfish 5.6.0, tag
BABEL_5_6_0__PG_17_10, published November 2, 2026 - 6.x (PostgreSQL 18): Babelfish 6.1.0, tag
BABEL_6_1_0__PG_18_4, published November 2, 2026
The release notes do not mention the fix
None of the three changelogs mentions TDS, prelogin, a buffer overflow, or the CVE. They list general items such as improved memory handling in a few functions, but nothing in the protocol layer. A search of the babelfish_extensions commit history for "prelogin" turned up only older, unrelated work from 2023 (an SSL prelogin handshake rework and a product version change). The version number is therefore the only reliable signal that you have the fix. Do not wait for a changelog entry.
Applying the fix on self-hosted installs
- The prelogin parser is compiled C code in the
babelfish_tdsshared library. The fix takes effect only after you install the new binaries and restart the PostgreSQL server. - According to the release notes,
babelfish_tdshas no SQL-level changes in these releases. You only need to runALTER EXTENSION ... UPDATEforbabelfishpg_commonandbabelfishpg_tsql. RunningALTER EXTENSIONalone does not replace the vulnerable parser code, and neither does checking\dx. The new library has to be loaded. - Version gaps: NVD lists the affected open-source ranges as ending at 4.8 and 5.4, but the fixed releases are 4.10 and 5.6. Treat 4.9 and 5.5 as unpatched too. The Aurora 5.5.0 build is explicitly listed as affected.
- Older branches (1.x, 2.x, 3.x): there are no fixed open-source releases. Self-hosted users must move to a fixed line through a major version upgrade using
pg_upgrade. The release notes say 4.10, 5.6 and 6.1 support upgrading from "some" older versions, so confirm your starting version is supported first.
Amazon Aurora PostgreSQL with Babelfish
AWS backported the fix to many Aurora minor lines, including the 1.x through 3.x Babelfish branches that have no fixed open-source release. Fixed builds, shown as Aurora version (Babelfish version):
- PostgreSQL 13: 13.9.16 (1.5.5), 13.23.3 (1.17.2)
- PostgreSQL 14: 14.6.16 (2.3.5), 14.17.8 (2.12.4), 14.18.6 (2.13.3), 14.19.5 (2.14.2), 14.20.5 (2.15.2), 14.22.3 (2.16.1), 14.23.1 (2.17.0)
- PostgreSQL 15: 15.10.8 (3.8.4), 15.12.8 (3.9.4), 15.13.6 (3.10.3), 15.14.5 (3.11.2), 15.15.5 (3.12.2), 15.17.3 (3.13.1), 15.18.1 (3.14.0)
- PostgreSQL 16: 16.8.8 (4.5.5), 16.9.6 (4.6.3), 16.10.5 (4.7.2), 16.11.5 (4.8.2), 16.13.3 (4.9.1), 16.14.1 (4.10.0)
- PostgreSQL 17: 17.4.8 (5.1.4), 17.5.6 (5.2.3), 17.6.5 (5.3.2), 17.7.5 (5.4.2), 17.9.3 (5.5.1), 17.10.1 (5.6.0)
- PostgreSQL 18: 18.3.4 (6.0.2), 18.4.1 (6.1.0)
These fixes are platform-specific. Aurora 16.11.5 with Babelfish 4.8.2 is a corrected combination, even though the open-source recommendation names 4.10. Do not collapse the two release paths into a single version threshold.
Operational points from AWS's upgrade documentation:
- Babelfish cannot be upgraded independently on Aurora. You upgrade the supporting Aurora PostgreSQL cluster to a version that contains the desired Babelfish build.
- Apply all pending maintenance so the cluster lands on the latest patch, not just the latest minor version.
- Minor versions and patches do not require a new cluster parameter group. A major upgrade requires a custom parameter group for the new engine version with the same Babelfish parameter settings.
- Automatic minor version upgrades may not select the latest engine version, so do not treat them as confirmation that a fixed build is installed.
- To verify, compare the cluster's Babelfish version against the patch level number in parentheses above, not only the Aurora minor version.
Interim workaround
Restrict network access to the TDS port (default 1433) to trusted sources. On Aurora, AWS specifies VPC security groups for this. Restricting access limits who can deliver the triggering input, but it does not install the parser fix.
Detection methods
As of November 6, 2026, there is no public Sigma, YARA, Snort, or Suricata rule and no IoC set (hashes, IPs, domains) for this CVE. The AWS bulletin and NVD entry cover only upgrades and port restriction. Useful detection comes from asset exposure, the validation errors in the patched parser, and network and host monitoring derived from how the bug works.
What you are looking for
- The malicious traffic arrives before authentication. There will be no failed login, username, or SQL statement attached to it.
- A malformed PRELOGIN will most likely show up as option lengths or offsets that do not match the packet, relative to the option tokens and the 4096-byte default packet size listed above.
Inventory first
The most reliable detection today is knowing what is vulnerable and exposed:
- Self-managed Babelfish: connect to the PostgreSQL endpoint and run
\dxto list installed extension versions (babelfishpg_common,babelfishpg_tsql, and so on). Versions 1.0 through 1.5, 2.1 through 2.15, 3.1 through 3.12, 4.0 through 4.8 and 5.1 through 5.4 are listed as affected. The fixed lines are 4.10, 5.6 and 6.1. - Aurora: compare each cluster's engine and Babelfish version with the ranges in bulletin 2026 166 AWS. For example, 16.x clusters with Babelfish below 4.5.5, or 5.4.x below 5.4.2, are affected. Also check for pending maintenance.
- Exposure: list which of these instances accept TDS connections on 1433 from untrusted networks, such as security groups open to
0.0.0.0/0or internet-facing load balancers. An exposed, unpatched TDS listener is the top-priority hunting target.
Patched parser protocol violation errors
The patched parser ends rejected connections with a FATAL error using ERRCODE_PROTOCOL_VIOLATION. Strings worth alerting on, taken from tdslogin.c:
Prelogin request contained no options invalid prelogin option length: <n> invalid prelogin ENCRYPTION option length: <n> Certification 0x<xx> not supported
Prelogin request contained no options: a PRELOGIN with no option headers, matching the NULL pointer edge case.invalid prelogin option length: an option longer than 4096 bytes, the overflow-style input.invalid prelogin ENCRYPTION option length: a malformed ENCRYPTION option.Certification 0x<xx> not supported: an older check that fires on an unknown ENCRYPTION value. Legitimate clients rarely trigger it, so it works as a low-volume signal of a malformed handshake.
Ship PostgreSQL server logs to your SIEM (for Aurora, export them to CloudWatch Logs) and alert on these strings, especially bursts from a single source IP. Normal SQL Server drivers send well-formed PRELOGIN packets, so these messages from an untrusted address strongly suggest probing. Caveat: these messages only exist in patched builds. A vulnerable server processes the malformed packet instead of rejecting it, so this signal is for spotting continued attempts after patching and for confirming the fix is active.
Network level hunting
With no public IDS rule, NDR or Zeek and Suricata users need custom logic. In principle, look for:
- PRELOGIN messages to 1433 where an option's declared length exceeds 4096 bytes, or where offset plus length runs past the end of the packet.
- PRELOGIN messages with no options before the
0xFFterminator, or with a malformed ENCRYPTION option. - Connections from unexpected sources that send PRELOGIN and disconnect without ever reaching
LOGIN7, especially when repeated. This fits fuzzing or exploit attempts.
If you use a TDS parser such as Zeek's, check how it handles malformed PRELOGIN packets first, and test any custom rule against normal client traffic before enabling alerts.
Host and post-exploitation indicators
On an unpatched server, a failed attempt will most likely crash the database process, while a successful one runs OS commands as the database process user. Watch for:
- Unexpected PostgreSQL backend crashes, crash recovery cycles, or Aurora failovers and restarts that line up in time with inbound TDS connections.
- Shells or other unusual child processes spawned by the database service account, and outbound connections from the database host to unfamiliar destinations.
- New files written by the database user outside its data directories.
These are behavioral leads rather than CVE-specific signatures, and they are most useful in correlation. A crash or unusual child process close in time to a TDS connection from an untrusted IP should be treated as a likely exploitation attempt. VulDB also recommends continuous monitoring for unusual traffic to port 1433, which fits here because the PRELOGIN exchange is the only point where an attacker touches the service before exploitation.
Affected systems and versions
Babelfish for PostgreSQL extension (as stated in the CVE record):
- 1.x: versions 1.0 through 1.5
- 2.x: versions 2.1 through 2.15
- 3.x: versions 3.1 through 3.12
- 4.x: versions 4.0 through 4.8 (treat 4.9 as unpatched as well)
- 5.x: versions 5.1 through 5.4 (treat 5.5 as unpatched as well)
Fixed open-source releases: 4.10.0 (PostgreSQL 16.14), 5.6.0 (PostgreSQL 17.10), 6.1.0 (PostgreSQL 18.4), or later. No fixed open-source release exists for 1.x, 2.x or 3.x.
Amazon Aurora PostgreSQL with Babelfish: affected unless the cluster runs one of the fixed engine and Babelfish pairs listed in the Patch Information section, or later, with pending maintenance applied. The Aurora 5.5.0 Babelfish build is explicitly listed as affected.
Vulnerable configuration: any affected deployment with the TDS listener (default TCP 1433) reachable by an attacker. Exposure to untrusted networks is the highest-risk configuration. The PostgreSQL endpoint on 5432 is not the disclosed attack surface.
Vendor security history
AWS disclosed three Babelfish issues in early November 2026, and they have different prerequisites:
- CVE-2026-119922 (bulletin of November 3, 2026): remote, authenticated user. Privilege escalation through improper access control. AWS stated there was no workaround and identified corrected releases.
- CVE-2026-119923 (bulletin of November 6, 2026): remote, unauthenticated actor. Memory safety issue in TDS handshake handling with possible OS command execution. Corrected releases, Aurora build mappings and a network workaround were published.
- CVE-2026-119924 (same November 6 bulletin): remote, authenticated actor. Adjacent process memory disclosure or denial of service through TDS remote procedure call handling. Do not confuse it with the NULL pointer finding consolidated into CVE-2026-119923.
Database authentication is a prerequisite for the other two issues but not for this one, so a posture built only around authenticated user permissions does not address CVE-2026-119923. The disclosures show published remediation guidance, but they do not establish average repair times, historical exploit frequency, or a comparative security ranking for the vendor.
References
- NVD: CVE-2026-119923
- CVE Record: CVE-2026-119923
- AWS Security Bulletin: CVE-2026-119923 and CVE-2026-119924, Issues with Babelfish for Aurora PostgreSQL
- AWS Security Bulletin: CVE-2026-119922, Babelfish for PostgreSQL Privilege Escalation
- GitHub Advisory: Babelfish for PostgreSQL Privilege Escalation
- Release: Babelfish 4.10.0 for PostgreSQL 16.14
- Release: Babelfish 5.6.0 for PostgreSQL 17.10
- Release: Babelfish 6.1.0 for PostgreSQL 18.4
- GitHub API: Babelfish 4.10.0 release metadata
- GitHub API: Babelfish 5.6.0 release metadata
- GitHub API: Babelfish 6.1.0 release metadata
- GitHub API: babelfish_extensions commit search for prelogin
- Source: tdslogin.c (BABEL_4_X_DEV)
- Source: tds_int.h (BABEL_4_X_DEV)
- Babelfish internals: TDS protocol
- VulDB: CVE-2026-119923
- MITRE CWE-122: Heap Based Buffer Overflow
- Babelfish project site
- Babelfish: Managing security
- AWS: Using Babelfish for Aurora PostgreSQL
- AWS: Upgrading your Babelfish cluster to a new version
- AWS: Managing Babelfish for Aurora PostgreSQL version updates
- AWS: Maintaining an Amazon Aurora DB cluster
- CISA Known Exploited Vulnerabilities Catalog
- CISA KEV JSON feed
- AWS press release: General Availability of Babelfish for Amazon Aurora PostgreSQL



