SageMaker SDKの既定バケットに所有者確認漏れ｜成果物の改変を防ぐ更新と点検

Amazon SageMaker Python SDKで保存先を省略している環境は、SDKの版と既定のS3バケットの所有者を確認してください。CVE-2026-112408では、第三者が予測可能なバケット名を先に確保すると、学習スクリプトやモデル成果物の読み取り・置き換えにつながります。修正版は2系が2.257.3、3系が3.10.0です。

AWSは2026年10月21日12時30分PDT（日本時間10月22日4時30分）にセキュリティ告知2026-142-AWSを公開しました。本記事は10月25日に一次資料を確認した脆弱性ニュースです。SageMakerでモデルを学習・配備するAIサービスの開発者や、その処理基盤を運用する担当者が対象になります。

新しい環境で既定バケットを使う前に確認する

問題があるのは、保存先を指定しない場合に使われるdefault_bucket()です。開発元の勧告GHSA-5rx8-8fr2-f855によると、SDKはAWSリージョンとアカウントIDからバケット名を決め、同名のバケットが存在すると所有者を確認せず使用していました。

S3のバケット名はグローバルに一意です。攻撃者が対象アカウントの利用者より先に、その名前のバケットを自分のAWSアカウントへ作成すると、SDKが書き込むコードや成果物を読んだり置き換えたりできる可能性があります。置き換えられた成果物が使われると、SageMakerのリモート実行環境でコードが実行され、実行ロールのIAM認証情報が取得されるおそれがあります。

開発元は、対象利用者の既定バケットが自身のアカウントにまだ存在しない場合に限って悪用できると説明しています。すでに自分のアカウントで所有しているバケットが、今回の問題だけで第三者へ移るという説明ではありません。新しいアカウントやリージョンでの初回実行は、この条件を点検する優先対象です。

影響の判定はバージョンと所有者を組み合わせる

実務では、脆弱なSDKが見つかっただけで侵害の有無を結論付けず、保存先の決まり方と所有者を確認します。逆に、学習ジョブが正常終了していても、それだけでは保存先が正しい証拠になりません。今回の問題では、処理を継続できること自体が安全性の判断材料にならないためです。

本サイトは、既定バケットを自アカウントで所有済み、保存先を明示済みだが所有者は未点検、保存先を省略した新規環境、の三つに分けて扱うことを提案します。所有済みなら開発元が示す先取りの成立条件から外れます。明示済みでも名前だけを転記していないかを確認し、新規環境では初回のアップロード前に修正版と保存先を確定します。

仮に本番アカウントでは長年同じバケットを使い、検証アカウントを追加したばかりなら、本番の所有確認だけで検証環境も安全とは判断できません。これは条件を理解するための仮想例です。アカウントやリージョンごとに、実際に使われる保存先を追う必要があります。

Webアプリから公開済みの推論APIを呼ぶだけの担当者と、モデルの学習・配備処理を管理する担当者では、確認範囲が異なります。まずSDKを使うジョブの管理者へつなぎ、利用していないフロントエンドやWebサーバーまで一律に更新対象へ広げないようにします。

2系と3系の修正版を取り違えない

系列	影響する版	修正版
V2	2.257.3未満	2.257.3
V3	3.0.0以上3.10.0未満	3.10.0

影響範囲はAWS告知の系列別表記に基づきます。開発元の評価はHigh、CVSS v3.1基本値は8.1です。攻撃成立にはバケットの先取りなどの条件があり、スコアだけからすべてのSageMaker利用環境が直ちに侵害されるとは判断できません。

修正版のV2リリース2.257.3とV3リリース3.10.0も公開されています。脆弱性の告知は10月ですが、V3のリリースノートには2026年5月1日と記載されています。今回初めて修正版が配布されたという意味ではありません。AWSは利用する系列の最新バージョンへの更新と、フォーク・派生コードへの修正反映を勧めています。

SDKが実際に動く場所と保存先を点検する

本サイトが勧める順序は、まず学習・配備処理で使うPythonパッケージsagemakerの版を調べ、次に保存先を指定しているか確認することです。ノートブック、CIの実行環境、定期ジョブ用コンテナなどを使い分けている場合は、それぞれの依存関係を確認します。手元の環境だけ更新して完了にしないようにします。

すぐに更新できない場合、AWSは自分のアカウントが所有するS3バケットを、sagemaker.Sessionのdefault_bucketパラメーターまたはSDK設定ファイルで明示する回避策を示しています。自動生成される名前への依存をやめるとともに、指定する保存先が意図した所有者のものかを確かめてください。

運用上は、利用するアカウント・リージョン、バケット、実行ロールの対応を整理してから、更新後の処理が想定した保存先を使用しているか確認することを提案します。権限を広げてアクセスエラーを消す対応は、保存先の取り違えを解決しません。

すでに想定外の所有者の保存先を使っていた形跡がある場合は、その成果物を信頼して学習・配備を続けず、処理の停止と調査を優先します。SDKの更新は、過去に書き換えられた可能性のあるコードやモデルが正しいことまで証明するものではありません。ここでの調査順序は本サイトの提案であり、実環境の悪用が確認されたという意味ではありません。

更新漏れを残さないための記録と確認

更新対象を洗い出すときは、リポジトリの依存関係ファイルと実行環境の両方を見ます。依存関係の宣言を直しても、すでに作成したコンテナや、以前の仮想環境がそのまま使われていれば、実行中のパッケージは変わりません。本サイトは、ジョブ名、実行イメージや環境、SDKの実際の版、保存先、担当者を一組で記録することを勧めます。

版の確認には、そのジョブが利用するPython環境でパッケージ情報を参照します。以下はインストール済みの版を表示する確認例で、更新やAWSへの操作は行いません。本サイトで利用者の実環境を試験した結果ではないため、CIやノートブックでは対象のPython環境を選んで実行してください。

python -c "from importlib.metadata import version; print(version('sagemaker'))"

パッケージが見つからない場合も、それだけで組織内に利用箇所がないとは判断できません。確認したPythonとジョブが使うPythonが違う可能性があります。確認結果は実行環境の名前とセットで残すと、手元だけを更新した取り違えを防ぎやすくなります。

V2を使っている環境で、脆弱性対応と同時にV3への移行まで必須と考える必要はありません。AWSは両系列の修正版を示しています。まず利用系列の修正を反映し、依存関係の固定やコンテナの再構築が必要なら通常のリリース手順で進めます。更新後は無害な検証用の入力で、アップロード先とジョブが参照する成果物の場所を確認してください。

所有者を検証する仕組みとその限界

S3には、期待する所有者のアカウントIDをリクエストへ付けるAWS公式資料：bucket owner conditionがあります。所有者が一致しない場合、対応する操作はアクセス拒否になります。独自のS3連携処理を点検する際には、バケット名に加えて所有者も検証しているかが確認点です。

ただし、この仕組みはSDKの修正適用を省くための代替手順ではありません。自分が管理するコードで使う場合も、対象APIが対応しているかを確認します。AWSはCreateBucketやListBucketsなどでは利用できないと説明しています。また、確認できるのは所有アカウントであり、バケットの設定や中のコード・モデルが正しいことまで保証する機能ではありません。

SDK側で保存先がどこから決まるかは、SageMaker Python SDK V3のSessionリファレンスも確認できます。既定値だけでなく、呼び出し側や設定ファイルの指定を追い、実行時に選ばれる保存先を確かめます。このリファレンスはV3用なので、V2のコードを変更するときは利用系列に対応する資料でAPIを確認してください。

不審な保存先が見つかった場合の初動

所有者が想定と違っていた場合、本サイトは、バケット名、使用期間、関係するジョブ、実行ロール、参照した成果物を先に記録することを提案します。原因を切り分ける前に成果物を削除したり、同じ名前へ再アップロードしたりすると、調査に必要な情報や再現条件を失うおそれがあります。調査対象の処理と正常な処理を区別して停止範囲を決めます。

調査では、手元の信頼できるソースやビルド成果物と、ジョブに渡した内容を照合します。モデルの出力が正常に見えることだけで、学習コードや配備用成果物が無改変だったとは証明できません。比較に必要な記録がない部分は、安全だったと推定せず、信頼できる入力からの再作成や再配備を検討します。

実行ロールの認証情報が取得された疑いがある場合は、クラウドのインシデント対応担当者と連携し、そのロールに許可された操作と関連する利用記録を調べます。影響範囲はロールの権限や実際の操作によって変わるため、今回の勧告だけから全アカウントの侵害を断定しません。正常利用への影響も確認しながら、不要な権限や不審な処理の封じ込めを判断してください。

対応を閉じる際は、修正版が実行環境へ反映されたこと、保存先の所有者が正しいこと、利用する成果物の出所を説明できることを別々に確認します。SDKの版だけで完了にせず、今回の脆弱性が越えてしまう「保存先」と「実行する内容」の信頼境界まで確認することが重要です。

関連記事

S3の公開設定や共有経路の点検は、S3の非公開設定と共有リンク・配信経路の確認でも整理しています。リンク先は10月18日時点の一般的なアクセス制御の解説です。今回の保存先の所有者確認と併せて、成果物へアクセスできる主体を点検する際に役立ちます。