Originally published on nooryasser.com. This DEV edition condenses the operational response for database and platform teams.
AWS published security bulletin 2026-166-AWS on November 6, 2026 for two memory-safety flaws in the 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. The AWS CVE record describes a heap-based buffer overflow in the prelogin parser that may allow arbitrary operating-system commands as the database process user.
CVE-2026-119924 requires an authenticated TDS session. It may expose adjacent process memory or crash the database process.
The response is not simply “block port 1433.” Restrict reachability immediately, identify every affected deployment, upgrade to a fixed build, replace every live process, and verify the runtime that actually serves traffic.
The decision in one table
| Observed state | Safe conclusion | Action |
|---|---|---|
| Babelfish is not installed and no TDS listener exists | These two flaws do not apply | Preserve inventory evidence and close the ticket |
| An affected open-source Babelfish line is installed | The pre-auth and post-auth parser paths may be reachable | Contain, upgrade to 4.10, 5.6, or 6.1+, then verify |
| Aurora PostgreSQL has Babelfish enabled on an affected build | The extension cannot be patched independently | Upgrade to the matching fixed Aurora engine build and apply pending maintenance |
| The version is unknown but TCP 1433 is reachable | Exposure cannot be disproved | Restrict reachability first, then identify and patch |
| A fixed version is installed but old processes remain | Control-plane state is not runtime proof | Restart or fail over, then verify every serving node |
What is actually vulnerable?
Babelfish lets SQL Server clients communicate with PostgreSQL through a TDS endpoint. That compatibility boundary must parse client bytes before translating requests into PostgreSQL behavior.
The two bugs sit at different stages:
- CVE-2026-119923 — critical, pre-authentication. AWS identifies a heap-based buffer overflow in TDS prelogin parsing. A malformed packet may allow command execution as the database process user.
- CVE-2026-119924 — authenticated. AWS describes an out-of-bounds read in TDS RPC procedure-name parsing. A remote authenticated user may read adjacent process memory or cause denial of service.
The first bug crosses the authentication boundary. SQL authentication, database roles, and application permissions do not prevent a client from reaching the vulnerable handshake parser.
AWS lists these open-source Babelfish ranges as affected:
- 1.0–1.5
- 2.1–2.15
- 3.1–3.12
- 4.0–4.8
- 5.1–5.4
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, so they need a supported upgrade plan.
Aurora is more granular because the Babelfish version is coupled to an Aurora PostgreSQL engine build. Use the exact branch matrix in the AWS bulletin. Fixed examples 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.
Those examples do not override intermediate-version or major-upgrade constraints.
Inventory before choosing a target
Create one evidence row per cluster, not one row per cloud account. Record:
- owner, environment, and region;
- endpoint and every source allowed to reach TDS;
- Aurora engine version and Babelfish version;
- maintenance policy and pending maintenance;
- planned upgrade target and rollback owner.
For Aurora, enumerate engine versions that support Babelfish:
aws rds describe-db-engine-versions \
--region eu-west-1 \
--engine aurora-postgresql \
--query '*[]|[?SupportsBabelfish==`true`].[EngineVersion]' \
--output text
Then query the real 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 raw command output, timestamps, and the 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
AWS recommends restricting the default TDS port, TCP 1433, to trusted sources until the upgrade is applied.
Use application security-group references or narrow CIDRs. Remove broad internet routes, shared corporate ranges, and temporary administration networks that do not need TDS.
Check the whole path:
- public endpoint settings;
- VPC routes and security groups;
- network ACLs and transit gateways;
- Kubernetes egress paths;
- TCP proxies or load balancers in front of the cluster.
A restrictive database security group can still 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, and it does not fully address CVE-2026-119924 when a trusted or compromised application identity is allowed through.
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 schemas and TDS clients, install signed release artifacts from the official project, update extensions in the documented order, and replace every database process.
Do not copy one shared library into an old image. Build an immutable package or image set and record its digests.
Babelfish for Aurora PostgreSQL
Babelfish cannot be upgraded independently from its Aurora PostgreSQL cluster. Select a fixed engine build from the AWS matrix that is a valid target from your current version.
Use a clone or restored snapshot for rehearsal. Verify parameter groups, representative T-SQL, stored procedures, transaction behavior, drivers, failover, and connection-pool recovery. Apply any pending maintenance named by AWS; selecting a version in the console is not completion evidence.
A safe rollout sequence
- Assign ownership. Export the authoritative cluster inventory.
- Contain. Restrict TDS to the smallest verified source set.
- Snapshot and rehearse. Use an isolated clone or restore. Do not send malformed proof-of-concept traffic to production.
- Patch a canary. Upgrade a representative non-production or low-risk target.
- Exercise contracts. Test login, prepared statements, RPC/stored procedures, transactions, failover, and pool recovery.
- Roll production in bounded waves. Watch connection errors, process restarts, latency, replication health, and application errors.
- Prove runtime state. Query the version through both TDS and PostgreSQL paths after restarts or failovers.
- Review the exposure window. Preserve relevant logs and investigate anomalies without turning noise into a breach claim.
Define the verification contract before the change
Call the rollout complete only when these layers pass:
- Control plane: the Aurora engine target or immutable artifact digest matches the approved change.
- Runtime: every serving node reports a fixed Babelfish version after process replacement.
- Network: TCP 1433 accepts only approved application sources.
- Application: representative login, RPC, transaction, and failover tests pass.
- Operations: restart, memory-fault, connection-reset, and error-rate signals stay within thresholds.
- Recovery: snapshot/restore and rollback procedures remain executable.
A green dashboard is necessary but not sufficient. It may aggregate away one old reader or secondary endpoint.
Patch status is not incident status
The AWS bulletin describes possible confidentiality, integrity, and availability impact. It does not report active exploitation.
Keep three states separate:
- Vulnerable: an affected version and reachable path existed.
- Attempted exploitation: telemetry shows crafted traffic consistent with a vulnerable path.
- Confirmed compromise: independent evidence shows unauthorized execution, access, persistence, or business impact.
Review listener exposure history, security-group changes, proxy logs, database crashes or restarts, unusual connection bursts, and operating-system activity available from the platform. A restart may be benign; a malformed connection may be a scanner. Neither alone proves command execution.
Anti-patterns to 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 live processes.
- Choosing an Aurora target without validating the supported upgrade path.
- Running exploit payloads against production to prove reachability.
- Claiming compromise from version inventory or one crash event alone.
Executive checklist
- [ ] Every Babelfish or 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 or clone rehearsal covers TDS, RPC, transactions, and failover.
- [ ] Every serving process and reader reports a fixed version.
- [ ] Exposure-window evidence is preserved and assessed without unsupported breach claims.
- [ ] Containment remains in place after patching.
Top comments (0)