Redshift JDBCの任意コード実行を修正｜接続設定と稼働中のJARを確認

Amazon RedshiftへJavaから接続するアプリやジョブでは、実行環境のJDBCドライバーを確認してください。AWSセキュリティ告知 2026-168-AWSは2026年11月3日（米国太平洋標準時、日本時間4日）、2.3.0未満で接続URLやAWS認証情報プロファイルの設定値をきっかけに、アプリのJVM内で任意コードが実行される可能性があると公表しました。CVE-2026-119084です。修正版の2.3.0以降へ更新し、再配備後に実行中のプロセスが新しいドライバーをロードしていることを確かめます。

点検を急ぐのは、顧客や外部システムから接続設定を受け取る分析ツール、データ取り込みサービス、接続テスト機能です。固定設定の定期ジョブも更新対象ですが、攻撃者が設定へ到達できるかで優先度は変わります。Redshiftクラスターのエンジンを更新しても、接続するJava側のJARは置き換わりません。

SQLを送る前の接続設定が入口になる

AWSのGitHubセキュリティ勧告によると、旧版は特定のJDBC接続URLパラメーターやAWS認証情報プロファイルのフィールドを処理する際、アプリのクラスパス上にあるクラスを読み込んでコードを実行することがあります。影響が出るのは接続先データベースではなく、ドライバーを呼び出すアプリ側のJVMです。任意のJavaコードが必ず実行できるという意味ではなく、攻撃者が対象の設定値に影響を与えられることや、利用できるクラスなどの条件が関係します。

通常の検索画面でSQLの検索語だけを入力できることは、接続設定を書き換えられることとは別です。プリペアドステートメントはSQLへ渡す値の扱いを変えますが、接続URLや認証プロファイルの値には作用しません。一方、利用者が接続先の文字列を登録できる管理画面や、外部から取り込んだ設定を使って接続を試すワーカーでは、SQLを一度も実行しなくても設定値がドライバーに届き得ます。接続テストに失敗した記録だけで、設定の処理も行われなかったとは判断できません。

AWSのGitHub勧告での評価はCVSS 3.1で8.1（High）です。評価上の権限要件と、個別アプリで接続設定を変更できる役割は分けて考えます。たとえば設定登録画面に認証が必要なアプリでも、登録できる役割が広い、別テナントの設定が共有ワーカーで処理される、あるいは外部ファイルを自動で読み込むなら、JVMの実行権限との隔たりが大きくなります。今回確認したAWS資料には実環境での悪用を確認したとの記載はありません。

設定を受け取る場所から実行環境までたどる

まず、JDBC URLを受け取るフォーム、API、設定ファイル、シークレット管理の参照先を洗い出します。接続先を登録する画面があるなら、ユーザーが指定できるのはホスト名だけか、クエリー文字列を含むURL全体かを確認します。画面上の項目を制限していても、裏側のAPIや一括インポートが任意の設定を受け付けていないかを別に調べます。テスト接続と本番の定期実行が違うサービスなら、両方の入力検証と実行環境が対象です。

次に、AWS認証情報プロファイルを利用している処理で、読み込む設定ファイルを誰が変更できるかを見ます。名前が固定されていても、実体が共有ボリュームやジョブの生成ファイルなら、元の設定を書き換えられる経路が残ることがあります。設定ファイルの書き込み権限と、その内容を取り込むデプロイ経路は別々に確認します。CIのジョブ変数や管理画面で選んだ値からプロファイルが生成される場合は、生成後のファイルだけでなく入力元の変更権限も調べます。

運用台帳には、処理名、設定の入力元、編集できる役割、ドライバーを実行する環境、そこから使える権限を一行ずつ残します。たとえば、顧客が接続設定を保存し、共有ワーカーが検証する構成では、顧客画面の権限よりワーカーが持つ権限の方が影響の判断に役立ちます。反対に、運用チームだけが固定設定を変更できるバッチでは、変更の承認と設定の出所を確認しつつ、通常の更新手順で旧版を除去します。

2.3.0以降へ更新し稼働中のJARを確かめる

修正はAWSのドライバー2.3.0リリースに含まれます。AWSは最新版への更新と、フォークや派生コードにも修正を反映することを推奨しています。GitHub勧告が示すMaven座標は com.amazon.redshift:redshift-jdbc42 です。直接依存に見当たらない場合も、親POMや依存関係の管理設定、コネクターが持ち込む間接依存、アプリに手動で追加したJARを確認します。複数のビルド方式がある場合は、リポジトリ単位ではなく配備物単位で判断します。

Mavenでは該当モジュールで mvn dependency:tree -Dincludes=com.amazon.redshift:redshift-jdbc42 を使い、解決された依存を確認できます。GradleではJavaアプリの例として ./gradlew dependencyInsight --dependency redshift-jdbc42 --configuration runtimeClasspath で実行時の解決結果を確認します。構成名はプロジェクトに合わせてください。いずれもビルドが管理する依存の確認です。外から配置したJARや、別名の成果物へ同梱したドライバーは、この出力だけでは判定できません。

手動配置のある環境では、プラグインのディレクトリ、起動時に追加するライブラリ、コンテナへマウントする共有ファイルも確認します。ビルド時に作った一覧と、実際に配備したイメージやアーカイブの内容を比較してください。ファイル名の変更だけで中身が置き換わるわけではないので、配布元のバージョン情報や自社のビルド記録で確認します。新旧が混在する場合は、どちらが優先されるかを推測するより、不要な旧版を配備物と追加のクラスパスから除きます。

新しい成果物でアプリやワーカーを再起動し、接続を担当するプロセスがどの成果物から立ち上がったかを記録します。必要なら、隔離した検証環境でドライバークラスのコードソースや実装バージョンを確認します。パッケージ形式によってはバージョンが得られないため、その場合はロード元のファイルと配備物の記録を照合します。接続URLや認証プロファイルの全文を出力する必要はありません。ログやチケットには秘密情報を含まない識別子を残します。

正常な接続と入力制限を別々に検証する

更新後は、検証用の接続先に対して、普段使っている認証方式で接続し、読み取り用の確認処理が通ることを確かめます。接続プールを使う構成では、以前の接続を再利用できただけで合格にせず、新しいプロセスから新規接続を試します。複数のワーカーや旧環境が残る段階的な切り替えでは、どの環境で試験したかを記録し、未更新の実行先へジョブが流れないことも見ます。

入力制限の試験では、許可したホストやデータベース名で通常どおり接続でき、未知のオプションや許可範囲外の値はドライバーへ渡る前に拒否されることを見ます。危険なクラス名や攻撃コードを本番へ入力する必要はありません。未定義の設定キー、同じキーの重複、区切り文字を含む値など、無害な試験データで拒否と記録を確認できます。画面の試験が通っても、設定のインポートやAPIに別の処理があれば同様に確認します。

接続できなくなった場合は、まず新旧のどのJARが読み込まれたか、認証方式に必要な設定が残っているか、ネットワークとデータベースの疎通があるかを切り分けます。例外の発生場所を記録し、接続に失敗したという事実だけで修正の影響と決め付けません。旧版への切り戻しが必要になれば、外部設定から接続を実行する機能を制限したうえで、修正版へ戻すまでの期限と責任者を決めます。

すぐに更新できない場合は設定を作る側で絞る

AWSが案内する暫定策は、信頼できない値から接続URLやAWS認証情報プロファイルを組み立てないこと、外部入力が必要なら、許可するパラメーターと値を限定することです。アプリ側では、URLを丸ごと受け取る方式から、必要な項目だけを受け取り、固定したテンプレートへ安全に反映する方式へ寄せると検証箇所を絞れます。接続先を選ぶだけなら、登録済み接続先の識別子を受け取り、実際のURLはサーバー側に保持する方法もあります。

許可リストは、外部値がURL文字列へ結合された後の見た目だけで判断せず、構造を解析した結果に適用します。たとえばホスト名の入力に別のパラメーターを混ぜられないよう、区切りやエンコードを考慮して入力を検証し、必要な値だけを組み立て直します。運用者しか更新できないと考えているプロファイルでも、取り込み元が他チームや外部サービスなら書き込み経路を確認します。これは露出を抑える措置であり、旧版を使い続ける根拠にはしません。

不審な変更があればアプリ側の証跡を優先する

接続設定に想定外の値が見つかった場合、変更時刻、変更者、対象ジョブ、どのワーカーが設定を読み込んだかを照合します。設定の監査履歴、ジョブ実行記録、JVMの起動や例外のログ、外向き通信の記録があれば、同じ時刻軸に並べます。データベースの監査ログは補助情報になりますが、この脆弱性はアプリ内でコードが動く可能性があるため、SQLが記録されていないだけでは調査を終えられません。

実行の疑いがあるときは、組織の初動手順に従って証跡を保全し、そのプロセスが参照できたファイル、接続先、サービス資格情報を基に影響を判断します。シークレットを交換する必要があるかは、更新の完了とは別の判断です。更新票を閉じる際は、修正版の配備、実際のロード元、通常接続の確認、外部設定の制限、疑わしい変更の有無をそれぞれ記録しておくと、後から再調査が必要になったときに範囲を絞れます。