AWS SDK for pandasに結果保存先の検証不備｜AthenaとS3の所有者を確認

AWSは2026年10月28日、AWS SDK for pandasのAthenaモジュールにおける所有者検証不備CVE-2026-118029を公表しました。対象はPythonパッケージawswranglerの3.16.1未満です。既定のクエリ結果保存先を利用する構成では、第三者が先に用意したS3バケットへ結果が渡り、閲覧や返却結果の改ざんにつながる可能性があります。

対象の開発・運用担当者は、SDK更新と並行して、アカウント・リージョンごとの結果保存バケットの所有者を確認してください。明示的に自分のアカウントが所有する保存先を指定するか、ワークグループ側で保存先を強制することが公式の回避策です。S3を非公開に設定したという確認だけでは、今回の問題の確認は終わりません。

本記事は11月2日に確認したAWS公式速報、開発元アドバイザリ、Athena公式文書に基づくニュース解説です。特定企業の漏えい事件や実際の攻撃成功を報告するものではありません。以下の点検・試験例は本サイトの提案であり、実環境で攻撃を再現した結果ではありません。

何が誰に影響するのか

AWS公式速報によると、AWS SDK for pandasは、pandasとAthena、S3、AWS Glueなどを連携するオープンソースのPythonライブラリーです。今回の対象はそのAthenaモジュールであり、pandas本体やAthenaサービス全体に同じ不備があると説明されているわけではありません。Web管理画面の集計、定期レポート、分析用ノートブックなど、awswranglerを使う処理を棚卸しします。

公式のGHSA-34f4-24c9-rgcmは、明示的な自アカウント所有バケットを指定せず、既定の結果保存先を使う条件に依存するとしています。攻撃者がその既定バケットを先に作成することで、クエリ結果を読み、呼び出し元へ返る結果セットを改ざんできる可能性があります。単なる可用性の問題ではなく、機密性と完全性の両方に関係します。

例えば、集計結果を人が読むだけのレポートと、返った値を次の業務処理へ渡すアプリでは、改ざんされた場合の影響が異なります。本サイトの提案として、保存先の確認と併せて、結果を何に利用するかも記録します。元データが正しく保管されていても、途中の結果セットが信頼できなければ、業務判断の根拠が変わる可能性があるためです。

修正版と公表日を分けて管理する

影響版は3.16.1未満、修正版は3.16.1です。AWS速報は修正版が5月に公開済みであることを説明し、開発元のリリースノートにはAthenaのバケット所有者とマニフェスト整合性の検証修正が記載されています。10月28日は今回の脆弱性公表日であり、修正版が初めて配布された日として扱わないようにします。

公式は最新版への更新と、フォークや派生コードへの修正取り込みを推奨しています。パッケージの版を上げる作業と、修正内容が実行環境へ反映されたことの確認は別です。開発用の仮想環境だけでなく、コンテナ、ジョブ、ノートブック、Lambdaレイヤーなど、実際にawswranglerを読み込む場所を確認してください。

依存定義を更新しても、古いイメージやレイヤーが配布される構成では稼働版は変わりません。本サイトでは、依存定義、解決された版、配信成果物、実行先を一つの対応票へ記録することを提案します。独自フォークを使う場合には、上流の版番号を名乗っているかだけでなく、修正差分を取り込んだかをコードで確認します。

最初にアカウントとリージョンを確定する

公式回避策は、各アカウント・リージョンの既定結果バケットが自分のアカウント所有であることを確認するよう求めています。管理者の端末で見える一つのバケットだけを調べて完了とせず、処理を実行するAWSアカウント、リージョン、認証に使うロール、Athenaワークグループを対応付けます。

次に、呼び出し側で保存先を明示しているか、ワークグループ側から設定されるか、どちらにも依存しない既定動作を使っているかを確認します。環境変数や共通関数で値を補っている場合もあるため、一つの関数呼び出しだけで判断しないようにします。設定の存在と、実際に採用された値を区別して確認することが重要です。

所有者を確認できないバケットへ、試しに実データを出力して調べる方法は避けます。本サイトからは、まず構成情報と管理記録で所有者を確認し、検証が必要なら自社管理の環境と無害なデータを使うことを提案します。確認できなかった保存先は、正常と仮定せず未確認として残してください。

明示保存先とワークグループの優先関係

AWS SDK for pandasのread_sql_queryにはs3_outputとworkgroupの設定があります。公式の現行リファレンスでは、これらを使って保存先や実行するワークグループを指定できます。ただし、呼び出し側に保存先を書くだけでは、ワークグループが強制する設定との関係まで確認できたことにはなりません。

Athenaの「Override client-side settings」は、既定では選択されていません。無効の場合はクライアントの設定が使われ、クライアント側に設定がないときはワークグループ全体の設定が適用されます。有効にすると、そのワークグループのすべてのクライアントに対して、結果保存先、期待するバケット所有者、暗号化などのワークグループ設定が強制されます。

したがって、アプリに書いたS3パスと実際の出力先が違う場合、コードの反映漏れだけを疑わずワークグループの上書き設定も確認します。逆に、ワークグループへ正しい保存先を設定しただけで、クライアントからの別指定を防いだつもりにならないことも必要です。保存先の指定と、その指定を強制する設定は別項目です。

ワークグループ側で強制する場合は、他の利用者や自動処理への影響も確認します。AWS文書は、任意のS3バケットに結果があることを前提にした自動化が壊れる可能性があるため、利用者への事前連絡を勧めています。保存先を変えた後は、結果を読む処理、通知、後続ジョブまで含めて確認してください。

ExpectedBucketOwnerで不一致を失敗にする

AthenaのResultConfigurationにあるExpectedBucketOwnerは、結果保存先バケットの所有者として期待する12桁のAWSアカウントIDを指定する設定です。実際の所有者と一致しないと、S3への呼び出しは権限エラーで失敗します。所有者の思い込みを、実行時に検査する条件として持たせるための仕組みです。

ワークグループでもExpected bucket ownerを設定できます。ワークグループがクライアント設定を上書きする場合は、所有者の設定もワークグループ側の値が使われます。アプリ側の設定だけをレビューして終えるのではなく、実際に採用される保存先と期待所有者が同じ管理単位で整っているかを確認します。

この設定には重要な適用範囲があります。AWS文書は、Athenaクエリ結果用のS3出力先にだけ適用され、外部データソース、CTASやINSERT INTOの宛先テーブル、UNLOADの出力先、フェデレーションクエリのスピル先などには適用されないと説明しています。S3へのすべての書き込みを一括して保護する設定ではありません。

read_sql_queryは現行仕様でCTAS方式を既定とし、UNLOAD方式も選べます。採用する方式によって関連する保存先が増えるため、通常の結果保存先とテーブル・エクスポート等の保存先を分けて点検してください。ExpectedBucketOwnerを一つ設定したから派生するすべてのS3経路を確認済み、と報告しないことを提案します。

更新後は無害なクエリで出力先を読み戻す

本サイトの提案する受け入れ試験では、まず更新後の実行環境で無害な小さなクエリを実行し、実行に使われたワークグループ、採用された保存先、結果を読み取る処理を確認します。成功という表示だけでなく、自分たちが管理する保存先へ結果が置かれ、期待した内容をアプリが読んだことを確かめてください。

検証環境では、所有者設定が不一致の場合に処理が失敗し、後続処理が止まることも確認します。第三者のバケットを探したり、実在の他社アカウントへデータを送ったりする必要はありません。自社が管理する試験条件で、エラーが成功扱いされず、古い結果で処理を継続しないことを点検します。

保存先の変更後にアクセス拒否が出た場合は、所有者不一致、S3への権限、暗号化に使う鍵への権限、ワークグループの上書きなどを分けて調べます。エラーを消すために広いS3権限を付ける前に、意図したアカウントと保存先かを確認してください。今回の不備への対応が、別の過剰権限を作る変更にならないようにします。

過去の結果と新しい実行環境を分けて扱う

今回確認した公式資料は、実環境での悪用件数や特定顧客の被害を説明していません。悪用状況は不明とし、読者の環境で漏えいが起きたとも、何も起きていないとも断定しません。修正版を入れることと、過去にどこへ結果を保存したかを確認する作業は別に進める必要があります。

過去の保存先が不明な場合には、残っているクエリ実行記録、構成管理、配信履歴から確認可能な範囲を整理します。不審な結果や所有者不一致が判明したら、関連記録を保全し、担当者へ引き継ぎます。保存先を正しく直しても、以前に作成されたレポートや、その値を使った業務判断が自動で正しくなるわけではありません。

対応票には、稼働するawswranglerの版、対象アカウントとリージョン、結果保存先と所有者、上書き設定、CTAS等の別経路、受け入れ試験、過去分の未確認範囲を残します。SDK更新だけで完了とせず、結果データの行き先と、次回の実行でも同じ安全な構成が使われることまで確認するのが今回の要点です。