AWS CDKのRedshift連携にSQL注入｜更新後もPUBLIC権限の監査が必要

AWSは2026年10月26日、AWS CDKのRedshift用実験モジュールにSQLインジェクションの脆弱性CVE-2026-115418があると公表しました。対象は@aws-cdk/aws-redshift-alphaの2.274.0-alpha.0未満です。ユーザー名、コメント、パスワードとして与えた値が、デプロイ時にRedshiftのスーパーユーザー権限で実行されるSQLを変えてしまう可能性があります。

利用者はモジュールを修正版以降へ更新するとともに、既存テーブルのPUBLIC向け権限を確認してください。AWSの公式勧告は、更新してもすでに設定された権限は取り消されないと明記しています。依存パッケージの更新と、データベースに残った状態の確認を別作業として扱うことが今回の重要点です。

対象はRedshift全体ではなくCDKの特定モジュール

今回の対象モジュールは、Amazon Redshiftのユーザー、テーブル、権限を管理する実験的なコンストラクトを提供します。Redshiftを使っているだけで、すべてのクラスターが同じ経路から攻撃されるという告知ではありません。CDKアプリケーションがこのモジュールを利用し、そのプロパティへどのような値を渡しているかが影響判断の出発点になります。

公式GitHub勧告はnpmの@aws-cdk/aws-redshift-alphaと、Pythonのaws-cdk.aws-redshift-alphaを掲載し、影響版を2.274.0-alpha.0未満、修正版を2.274.0-alpha.0としています。AWS速報本文は修正先を2.274.0と略記していますが、実際に導入するパッケージはalphaを含む完全なバージョンで確認します。CDK CLIの番号だけを見て対象外と判断しないでください。

運用上は、アプリの依存定義、ロックファイル、CIのインストール結果をそろえて確認します。複数リポジトリが同じ基盤を配備している場合、共通テンプレートだけでなく個別プロジェクトに固定された依存も対象です。開発端末の最新版と、実際にデプロイを行った環境の版が異なることがあるため、どの成果物が本番へ反映されたかを追えるようにします。

攻撃にはコンストラクトへ渡す値を変えられることが必要

AWSの説明では、悪用にはCDKアプリケーションのコンストラクトプロパティへ影響を与える能力が必要です。細工したユーザー名、コメント、パスワードが渡されると、デプロイ時に意図と異なるSQLが実行されます。インターネットからRedshiftの接続先へアクセスするだけで成立する認証不要攻撃として扱うのは不正確です。

公式評価はCVSS v3.1で7.3、重要度Highです。ベクトルはローカル攻撃、低い権限、利用者の関与を前提としています。一方、実行されるSQLはクラスターの管理資格情報を使うため、入力値を変える権限が小さくても、データベース側では強い権限の処理へつながります。公開Webフォームの入力検証とは異なり、配備定義から管理SQLへの信頼境界を確認する問題です。

例えば設定管理サービス、生成処理、他部署から受け取るメタデータ、レビュー前の変更をコンストラクトへ渡す構成がないかを調べます。これは本サイトが提案する調査対象であり、AWSがこれらすべてで攻撃を確認したという意味ではありません。固定値に見える項目でも、値の生成元と変更可能な担当者、配備の承認者までたどって判断します。

更新してもPUBLICの権限が戻らない理由

修正版は今後実行するSQLの生成を修正するものです。すでにデータベースへ書き込まれたアクセス権は別の状態として残ります。公式勧告は影響の例として全クラスター利用者へのアクセス付与を挙げ、更新後に既存テーブルのPUBLICへの付与を見直すよう求めています。脆弱なコードがなくなったことと、不適切な権限がなくなったことは別々に確認する必要があります。

監査では、現在の付与内容を正規の設計書や配備定義と比較します。PUBLICの権限があるだけで侵害を断定することも、昔からある設定だから安全と決めることも避けます。業務上必要な共有、検証時の設定残り、意図しない変更を区別し、対象テーブル、許可された操作、設定理由、変更時期を記録してください。

すべてのPUBLIC権限を一括で削除する手順は勧めません。正当な共有を止める可能性があり、業務影響を評価せず実行すると復旧が難しくなります。まず状態を保存し、オブジェクトの管理者と期待する権限を確認し、検証環境で必要なアクセスが維持されることを確かめてから、意図しない付与だけを取り消します。

最初に依存関係と配備履歴を棚卸しする

以下は本サイトの対応手順案です。最初に対象パッケージを使うCDKアプリケーションを一覧にし、直近の配備日時、対象クラスター、配備担当者、依存版を対応付けます。リポジトリだけでなくCIのキャッシュや固定されたビルド環境も見ます。古いロックファイルを使って再配備できる状態が残ると、更新後に再び旧版を持ち込む原因になります。

次にユーザー名、コメント、パスワードの供給元を調べます。コードに直接書かれた値、環境ごとの設定、秘密情報管理から取得する値、外部データから生成する値を区別します。秘密情報の内容をチケットやログへ貼り付ける必要はありません。値そのものの公開ではなく、どの経路で誰が変更できたかを追うことが目的です。

配備履歴から不審な入力が見つかっても、それだけでデータ流出を断定しません。変更がレビューで止まったか、実際に配備されたか、該当処理が実行されたか、権限変更が成立したかを順番に確認します。反対に、Gitの差分が見当たらない場合でも、別管理の設定値が変わる構成ならコード履歴だけで否定できません。

修正版を導入し生成物と実行環境を確認する

更新は対象モジュールを2.274.0-alpha.0以降の修正を含む版へ上げるところから始めます。独自フォークや派生コードを使っている場合も、上流の修正が取り込まれているかを確認するようAWSは求めています。パッケージ名が異なる社内ラッパーに置き換わっている場合、表面の版ではなく内部で利用する実装までたどります。

更新後はクリーンな依存解決を行い、インストールされた版とロックファイルを照合します。そのうえで合成結果と配備差分をレビューし、Redshift以外のリソースに予期しない変更が混ざっていないかを見ます。実験モジュールの更新で型や設定が変わる可能性もあるため、単純にビルドが通ったことだけを完了条件にしないでください。

本番へ進める前には、通常の名前、空欄を許す項目、引用符やバックスラッシュを含む業務上有効な文字列などを検証用データで確認します。攻撃用SQLを本番で試す必要はありません。入力が意図した一つの値として扱われること、既存の正常な配備が壊れないこと、管理権限や共有先が期待どおりであることを評価します。

権限監査は更新とは別の完了条件にする

配備後にもう一度、対象テーブルのPUBLIC向け権限を取得し、更新前の記録と比較します。望ましくない付与がある場合は、修正版を導入しただけで消えることを期待せず、管理者が必要な是正を行います。どの権限をなぜ戻したかを記録すると、後続の自動配備が同じ設定を再作成したときにも原因を追えます。

権限を狭めた後は、共有ユーザーと業務用アカウントの正常系も確認します。管理者としてアクセスできるという試験だけでは、一般ユーザーへ過剰に開いているか、逆に必要な権限を失ったかが分かりません。期待する利用者は必要な操作だけ成功し、対象外の利用者はアクセスできないという両側の確認を用意します。

監査対象の範囲は、そのCDKアプリが管理するテーブルから始め、疑わしい変更が確認された場合に関連範囲へ広げます。今回の勧告から、すべてのAWSアカウントや全Redshiftクラスターで侵害があったとは言えません。調査済み、対象外、情報不足を分け、証拠のない安全宣言や侵害宣言を避けてください。

更新までの回避策と限界

AWSが示す回避策は、ユーザー名、コメント、パスワードへ信頼できる開発者が作成した値だけを使い、既存のPUBLIC権限を確認することです。外部入力を単純に文字数制限するだけの方法は、公式の修正を代替しません。値を変えられる経路を絞り、レビュー済みの配備定義からだけ実行する運用を暫定措置として位置付けます。

緊急対応中は新規デプロイを止めるかどうかも業務影響と合わせて判断します。既存のデータベース稼働を止める必要があると公式が一律に求めているわけではありません。信頼できない値が入り得る変更を止めること、修正版を準備すること、すでに付いた権限を確認することの優先順位を決め、担当と期限を割り当てます。

今回確認したAWS公式速報とGitHub勧告は、実環境での悪用確認や被害件数を示していません。これを悪用がない証拠とすることはできませんが、未確認の侵害や具体的な攻撃グループを記事へ補う根拠にもできません。公開情報による更新判断と、自社のログ・設定による侵害確認を区別します。

対応完了を判断するチェック項目

完了条件は、対象アプリと配備先を特定したこと、実行環境が修正版を使うこと、独自派生にも修正があること、PUBLICへの既存付与を確認したこと、必要な是正と業務試験を終えたことです。依存更新のチケットと権限監査のチケットを分けても、両方が完了するまで案件全体を閉じない運用にします。

デプロイ用コードは開発者だけが触るため安全だと考えがちですが、外部由来の設定値や変更可能なプロパティが管理SQLへ渡ると、権限の境界を越える場合があります。今回の対策はパッケージ更新を入口に、配備時の入力と実際のデータベース権限を突き合わせることです。更新後に残る状態まで確認することで、修正の取りこぼしを減らせます。