Babelfishの認証前コマンド実行を修正 Auroraの更新とTDS接続制限を確認

AWSは日本時間11月7日、SQL Server向けのアプリケーションをPostgreSQLで動かす互換機能Babelfishについて、TDSプロトコル処理の脆弱性2件を公表しました。特にCVE-2026-119923は認証前の接続処理にあり、細工された通信でデータベースプロセスの権限によるOSコマンド実行につながるおそれがあります。利用するWebアプリのログインやデータベースの強いパスワードだけでは、この認証前の経路を防げません。

対象はBabelfishを有効にしたデータベースです。運用担当者はTDSポートへの接続元を必要なアプリケーションなどに絞り、稼働するAurora PostgreSQLとBabelfishの両方の版を確認して更新してください。AWS：Babelfishの2件に関するセキュリティ告知は米国太平洋標準時11月6日10時、日本時間では11月7日3時の公表です。本稿は同告知と公式CVEレコードを基に、接続条件と更新の判断を整理する脆弱性ニュースです。

接続前と接続後で異なる2件の影響

CVE Program：CVE-2026-119923は、TDSのpreloginパーサーにおけるヒープベースのバッファーオーバーフローを説明しています。TDSポートに到達する認証不要の攻撃者が、不正な形式のパケットを送ることで、データベースのプロセス利用者としてOSコマンドを実行する可能性があります。同じ接続前パーサーのNULLポインター参照の問題も、このレコードにまとめられています。Amazonが登録した評価はCVSS v3.1で9.8、v4.0で9.3、いずれもCriticalです。本記事で示す重大度はこのCVEに対する値です。

もう一つのCVE Program：CVE-2026-119924は、TDSのRPC要求に含まれる手続き名を処理する際の境界外読み取りです。こちらは認証済みのリモート利用者が、細工された要求で隣接するプロセスメモリーを読んだり、サービス拒否を起こしたりする可能性があります。Amazonの評価はCVSS v3.1で8.1、v4.0で7.2です。認証不要のコマンド実行と、認証後の読み取り・停止を同じ攻撃条件として扱わず、到達できる接続元と認証情報を持つ利用者をそれぞれ点検します。

今回確認したAWS告知には、実環境での悪用を確認したという記述はありません。これを悪用がないという証拠にはせず、まず未認証で到達できるDBを優先して対応します。また、通常のPostgreSQL接続を利用するすべてのDBに同じ問題があるという告知でもありません。Babelfishを使っているか、TDSの接続先を提供しているかが確認の出発点です。

PostgreSQLの版だけでは修正の有無を決めない

オープンソース版についてAWSは、Babelfish 1.0～1.5、2.1～2.15、3.1～3.12、4.0～4.8、5.1～5.4を影響範囲として列挙しています。修正は4.10、5.6、6.1に含まれます。独自にビルドした環境では、PostgreSQLの版が新しいだけでBabelfishの修正まで入っているとは判断せず、配布物に含まれる互換拡張の版と適用した修正を確認します。

Aurora PostgreSQLでは、同じBabelfishのメジャー系列にも複数の修正パッチがあります。たとえばAWS告知には、Aurora PostgreSQL 16.8.8（Babelfish 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）が修正を含む版として挙がっています。「Babelfish 4系は4.10未満なら全部未修正」という読み方では、Aurora向けに提供された修正を見落とします。

同様に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）が挙がっています。18系は18.3.4（6.0.2）と18.4.1（6.1.0）です。13～15系も含む完全な一覧はAWS告知で照合します。ここに例示した版だけを更新候補の全体とせず、現在の系列、適用可能な更新先、保留中のメンテナンスを組み合わせて判断してください。

AuroraではBabelfishだけを独立して更新できず、対応するAurora PostgreSQLクラスターを更新します。AWS：Babelfishクラスターの更新は、メジャー・マイナー更新前に保留中のメンテナンスを適用するよう案内しています。更新予約を入れただけでは修正を適用したことになりません。作業後に実際のエンジンと互換拡張の版を再取得して、計画した組み合わせへ移ったことを確認します。

TDSの入口と接続元を先に絞る

AWSが提示する更新までの回避策は、VPCセキュリティグループでTDSポートへのネットワークアクセスを信頼できる接続元に制限することです。既定のTDSポートは1433です。ポート番号を変更している環境では、既定値だけを検索して点検を終えず、DBの設定とアプリの接続文字列から実際の待受先を確認します。PostgreSQL用の接続経路に制限があっても、TDS側が同じ制限とは限りません。

実施する際は、アプリサーバー、バッチ処理、運用用接続元を洗い出して、利用目的ごとに必要な到達元を残します。本サイトの提案として、接続元を減らす変更は代表的な処理の疎通確認と組み合わせます。すべての通信を広く許可し直して復旧するのではなく、足りない接続元を特定して必要な範囲だけ追加します。不要なテスト環境や、以前の移行作業用の接続元が残っていないかも確認します。

同じVPCにあることだけを信頼の根拠にしないでください。認証前の問題では、DBのログイン権限を付けていないワークロードでも、TDSポートへの到達が許されていれば攻撃の入口に届くためです。一方、正規の接続元を残した場合、その内部からの攻撃リスクは残ります。ネットワーク制限を更新の代わりにせず、修正を適用するまでの露出を減らす措置として位置付けます。

更新前後に同じ方法で版と業務動作を確認する

Auroraの版確認にはAWS：Babelfishのバージョン確認を使えます。TDSで接続したセッションでは、SELECT CAST(serverproperty('babelfishversion') AS VARCHAR) でBabelfishの版、SELECT aurora_version() AS aurora_version でAuroraの版を取得します。SQL Serverとの互換性を示す表示だけを見ず、この二つを記録してAWS告知の組み合わせと突き合わせます。照会のために新たな公開経路を開けず、既に許可された管理経路から確認します。

作業計画では、更新先が同じメジャー内のパッチなのか、別メジャーへの移行なのかを分けます。AWSのガイドでは、メジャー更新には対象版に合うカスタムDBクラスターパラメーターグループなどの準備が必要です。緊急対応を理由に、修正が含まれる最小のパッチと、互換性評価が必要なメジャー移行を混同しないようにします。利用できる更新先と保守手順は、対象リージョンと稼働環境で確かめます。

更新後の試験では、まず許可したアプリケーションから接続でき、通常の読み取り・更新や代表的なストアドプロシージャーが動くことを確認します。次に接続を許していない確認用ホストから、TDSポートに到達できないことを確認します。この二つは別の合格条件です。ログインが成功しただけではネットワーク制限が効いたか分からず、ポートが閉じたことだけでは業務が正常に動くか分かりません。試験は自社管理下の環境に限って実施します。

セルフホストのBabelfishでは、配布物の更新だけでなく、各拡張の更新が必要です。Babelfish：4.10.0のリリースノートは4系から4.10への更新でdump/restoreが不要としつつ、拡張の更新手順を示しています。これは全系列の移行が無条件で同じ方法になるという意味ではありません。稼働するPostgreSQLとBabelfishの組み合わせに対応するリリース手順に従い、更新後も古い拡張が残っていないことを確認します。

停止や再起動の履歴と侵害の確認を分ける

境界外アクセスに起因する問題では、異常終了や接続エラーが調査のきっかけになることがあります。ただし、それらだけで今回の脆弱性が悪用されたとは確定できません。本サイトの提案は、更新前に利用可能な範囲でDBのエラーや再起動履歴、ネットワーク側の記録、構成変更の履歴を保全し、不審な時間帯や接続元を後から照合できるようにすることです。負荷や別の不具合による停止と混同しないようにします。

逆に、認証失敗が見当たらないだけでCVE-2026-119923の影響を否定することもできません。問題は認証前のパーサーにあり、アプリのログイン履歴に残る処理と同じとは限りません。今回の公式資料には、過去の侵害を一つの照会で否定できる検査方法は示されていません。不正な処理の実行を示す別の証跡が見つかった場合は、パッチ作業とは別にインシデント対応として調査範囲を決めます。

最後に、更新したクラスター名、適用後のAuroraとBabelfishの版、TDSポート、許可した接続元、業務試験と拒否試験の結果を一緒に残します。開発・検証・災害復旧用に同じ構成を持つ環境も確認対象です。一つの本番クラスターの更新だけで全体を完了にせず、稼働していない環境を再開する際にも修正済みの版と接続制限が引き継がれるよう、配備手順へ反映します。