Babelfish TDS flaws: patch the pre-auth RCE path safely

AWS published security bulletin 2026-166-AWS on November 6, 2026 for two memory-safety flaws in the Tabular Data Stream (TDS) layer used by Babelfish for PostgreSQL and Babelfish for Amazon Aurora PostgreSQL. The more severe issue, CVE-2026-119923, is reachable during the TDS connection handshake before authentication and may allow operating-system command execution as the database process user. CVE-2026-119924 requires an authenticated TDS session and may expose adjacent process memory or crash the database process.

The practical response is not “block port 1433 and move on.” Inventory every Babelfish deployment and its exact engine line, restrict TDS reachability immediately, upgrade to a fixed Babelfish or Aurora PostgreSQL build, replace every live process, then prove the new version and review telemetry from the exposure window. AWS's bulletin describes potential impact; it does not say that exploitation was observed. Do not turn a vulnerability notice into an unsupported breach claim.

The vulnerability facts and version data below come from the AWS security bulletin, the official AWS CVE records and Aurora documentation, verified on November 7, 2026. The rollout, verification and evidence workflow is engineering guidance.

Answer first

Treat CVE-2026-119923 as an urgent patch event wherever an affected Babelfish TDS endpoint is reachable by untrusted clients. The bug is in prelogin parsing, so SQL authentication, least-privilege database roles and application permissions do not stop the vulnerable code path from being reached. Restrict TCP 1433 to known application sources as a temporary containment control, but schedule the fixed build now.

What is vulnerable

Babelfish lets SQL Server clients communicate with PostgreSQL through a TDS endpoint. That compatibility boundary parses bytes from a SQL Server client before translating requests to PostgreSQL behavior. The two flaws sit in different stages of that boundary:

• CVE-2026-119923 — critical, pre-authentication: AWS describes a memory-safety issue in the TDS connection-handshake handling. The official AWS CVE record identifies a heap-based buffer overflow in the prelogin parser and assigns CVSS v3.1 9.8. A malformed prelogin packet may allow arbitrary operating-system commands as the database process user.
• CVE-2026-119924 — important, authenticated: the second AWS CVE record describes an out-of-bounds read in the TDS RPC procedure-name parser. A remote authenticated user may read adjacent process memory or cause denial of service.

The first issue crosses the authentication boundary: the parser must handle the handshake before the client can prove a database identity. The second still matters because “authenticated” may include compromised application credentials, overly broad integration users or any tenant permitted to reach the TDS listener.

AWS lists open-source Babelfish for PostgreSQL 1.0–1.5, 2.1–2.15, 3.1–3.12, 4.0–4.8 and 5.1–5.4 as affected. The fixed open-source releases are 4.10, 5.6 and 6.1. Older major lines do not have a same-line fixed release in the bulletin; plan a supported upgrade path instead of assuming an unlisted patch exists.

For Aurora PostgreSQL, the affected and fixed matrix is more granular because the Babelfish version is coupled to an Aurora engine build. Use the exact table in 2026-166-AWS for the branch you operate. Examples of fixed combinations include Aurora PostgreSQL 13.23.3 with Babelfish 1.17.2, 14.23.1 with 2.17.0, 15.18.1 with 3.14.0, 16.14.1 with 4.10.0, 17.10.1 with 5.6.0 and 18.4.1 with 6.1.0. These examples are not permission to skip intermediate upgrade constraints.

Inventory before choosing a target

Build one row per cluster, not one row per account. Record owner, environment, region, endpoint, TDS exposure sources, Aurora engine version, Babelfish version, maintenance policy and upgrade target.

For Aurora, AWS documents how to enumerate regional engine versions that support Babelfish:

aws rds describe-db-engine-versions \
  --region eu-west-1 \
  --engine aurora-postgresql \
  --query '*[]|[?SupportsBabelfish==\`true\`].[EngineVersion]' \
  --output text

Query the actual cluster separately; an available engine version is not proof that a cluster runs it:

aws rds describe-db-clusters \
  --db-cluster-identifier payments-sql \
  --query 'DBClusters[0].{EngineVersion:EngineVersion,Pending:PendingModifiedValues,Status:Status}'

From the TDS endpoint, \SELECT SERVERPROPERTY('BabelfishVersion');\ identifies the Babelfish product version. From the PostgreSQL endpoint, inspect installed extensions with \\\dx\. Store command output, timestamp and cluster ARN in the change record. Screenshots alone are weak evidence because they omit query scope and are hard to compare automatically.

Contain the TDS boundary without mistaking containment for a fix

AWS recommends restricting network access to the default TDS port, TCP 1433, to trusted sources until the upgrade is applied. Implement that as an allowlist of known application security groups or narrow CIDRs. Remove broad internet routes, shared corporate ranges and “temporary” administration networks that do not need TDS.

Also check the entire path: public endpoint settings, VPC routing, security groups, network ACLs, transit gateways, Kubernetes egress and any TCP proxy or load balancer in front of the cluster. A restrictive database security group can be undermined by a trusted proxy that accepts traffic from everywhere.

Containment reduces who can send a malicious packet; it does not repair the parser. It also cannot fully protect against CVE-2026-119924 when a trusted or compromised application identity is allowed through. Keep the restriction after patching as defense in depth.

Choose the patch path

### Open-source Babelfish

Move to Babelfish 4.10, 5.6, 6.1 or later on the corresponding supported PostgreSQL major. Back up configuration and data, rehearse the upgrade with production-shaped schema and TDS clients, install signed release artifacts from the official project, update the Babelfish extensions in the documented order, and replace every database process.

Do not copy only one shared library into an old image. A mixed artifact set is difficult to attest and may fail during rollback. Build an immutable image or package set, record digests, and deploy it through the same path used for normal database releases.

### Babelfish for Aurora PostgreSQL

AWS states that Babelfish cannot be upgraded independently from its supporting Aurora PostgreSQL cluster. Select a fixed engine build from the security bulletin that is a valid target for your current source version. The Aurora upgrade guide distinguishes minor/patch upgrades from major upgrades; major moves can require a new cluster parameter group and prerequisite intermediate versions.

Use a clone or restored snapshot for rehearsal. Run prechecks, verify parameter parity, exercise representative T-SQL, stored procedures, transaction semantics and drivers, and measure the expected interruption. Then schedule the production change with an explicit abort threshold and rollback owner. Apply any pending maintenance AWS names in the bulletin; choosing a version in the console without completing maintenance is not completion evidence.

A safe rollout sequence

1. Freeze ambiguity: assign an incident/change owner and export the authoritative cluster inventory.
2. Contain: restrict TDS to the smallest verified source set. Test that approved clients still connect and unapproved probes cannot.
3. Snapshot and rehearse: restore or clone into an isolated environment. Do not send malformed proof-of-concept traffic to production.
4. Patch a canary: upgrade one non-production or low-risk representative, including extensions, parameter groups and proxies.
5. Exercise contracts: test login, prepared statements, RPC/stored procedures, transactions, failover and connection-pool recovery.
6. Roll production: upgrade in bounded waves, watching connection errors, process restarts, latency, replication health and application error rates.
7. Prove runtime state: query the version through both TDS and PostgreSQL paths after all restarts or failovers.
8. Review exposure-window evidence: preserve relevant logs and investigate anomalies without claiming compromise from noise alone.

Verification contract

Define success before the change:

Keep raw outputs and timestamps. A dashboard returning to green is necessary but not sufficient: it may aggregate away one old reader or one secondary endpoint.

Incident review without overclaiming

The public AWS bulletin explains possible confidentiality, integrity and availability impact, but it does not report active exploitation. Therefore:

• Documented fact: affected versions can expose vulnerable TDS parser paths with the stated impacts.
• Not documented by AWS: that a public exploit was used against your environment, or that any specific cluster was compromised.
• Engineering inference: a broadly reachable pre-authentication endpoint deserves accelerated review because credentials are not required to reach that parser.

Review TDS listener exposure history, security-group changes, proxy logs, database process crashes or restarts, unusual connection bursts and operating-system activity available from the platform. A restart may have benign causes; a malformed connection may be a scanner; neither alone proves command execution. Escalate only when multiple artifacts form a coherent timeline, and preserve evidence before rotating or truncating logs.

Best practices and anti-patterns

Do: keep database endpoints private, use security-group references rather than broad CIDRs, track Babelfish and Aurora versions independently, rehearse upgrades from snapshots, verify every node after failover, and retain evidence from the exposure window.

Avoid: relying on SQL authentication for a pre-auth parser flaw, treating a blocked public route as a permanent fix, updating the cluster definition without replacing processes, choosing an Aurora target without validating the supported upgrade path, or running an exploit payload against production to “prove” vulnerability.

Network restriction may reduce immediate risk, but maintenance windows, application compatibility and major-version constraints still shape the safest rollout. Teams running obsolete Babelfish branches should treat this as both a security change and a lifecycle correction.

Executive checklist

• [ ] Every Babelfish/Aurora cluster has an owner and exact runtime version.
• [ ] TCP 1433 is limited to verified application sources.
• [ ] Open-source deployments target 4.10, 5.6, 6.1 or later.
• [ ] Aurora deployments use the exact fixed build and valid path from AWS's matrix.
• [ ] Snapshot/clone rehearsal covers TDS, RPC, transactions and failover.
• [ ] All serving processes and readers report a fixed version.
• [ ] Exposure-window evidence is preserved and assessed without unsupported breach claims.
• [ ] Containment remains in place after patching.

For broader operational context, see the PostgreSQL PITR restore-drill guide, PostgreSQL autovacuum operations, the Next.js critical RCE patch workflow, and the PHP2Shell response guide. The services page connects these controls to production architecture and platform engineering work.

References

1. AWS Security Bulletin 2026-166-AWS: CVE-2026-119923 and CVE-2026-119924
2. AWS CVE record: CVE-2026-119923
3. AWS CVE record: CVE-2026-119924
4. AWS Aurora: managing Babelfish version updates
5. AWS Aurora: upgrading a Babelfish cluster
6. Babelfish for PostgreSQL documentation
7. Rajagupta546, “Networking Rack,” CC BY-SA 4.0, Wikimedia Commons

Prepared by: Noor Yasser

Prepared by: Noor Yasser