Starlette CVE-2026-48710の影響確認と初動対応

冒頭要約

米国CISAは2026年9月2日、PythonのWebフレームワーク／ツールキットStarletteのCVE-2026-48710をKnown Exploited Vulnerabilities（KEV）カタログへ追加しました。Starletteの公式GitHub Security Advisoryでは、request.urlの組み立てに使うHostヘッダーの検証不足により、アプリケーションが認識するURLのパスと実際の要求先が食い違う可能性が説明されています。

まず、自社サービスがStarletteを直接または間接的に利用しているか、実行中のバージョンが1.0.0以下か、request.urlまたはrequest.url.pathを認可などのセキュリティ判断に使っているかを確認します。リバースプロキシがあるだけで安全と決めず、全インスタンスの更新、認可テスト、プロキシ設定、ログ保全を一つの作業票で追ってください。

公式アドバイザリでは1.0.1で修正済みです。影響版かつ外部公開され、パスに基づく認可を行う環境は優先度を上げます。不審なアクセスや説明できない認可結果が見つかった場合は、更新作業だけで閉じず、証跡保全とインシデント対応へ切り替えます。

この記事は2026年9月4日時点の確認結果です

CISA KEVとStarletteの公式アドバイザリは更新される可能性があります。作業開始時に必ず最新情報を再確認してください。CISAの2026年9月16日という期限は米国連邦政府機関向けのもので、日本の全組織に同じ法的期限が適用されるという意味ではありません。

何が起きたか：StarletteのCVE-2026-48710とは

Starlette公式のGitHub Security Advisoryは、影響版でHostヘッダーを検証せずにrequest.urlを再構築していたため、アプリケーションが参照するURLのパスが実際のルーティング先と一致しない場合があると説明しています。request.urlまたはrequest.url.pathを使って特定パスへのアクセス制御を行うミドルウェアや独自実装では、認可判断が意図どおりに働かない可能性があります。

CISA KEVはこの問題をHTTP Request/Response Smuggling Vulnerabilityとして掲載し、実際に悪用された脆弱性として優先対応を求めています。ただし、KEV掲載は「Starletteを含むすべてのアプリケーションで侵害が確認された」という意味ではありません。自社の利用有無、版、実装、公開範囲を分けて確認する必要があります。

確認項目	2026年9月4日時点の公式情報
CVE / GHSA	CVE-2026-48710 / GHSA-86qp-5c8j-p5mr
影響を受ける版	Starlette 1.0.0以下
修正版	Starlette 1.0.1
公式Advisoryの深刻度	Moderate、CVSS 3.1は6.5
主な成立条件	`request.url`または`request.url.path`をセキュリティ上の判断に利用している
CISA KEV追加日	2026年9月2日
CISAの期限	2026年9月16日（米国連邦政府機関向け）
ランサムウェア利用	CISAのレコードではUnknown

本記事では、攻撃を再現するヘッダー例、回避手順、探索方法は扱いません。防御側が対象判定、更新、検証、記録を行うために必要な情報だけを整理します。

なぜ重要か：直接依存でなくても対象になり得る

StarletteはPythonパッケージとして直接導入されるだけでなく、別のWebフレームワークやライブラリを経由して間接的に含まれることがあります。requirements.txtにstarletteが見当たらなくても、lockfile、SBOM、コンテナイメージ、実行中環境では利用されている可能性があります。

一方で、影響版を含むだけで、すべてのサービスに同じ影響が生じるわけではありません。公式アドバイザリが示す重要な分岐は、request.urlやrequest.url.pathを、認可、管理画面の保護、テナント分離、機能制限などのセキュリティ判断に使っているかどうかです。

また、リバースプロキシやロードバランサーによる防御は条件付きです。公式アドバイザリは、プロキシが不正なHostヘッダーを拒否または正規化し、ほかの転送ヘッダーも攻撃者に制御されない場合に限って緩和になり得るとしています。プロキシの存在を更新延期の根拠にせず、修正版への更新を基本にしてください。

読者別の影響

読者	まず確認すること	主な判断
情報システム担当者	Python Webサービスの一覧、外部公開、所有部署、委託先、更新窓口	影響候補を所有者へ割り当て、期限と暫定対策を管理する
開発者	lockfile、SBOM、コンテナ、実行中環境のStarlette版、認可ミドルウェア	影響版と実装条件を確認し、互換性試験後に更新する
SaaS管理者	ベンダー提供SaaSや内製SaaSでの利用有無、公式告知、責任分界	自分で更新できない場合は提供元の対応状況と残リスクを確認する
SRE / クラウド担当者	全Pod・タスク・VMの配布状況、入口のプロキシ設定、ログ	更新漏れと旧イメージの再起動を防ぎ、監視を継続する
CSIRT / SOC	Web、WAF、プロキシ、認証、アプリの各ログと保全期間	認可の不整合や不審なアクセスがあれば調査へ切り替える
個人開発者	公開中のPythonアプリ、ホスティング環境、依存関係	公開サービスを優先して版と更新可否を確認する

まず確認すること：影響調査チェックリスト

依存関係が見つからない場合も、「調査済みのリポジトリや実行環境」と「確認方法」を残します。ソフトウェア資産台帳の作り方とSBOMとOSVで学ぶ依存関係確認を使うと、直接・間接依存を同じ判断表へまとめやすくなります。

初動対応：やること・やらないこと・記録すること

やること

対象を固定する：サービス名、環境、リポジトリ、イメージ識別子、実行中のStarlette版、所有者を記録します。
証跡を先に確保する：更新前のlockfile、SBOM、デプロイ成果物、設定、Web・プロキシ・認証・アプリログを、組織の保全手順に従って保存します。
修正版へ更新する：公式情報に基づき1.0.1以降へ更新します。単に最新版へ飛びつくのではなく、利用中フレームワークが許容する互換範囲と保守方針を確認します。
ステージングで検証する：ログイン、権限別アクセス、管理画面、テナント境界、URL生成、プロキシ経由の通常通信を確認します。
全実行単位へ反映する：古いPod、タスク、VM、関数、待機系、ロールバック用イメージが残っていないことを確認します。
更新後も監視する：認可失敗、通常と異なるパス、Host関連の拒否、想定外の管理操作、説明できないデータ参照を確認します。

更新計画はCVE初動対応チェックリストへ、依存関係とCI/CDの確認は開発ツール・OSSサプライチェーン確認チェックリストへ転記すると、担当者と完了条件をそろえられます。

やらないこと

インターネット上の第三者サービスを探索・検証しない。
requirements.txtに記載がないことだけで「未使用」と判断しない。
WAFやリバースプロキシがあることだけで「影響なし」と判断しない。
本番コンテナ内のパッケージだけを書き換え、再現可能なlockfileやイメージを更新せずに閉じない。
ログや稼働中環境を消去してから調査を始めない。
CISAの期限を日本の全組織に対する法的期限として説明しない。
CVSSがModerateであることだけを理由に、KEV、外部公開、認可用途を無視して後回しにしない。

記録すべきこと

項目	記録例
対象	サービス名、環境、URL区分、所有者、委託先
依存関係	直接・間接、lockfile、SBOM、イメージ、実行中バージョン
実装条件	`request.url`参照箇所、用途、保護対象、レビュー担当
公開範囲	外部公開、認証前到達、VPN内、社内限定
境界設定	プロキシ、ロードバランサー、CDN、信頼する転送ヘッダー
更新	変更前後の版、成果物識別子、実施時刻、担当者、ロールバック
検証	権限別テスト、全インスタンス反映、監視結果、未解決事項
証跡	ログ種別、対象期間、保存先、保全担当者
判断	影響あり・なし・調査中、根拠、承認者、次回確認日時

判断基準：危険度と対応優先度

優先度	条件	初動
緊急	影響版を外部公開し、パスに基づく認可を行い、不審なアクセスまたは認可の不整合がある	証跡を保全し、公開制限、更新、CSIRT・法務・サービス責任者への連絡を並行する
高	影響版を外部公開している、または管理・顧客データ・テナント境界の認可に関係する	当日中に対象、暫定対策、更新計画、ログ確認、責任者を確定する
中	影響版だが内部限定で、セキュリティ判断への利用状況を調査中	到達範囲を維持・縮小し、期限付きで実装確認と更新を進める
低	1.0.1以降への更新と全環境への反映を確認し、認可テストと監視に問題がない	証跡と判断根拠を残し、再発防止の依存関係監視へ移る

次のいずれかがあれば、通常のパッチ作業からインシデント対応へエスカレーションします。

保護対象への説明できないアクセス、認可結果、管理操作がある。
Web、認証、プロキシ、アプリのログで時刻や主体を説明できない。
ログ欠損、設定変更、未知のデプロイ、旧イメージの再起動がある。
顧客データ、認証情報、テナント境界、管理機能への影響を否定できない。
影響版を更新できず、外部公開や認証前到達を止められない。
委託先やSaaS提供元から対象判定、更新状況、証跡を得られない。

データへの不正アクセスが疑われる場合は、漏えい疑い初動テンプレートを使い、事実確認前に被害範囲や原因を断定しないでください。

更新後の確認方法

実行中の全インスタンスでStarlette 1.0.1以降を確認する。
lockfile、SBOM、コンテナイメージ、デプロイ記録の版が一致していることを確認する。
一般利用者、管理者、異なるテナントなど、権限別の正常系・拒否系テストを行う。
アプリが信頼するHost系・Forwarded系ヘッダーと、プロキシが付与・削除する設定を照合する。
更新前後のログを比較し、認可失敗や通常と異なるアクセスが増えていないか確認する。
ロールバック先が脆弱な旧イメージへ戻らないよう、配布設定と保管ルールを更新する。
監視期間、担当者、クローズ条件、残リスクを対応記録へ残す。

「デプロイ成功」と「全実行環境の更新完了」は同じではありません。オートスケール、災害対策環境、停止中ジョブ、ロールバック用成果物まで含めて確認します。

よくある誤解

「Starletteを直接追加していないので関係ない」

別のパッケージがStarletteへ依存している場合があります。宣言ファイルだけでなく、解決済み依存関係、SBOM、コンテナ、実行中環境を確認してください。

「CVSS 6.5なら緊急ではない」

CVSSは脆弱性そのものの技術的深刻度を表す材料です。KEV掲載、外部公開、認可用途、資産重要度、不審ログを組み合わせて自社の優先度を決めます。CVEとCVSSの違いとKEVとEPSSの違いも参照してください。

「プロキシやWAFがあるので更新不要」

公式アドバイザリが示す緩和は条件付きです。設定変更や別経路、信頼する転送ヘッダーによって前提が崩れる可能性があるため、プロキシ確認と修正版への更新を分けて進めます。

「1.0.1へ固定すれば今後も安全」

1.0.1はこの問題の修正版ですが、将来の修正やサポート状況まで保証するものではありません。利用中フレームワークとの互換性を確認し、保守対象のリリース系列で継続更新します。

「アラートがないので侵害されていない」

未検知と影響なしは同じではありません。ログの有無、保存期間、検知ルール、認可実装を確認し、確認できない範囲を「未確認」として残します。

目的	内部リンク
作業票を作る	CVE初動対応チェックリスト、開発ツール・OSSサプライチェーン確認
依存関係を棚卸しする	ソフトウェア資産台帳の作り方、SBOMとOSVで学ぶ依存関係確認
インシデントに切り替える	漏えい疑い初動テンプレート、ログを読む初心者向けガイド
用語を確認する	CVE、KEV、SBOM、CWE、パッチ管理
優先度を比較する	CVEとCVSSの違い、KEVとEPSSの違い
知識を定着させる	セキュリティクイズ、実践トレーニング

公式情報・参考情報

まとめ：依存関係・実装条件・更新結果を分けて確認する

CVE-2026-48710への対応は、Starletteの名前を資産台帳で検索するだけでは完了しません。直接・間接依存と実行中の版を確認し、request.urlをセキュリティ判断に使う実装、外部公開、プロキシ設定、不審ログを組み合わせて優先度を決めます。

影響版なら、互換性を確認したうえで1.0.1以降へ更新し、全インスタンスへの反映と権限別テストまで行います。確認できない項目は「影響なし」にせず「調査中」として所有者と期限を置くことが、見落としを減らす最も実務的な進め方です。