AWS用PyAthenaに情報流出の脆弱性 CVE-2026-65321、3.35.4へ更新を

AWSの「Amazon Athena」にPythonから接続するための部品「PyAthena」に、外部から受け取った値にSQLの命令を混ぜ込まれる脆弱性が見つかりました。CVE-2026-65321、10点満点で9.8という最も深刻な部類の評価です。修正版の3.35.4は7月31日に公開されています。

PyAthenaは月に2,352万回ダウンロードされている部品です。ただし誰もが危ないわけではありません。影響を受けるのは、データの削除（DELETE）または集計結果からの表の作成（CTAS）を行う文に、利用者の入力など信頼できない値をそのまま渡していたアプリだけです。条件は後半で整理します。

むしろ厄介なのは別の点でした。この脆弱性は2026年8月3日の時点で、GitHubの警告データベースにもOSVにも登録されていません。つまりDependabotなどの自動検知はまだ何も知らせてきません。加えて、更新したくても更新できない下流のツールが複数あります。

PyAthenaとは何か。使っている自覚がない場合も

Amazon Athenaは、AWSに保管したファイルに対してSQLを直接投げられるサービスです。サーバーを用意せずに大量のログや売上データを集計できるため、データ分析の基盤としてよく使われています。

PyAthenaは、そのAthenaにPythonからつなぐためのクライアントです。AWSが公式に配布しているものではなく、個人が始めたオープンソースのプロジェクトで、MITライセンスで公開されています。開発しているのはlaughingman7743という日本のエンジニアで、2026年2月にはリポジトリを個人のアカウントからpyathena-devという組織へ移し、独自ドメインでドキュメントを公開する体制に移行しています。

重要なのは、PyAthenaを直接使っている自覚がなくても入っている場合があることです。GitHubが把握しているだけで2,240のリポジトリと168のパッケージがこれに依存しています。実際に依存関係を確認したところ、次のツールがPyAthenaを取り込んでいました。

※AWS公式のPythonライブラリであるawswranglerは、PyAthenaを使わず独自にAWSのAPIを呼んでいるため対象外です。BIツールのMetabaseもPythonで書かれていないため関係ありません。

誰が狙い、何をされるのか

この穴で立場が危ういのは、検索フォームや問い合わせ画面など、外部の人が文字を打ち込める窓口を持ち、その値を使ってAthenaに問い合わせているサービスです。攻撃者はそのサービスの利用者になりすます必要すらなく、公開された入力欄に細工した文字列を打ち込むだけで足ります。

攻撃者が行うのは、入力欄に「'」（シングルクォート）を混ぜて、そこで文字列を打ち切り、その後ろに自分のSQL命令を書き足すことです。開発者は「PyAthenaが安全に処理してくれる」と信じて値を渡していますが、後述する理由でその処理が効かない文が2種類ありました。

結果として何が起きるかは、そのアプリがAthenaに接続するときに使っているAWSの権限次第です。開発元の警告は、本来見えないはずの別の表からデータを抜き出すこと、データを破壊する命令を実行すること、攻撃者が指定した場所に攻撃者が指定した内容の表を作らせることを挙げています。サービスの利用者にとっては、自分とは無関係の他人の情報まで一括で外に出る恐れがあるということです。企業側にとっては、分析基盤に置いた全社データが1つの入力欄から抜かれうる、という話になります。

原因はAthenaが「SQLの方言」を2つ持っていること

SQLでは、文字の値を「'」で囲んで表します。利用者の入力に「'」が混ざっていると、そこで囲みが終わってしまい、残りが命令として解釈されてしまいます。これがSQLインジェクション（命令の注入）と呼ばれる古典的な攻撃です。

防ぐには入力中の「'」を無害な形に書き換えます。ところがこの書き換え方には方言があります。Athenaが内部で使っているTrinoというエンジンでは「'」を2個続けて書きます（''）。一方、表の定義まわりの処理で使われるHiveというエンジンでは「'」の前に「\」を付けます（\'）。

問題は、Athena本体が「\」をエスケープ記号として一切扱わないことです。Hive方式で \' に書き換えても、Athenaには「ただのバックスラッシュ1文字＋生の「'」」に見えます。囲みはそこで終わってしまいます。

警告文には具体例が載っています。入力値 a' OR 1=1 -- はHive方式で 'a\' OR 1=1 --' になりますが、Athenaはこれを「a\」という値と、そのあとに続く OR 1=1 -- という命令として読みます。「常に真」という条件が差し込まれ、その後ろは注釈として無視される、という典型的な形です。

DELETEとCTASだけが取り残された理由

では、なぜ一部の文だけが危なかったのか。修正前のPyAthenaは、文の先頭の単語を見てどちらの方式を使うか決めていました。安全なTrino方式に回すのは SELECT、WITH、INSERT、UPDATE、MERGE の5つで始まる文だけ。それ以外はすべてHive方式に落ちる作りでした。

この5つの一覧に、DELETEが入っていませんでした。そしてCTAS（CREATE TABLE ... AS SELECT、集計結果から新しい表を作る書き方）は先頭が CREATE なので、これも一覧に当たりません。どちらもTrinoが実行する文なのに、Hive用の書き換えをされていた、というのが今回の欠陥の正体です。

つまり許可する側だけを列挙して、それ以外を危険な既定へ落とすという設計になっていました。列挙から漏れた文が出た瞬間に穴が開く構造です。この判定処理は少なくとも2.x系の頃から同じ形で存在しており、警告も対象を「3.35.3以下のすべてのバージョン」としています。

修正は「安全側を既定にする」方向へ反転させた

修正は、判定の向きを逆にしました。既定を安全なTrino方式にし、Hiveの処理だとはっきり判別できた文だけをHive方式に回します。コード中の注釈には、この選択が意図的である理由がこう書かれています。Trino方式をHive文に使っても最悪でも表示の乱れで済むが、逆をやると値が文字列を打ち切ってSQLを注入できてしまう、と。

対策はもう一段重ねられています。/* 自動生成 */ DELETE FROM ... のように先頭に注釈を置いて文の種類の判定を欺く手を封じるため、判定前に先頭の注釈を取り除く処理が追加されました。また CREATE TABLE ... AS ... はHive側の判定から明示的に除外されています。テストには先ほどの a' OR 1=1 -- がそのまま使われ、正しく '' へ変換されることが確認されています。

なお、この修正コミットには Co-Authored-By: Claude という行が含まれています。AIに手伝わせて修正を書いた、ということです。前日に扱ったFreeRDPの件では、AIが脆弱性を「見つけた」側として開発元の謝辞に載っていました。見つけるのも直すのも、という状況が同じ週に並んだことになります。

自分は対象か。条件は4つそろったときだけ

NVDの説明文には「未認証の攻撃者が任意のSQLを注入できる」と書かれていますが、これは言い過ぎです。PyAthenaはサーバーではなくクライアントの部品で、攻撃者がPyAthenaに直接つなぐことはできません。開発元の警告自身が「実際に何が起きるかは、そのクエリを実行する権限とスキーマ次第」と限定しています。

実際に危ないのは、次の4つがすべて当てはまる場合です。

SELECTやINSERTしか使っていないアプリは、元から安全な方式に回されていたため影響を受けません。分析基盤では読み取りが大半なので、多くの利用者はこの時点で対象外になります。逆に、利用者の操作に応じてデータを消す機能や、条件を指定して集計表を作らせる機能を持っているなら、確認する価値があります。

警告に書かれていない、もっと強い回避策がある

開発元の警告が挙げている回避策は「更新するまでDELETEとCTASに信頼できない値を渡さない」というものです。しかし公式ドキュメントを読むと、警告には書かれていないより根本的な逃げ道があります。

PyAthenaは値の受け渡し方式を選べます。既定は「pyformat」で、この場合PyAthenaが自分でSQL文の中に値を埋め込んでから送ります。今回問題になった書き換え処理は、この埋め込みの過程で使われています。

これを「qmark」に変えると、値はSQL文に埋め込まれず、Athena側の正式なパラメータ機能（プリペアドステートメント）に渡されます。値と命令が最初から分けて運ばれるため、書き換えの巧拙が関係なくなります。今回の欠陥の影響も受けません。設定は次の1行です。

pyathena.paramstyle = "qmark"

もちろん既存のコードの書き方を変える必要があるため、その場で切り替えられるとは限りません。ただし、今回の1件に限らず「値を文字列に埋め込む」方式そのものが繰り返し事故を起こしてきたことを考えれば、更新とは別に検討する価値があります。データ連携部品への命令の注入という点では、データ基盤Prefectの事例や学習データ基盤Feastの事例も同じ系統の話です。

更新したくてもできない下流のツールがある

ここからが実務上いちばん厄介な点です。「3.35.4に上げてください」で済まない環境が実在します。

PyAthenaを取り込んでいるツールの一部は、依存関係にバージョンの上限を書いています。上限を超える版はインストールされません。実際に各ツールの配布物に書かれた指定を確認し、3.35.4が入るかどうかを機械的に判定しました。

しかも今回の脆弱性の対象は「3.35.3以下」、つまり2.x系も全部含まれます。「3未満」と書いているSupersetやDataHubは、上限の内側に安全な版が1つも存在しないことになります。上限を緩める修正が各ツールから出るまで、その組み合わせでは直せません。

当座の対応としては、上で述べた受け渡し方式の変更か、DELETEとCTASに外部入力を渡している箇所を洗い出して直すことになります。ある部品の上限指定のせいで下流が修正を受け取れない構図は珍しくなく、前日に扱った認証部品Better Authの件でも、途中の部品がバージョンを固定していたために修正が半年間下流に届いていませんでした。自分が使っている部品の内側で何が固定されているかは、依存関係をまとめて調べる記事も参考にしてください。

Dependabotはまだ警告を出さない

開発元の警告は7月31日に公開され、CVE番号も8月3日未明（日本時間）にNVDへ登録されました。それでも自動検知の網にはまだ乗っていません。

確認したところ、GitHubの全体向け警告データベース、脆弱性情報の共通基盤であるOSV、Pythonの公式な脆弱性データベースであるPyPA advisory-database、いずれにも本件は登録されていませんでした。GitHubのDependabotはこの全体向けデータベースを見て警告を出すため、現時点でDependabotを有効にしていても通知は来ません。脆弱性検査サービスのSnykも「PyAthenaに直接の脆弱性は見つかっていない」と表示している状態です。

開発元がリポジトリ上で警告を公開しても、それが全体向けデータベースへ取り込まれるまでには時間差があります。月に2,352万回ダウンロードされる部品でこの状態だということは、自動検知だけに頼っていると、当面のあいだ何も知らないまま過ごすことになるという意味です。米政府CISAの実際に攻撃されている脆弱性の一覧にも本件は含まれていません（ただし一覧の最新版は7月29日付・1,656件で、CVE番号が付く前に作られたものです）。悪用の報告や実証コードの公開も確認できておらず、危険度を予測するEPSSのスコアもまだ算出されていません。

前日の11件とは何が違うのか

本サイトでは前日、同じ8月2日に11件のCVE番号が一斉に登録された件を扱いました。あちらは公開済み・修正済みの警告に、あとから番号だけが付いたものでした。今回のPyAthenaも番号を発行したのは同じVulnCheckで、登録日も同じ8月2日です。しかし性質は正反対でした。

決め手は番号を予約した日です。CVE番号は、公開前にあらかじめ確保しておくことができます。この予約日と、実際に警告が公開された日を並べると、どちらが先に動いたかがわかります。

PyAthenaだけが逆です。番号を先に確保し、修正を作り、修正版と警告を同時に出し、そこにあらかじめ確保した番号を書き込む。これが本来の協調開示の手順です。実際、修正コミットにも、リリースの説明にも、警告本文にも、最初からCVE番号が入っています。報告者としてRahul Karne氏の名前が記載され、VulnCheckが調整役として明記されています。

修正版の公開から警告の公開まで3分、修正版の公開からNVD登録まで2日と2時間半でした。前日の11件が数か月遅れだったことを思えば、まったく違う速度です。同じ組織が同じ日に登録した番号でも、中身の意味はここまで違います。番号を見たら、まず「いつ予約されたか」を見る――これが両者を見分ける最も確実な方法です。

※なお、CVEの記録に申告されている公開日は2026年8月2日ですが、開発元の警告が実際に公開されたのは7月31日でした。2日のずれがあります。

日本発の部品なのに、日本語の情報がない

最後にもう1点。PyAthenaは日本のエンジニアが作り、日本でもAWSのデータ分析でよく使われている部品です。それにもかかわらず、本件を扱った日本語の情報は現時点で1件も見つかりませんでした。

情報処理推進機構などが運営する脆弱性データベースJVN iPediaを検索しても、「PyAthena」「Athena」いずれも該当0件です。JPCERT/CCの注意喚起にもありません。Qiitaには PyAthena に関する記事が14本ありますが、最も新しいものでも4月の投稿で、本件に触れたものはありません。国内メディアの報道も確認できていません。

使い方の記事は日本語で読めるのに、危険の知らせは英語の警告ページを自分で見に行かないと手に入らない。前日のBetter Authの件でもまったく同じ構図を確認しました。日本語で実装を学んだ部品ほど、この差は開きやすくなります。

まとめ

PyAthenaは3.35.4へ更新してください。7月31日に公開済みです。ただし影響を受けるのは、DELETEまたはCTASの文に外部からの入力をパラメータとして渡していたアプリに限られます。読み取りしか行っていない使い方であれば対象外です。

更新できない事情がある場合、値の受け渡し方式を「qmark」に変えると、Athena側の正式なパラメータ機能が使われるため今回の欠陥を回避できます。これは開発元の警告には書かれていない方法です。dbt-athenaやSuperset、DataHubなどはバージョンの上限指定があるため、そのままでは3.35.4を入れられません。各ツール側の対応を待つあいだは、この回避策か該当箇所の見直しで凌ぐことになります。

そして、Dependabotなどの自動検知はまだ動いていません。今回のように「開発元は警告を出しているが、自動検知の網には乗っていない」期間は必ず存在します。使っている部品のうち、止まると困るものについては、リポジトリの警告ページを直接見に行く経路を1本持っておくのが確実です。

参照元

• ▸ GHSA-xwj5-g6cv-4r5c - SQL injection in DefaultParameterFormatter for DELETE and CTAS statements（2026年7月31日）
• ▸ NVD - CVE-2026-65321
• ▸ VulnCheck - PyAthena 3.35.4 SQL Injection via DefaultParameterFormatter DELETE/CTAS
• ▸ PyAthena - 修正コミット（PR #745）（2026年7月31日）
• ▸ PyAthena - Release v3.35.4（2026年7月31日）
• ▸ PyPI - PyAthena
• ▸ PyAthena 公式ドキュメント（paramstyle の説明を含む）
• ▸ AWS - Amazon Athena のパラメータ化クエリ（プリペアドステートメント）
• ▸ MITRE CVE Services - CVE-2026-65321（予約日・公開日の記録）