Babelfish’s TDS flaws reach the connection and request parsers

A database connection starts parsing traffic before an application sends its first useful query. AWS’s November 6, 2026 Babelfish bulletin describes two memory-safety flaws in that protocol work. One sits in connection setup before authentication. The other sits in an authenticated remote-procedure-call request. For teams running SQL Server applications through Babelfish, the entry point and installed database branch both affect the response. [1]

Two parsers with different access requirements

Amazon’s CVE-2026-119923 record identifies a heap buffer overflow in the TDS prelogin parser. A malformed prelogin packet could allow remote command execution as the database process user. The record also consolidates a related null-pointer-dereference finding in that parser. Because the relevant work happens before login, the vendor does not make valid database credentials a prerequisite. [2]

CVE-2026-119924 concerns an out-of-bounds read in the TDS RPC procedure-name parser. Amazon describes an authenticated remote user sending a malformed request that could expose adjacent process memory or cause denial of service. The default TDS port is 1433. The two records therefore call for different assumptions about who can reach the vulnerable processing. [3]

In a hypothetical reporting environment, an application service might be allowed to open TDS connections while ordinary employee devices cannot. That reachability decision matters even when database passwords are well managed. For the prelogin issue, the assessment starts with the systems that can establish a connection. For the authenticated issue, it also includes the accounts and services allowed to issue requests.

Our interpretation is that the useful boundary map joins network access and database identity. A diagram showing only application usernames leaves out the connection setup path. A network diagram showing only trusted subnets leaves out the privileges available to a service within them. Putting those views together makes it easier to assign the update to the people who operate the real callers.

The deployment determines which version to change

AWS lists affected self-managed extension ranges as 1.0–1.5, 2.1–2.15, 3.1–3.12, 4.0–4.8 and 5.1–5.4. Its recommended extension releases are 4.10, 5.6 and 6.1 or later. Aurora customers receive the fixes through the engine releases in the bulletin’s separate branch matrix and should apply pending maintenance. [1] [2] [3]

Examples in that matrix include Aurora PostgreSQL 16.14.1 with Babelfish 4.10.0, 17.10.1 with 5.6.0, and 18.4.1 with 6.1.0. It also includes backported fixes such as Aurora 17.9.3 with Babelfish 5.5.1. The full matrix covers additional branches. A smaller-looking Babelfish number can therefore represent a patched managed release. [1]

AWS’s version documentation explains that Aurora and PostgreSQL engine version identifiers have distinct meanings, even where their numbering aligns closely. For an inventory used to assess this bulletin, retaining the complete Aurora version alongside the included Babelfish version avoids losing the patch component that identifies the managed fix. [5]

The Babelfish 5.6.0 release was published on November 2, before the November 6 disclosure. Its release notes distinguish installing new binaries from updating changed extensions, and direct managed-environment users to their vendor’s upgrade instructions. That timing is useful context when comparing an existing change record with the newly published advisory. [4]

A maintenance window has callers on both sides

For our example reporting team, the question after choosing a supported fixed release is which ordinary workflows must still complete. A representative acceptance check might include opening a connection, using the application’s stored-procedure path and producing a known report. Those checks describe this hypothetical application’s business work. They help its owner judge the effect of the change without inventing a performance result.

The network owner has a related job while the update is arranged. AWS recommends limiting TDS-port access to trusted sources until the upgrade is applied. Turning that guidance into an environment-specific decision requires knowing which callers are legitimate. A security-group description that says reporting can be a starting clue, but the application owner should be able to explain what actually needs the connection. [1]

The change record can then connect the target release, the installed result and the application checks. That is particularly helpful when different clusters take different supported upgrade paths. The database team can review each cluster against the branch matrix, while the reporting owner confirms the workflows that depend on it. Everyone gets to talk about the same database, which is a surprisingly valuable maintenance feature.

These findings put protocol handling on the same operational map as query permissions and application behavior. A team responding to the bulletin needs both a fixed installation and a clear account of who can reach it. The distinction between prelogin traffic and authenticated requests gives that review a concrete place to begin. [2] [3]