PHPのWindows版で起きることと、10月21日の版が対象の理由

CVEの記録（採番機関はGoogle）によると、Brotli 1.0.3〜1.2.0の展開処理に不備があり、細工した圧縮データを展開すると、メモリの破壊、情報の漏えい、サービス停止、場合によっては任意のコード実行につながるおそれがあります。修正版は1.0.10・1.1.1・1.2.1です。深刻度は、Googleの評価でCVSS 4.0の9.2、NVDの評価でCVSS 3.1の9.8です。[2][4]

PHP公式によると、Windows版ではcURL拡張を通じてこの展開処理に届きます。パッケージに付く部品の一覧（SBOM）では、10月21日に出た8.5.12・8.4.27・8.3.36・8.2.35のWindows版はBrotli 1.2.0を同梱し、-1の版は1.2.1です。10月21日の更新を済ませた環境も、-1の版に入れ替えるまでは対象です。[1][6][7]

Brotliそのものの仕組みと、Python・Node.jsでの確かめ方は、Brotliの脆弱性の記事で説明しています。

PHPのcURLで自動展開が有効になる場合

PHP公式は、cURLでHTTP応答の自動展開が有効なときに問題の処理に届くとし、cURLの初期設定では無効だが、アプリやHTTPクライアントのライブラリが有効にすることがあると説明しています。有効にする設定はCURLOPT_ENCODING（別名CURLOPT_ACCEPT_ENCODING）です。よく使われるライブラリの初期の動作は、ソースで見ると次のとおりです。[1][8][9][12][16]

GuzzleやWordPressを使うアプリは、何も設定していなくても自動展開が有効です。外部のAPIやWebページから受け取る応答が経路になります（ソースから見た当社の整理）。

Brotliの脆弱性の悪用の状況

米CISAは10月27日（米国時間）、この脆弱性を「Google Brotli」としてKEVに追加しました。対応期限は11月10日です。PHPのWindows版を通じた悪用の記載は、11月1日の確認時点でPHP公式の告知にもKEVにもありません。今後30日に悪用される見込みの推定（EPSS）は82.6%です（10月31日時点、CVEとしての値）。[1][3][13]

セキュリティ会社ELLIO（第三者）は、PoCが公開されていて、それを写したNode.jsを狙う攻撃の通信を観測したと報告しています。PHPのWindows版で動くPoCの記載は、確認した一次情報にはありません。当社はPoCを検証していません。[14]

攻撃を受けていないかの確認

悪用が確認された脆弱性は、更新に加えて、更新前に攻撃を受けていないかを確認します。

1. 公開していた期間のWebサーバー・アプリケーションのログで、異常終了や不審な要求がないか確認します。
2. 見覚えのないファイル（Webシェルなど）や、設定・アカウントの変更がないか確認します。
3. サーバーから見覚えのない宛先への通信がないか確認します。
4. 痕跡が見つかった場合は、ログや機器の状態を保全し、専門の窓口に相談します。

PHPの系列ごとの入れ替え先

入れ替え先は、PHP公式の告知と、配布元のWindows版の一覧から出しました（11月1日確認）。

「-1」は依存ライブラリを更新して作り直したことを示し、PHPのソースと実行時の版は変わりません。-2以降の版は出ていません。配布物の一覧は、windows.php.netからdownloads.php.net/~windows/releases/に転送されます。[1][5]

各パッケージには部品の一覧（.cdx.json）と、既知の脆弱性への対応を書いたVEX（.openvex.json）が付きます。8.5.12-1のVEXにはCVE-2026-111497の記載がないので、脆弱性スキャナーの結果は、部品の一覧のBrotliの版と照らし合わせます。8.1はPHPのサポート対象（8.2〜8.5）に入っておらず、8.1.34には部品の一覧もありません。[5][6][11][15]

Windows版PHPの同梱Brotliを確かめて、-1の版に入れ替える手順

1. 使っているPHPの場所を確かめます。コマンドラインとWebサーバー（IISのFastCGI、Apacheなど）で別のPHPを使っていることがあるので、Webサーバーの設定に書かれたPHPの場所とも照らし合わせます。

   コマンドプロンプト

   where php

2. 系列と、スレッドセーフ版（TS）か非スレッドセーフ版（NTS）か、x64かx86かを確かめます。入れ替えるzipを選ぶときに使います。

   コマンドプロンプト

   php -v
   php -i | findstr /c:"Thread Safety" /c:"Architecture"

3. cURL拡張が使う同梱Brotliの版を表示します。1.2.1でなければ入れ替えの対象です。

   コマンドプロンプト

   php -r "echo curl_version()['brotli_version'] ?? 'none';"

4. アプリとComposerで入れたライブラリ（vendorフォルダ）で、自動展開を有効にする設定と、Guzzleが入っているかを確かめます。vendor\guzzlehttpに当たるのはGuzzle自身の処理で、Guzzleを使っていれば初期設定で有効です。

   コマンドプロンプト

   findstr /s /i /m "CURLOPT_ENCODING CURLOPT_ACCEPT_ENCODING decode_content" *.php
   composer show guzzlehttp/guzzle

5. 配布元の一覧から、同じ系列・同じ種類（TS／NTS、x64／x86）の-1の版を入手し、SHA-256の値を一覧のsha256sum.txtと照らし合わせます。

   PowerShell

   Get-FileHash .\php-8.5.12-1-nts-Win32-vs17-x64.zip -Algorithm SHA256

6. php.iniを残してPHPのフォルダを入れ替え、Webサーバーを再起動します（IISの例）。そのあと、Webサーバーが使うPHPでもう一度brotli_versionが1.2.1になったことを確かめます。

   コマンドプロンプト（管理者）

   iisreset
   php -r "echo curl_version()['brotli_version'] ?? 'none';"

すぐに入れ替えられないとき

PHP公式の告知に回避策の記載はありません。条件から見ると、cURLの自動展開を使わなければ経路から外れます。Guzzleでは'decode_content' => falseを指定し、自分のコードではCURLOPT_ENCODINGを設定しないようにします。これは当社の整理で、提供元が示した回避策ではありません。[1][8]

自動展開を止めると、圧縮された応答がそのまま渡り、アプリが読めなくなる場合があります。外部のAPIとの連携を検証環境で確かめてから切り替えます。

10月21日のPHP本体の修正とは別に入れ替える

PHP公式は10月21日、PHP本体の脆弱性2件（CVE-2026-109618・CVE-2026-109619、報道ではPHP2Shellとも呼ばれます）を直した8.5.12などを公開しました。この2件は10月26日からKEVに載っています。今回の-1の版は、同梱のBrotliを入れ替えたもので、原因も確かめる所も別です。[3][10]

-1の版は8.5.12などと同じソースから作られているので、10月21日より前の版に留まっている環境も、-1の版に入れ替えれば両方の修正が入ります。[1]

PHPの脆弱性情報まとめで、PHP2Shell・追加の設定問題・Brotliの対応を比較することもできます。

TwistedのHTTP/2サーバーで起きること

公式アドバイザリによると、相手がEND_STREAM付きの要求を送った直後にそのストリーム（1つの接続の中の個々の通信）を中止すると、Twistedは中止を処理する前に要求の振り分けと応答の作成を済ませてしまいます。中止されたストリームは同時に扱える数（100）の枠から外れ、中止の頻度を抑える仕組みも無かったため、1つの接続で同じことを繰り返すだけで、わずかな通信量でCPUの1コアを使い切らせることができます。[1]

影響はサービス停止（DoS）で、情報の漏えいや改ざん、コードの実行は無いとされています。深刻度は、Twistedの評価でCVSS 3.1の7.5（重要）です。2019年に直したHTTP/2の大量送信の問題（GHSA-32gv-6cf3-wcmq）の修正は、この経路を防いでいません。[1]

TwistedでHTTP/2が有効になる条件

アドバイザリの対象はtwisted.webのHTTP/2サーバーです。ソースを見ると、HTTP/2の処理は追加の部品h2とpriority（twisted[http2]で入る）が読み込めたときだけ有効になり（H2_ENABLED）、そのときだけTLSの合意の候補にHTTP/2を出します。HTTP/2に切り替わるのは、TLSの接続でHTTP/2が合意されたときだけで、それ以外はHTTP/1.1で処理します。[1][5][6][8]

3行目は、ソースから見た当社の整理です。DjangoのASGIサーバーDaphneは、Twisted[tls,http2]を入れてssl:で起動するとHTTP/2を扱い、起動時に「HTTP/2 support enabled」と記録します。[9]

TwistedのHTTP/2の脆弱性の悪用の状況

米CISAのKEVには、この攻撃の型であるHTTP/2の仕様の番号CVE-2023-44487が、2023年10月10日から載っています。2023年に実際の攻撃で使われた型です。Twistedのこの不具合そのものが悪用されたという記載は、11月1日の確認時点でTwistedのアドバイザリにもKEVにもありません。この件はCVEの番号が付いていないため、今後30日に悪用される見込みの推定（EPSS）もありません。[1][3]

アドバイザリには、攻撃の手順が文章で書かれています（コードは載っていません）。攻撃の型はよく知られているので、HTTP/2を外部に公開しているなら早めに更新します。[1]

Twistedの対象と推奨する版

推奨する版は、Twistedのアドバイザリ（26.4.0以前が対象、26.10.0rc1で修正）と、PyPIに公開済みの版から出しました（11月1日確認）。上げる前に、リリースノートで変更点を確かめてください。[1][2][4]

26.10.0には、他に6件の脆弱性の修正も入っています。リリースノートは、26.10.0がPython 3.10に対応する最後の版だとしています。Python 3.9で使える修正済みの版は無いので、3.9の環境ではPythonから上げます。[2][4][10]

TwistedのHTTP/2が有効かを確かめて、26.10.0へ上げる手順

1. 動いているPython環境で、Twistedとh2・priorityの版を確かめます。「Required-by」に、Twistedを必要としているパッケージ（Daphneなど）が出ます。

   ターミナル

   python -m pip show twisted h2 priority

2. TwistedのHTTP/2の処理が有効かを確かめます。Trueなら、TLSで待ち受けるサーバーはHTTP/2を受け付けます。

   ターミナル

   python -c "from twisted.web.http import H2_ENABLED; print(H2_ENABLED)"

3. 外から見て、そのサーバーがHTTP/2で応答するかを確かめます。「2」と出ればHTTP/2です。前段の機器があるときは、Twistedが直接応答しているかを構成と照らし合わせます。

   ターミナル

   curl -s --http2 -o /dev/null -w "%{http_version}\n" https://<ホスト>:<ポート>/

4. Pythonの版を確かめ、3.10以上なら26.10.0以上に上げます。ロックファイルに古い版が固定されていないかも確かめ、使っている場合はロックファイルも更新します。

   ターミナル

   python --version
   python -m pip install --upgrade "twisted>=26.10.0"
   grep -i -n "twisted" requirements*.txt poetry.lock uv.lock

5. サーバーを再起動し、動いている環境（コンテナなど）の中でもう一度版を確かめます。

   ターミナル

   docker exec <コンテナ名> python -m pip show twisted

すぐに26.10.0へ上げられないとき

公式のアドバイザリに回避策の記載はありません。条件から見ると、HTTP/2を使わない環境は影響の経路から外れます。h2が読み込めなければTwistedはHTTP/2を候補に出さず、HTTP/1.1だけで処理します。Daphneならhttp2の追加の部品を入れない形に戻します。これらはソースから見た当社の整理で、提供元が示した回避策ではありません。[5][6]

h2は他のパッケージ（HTTP/2を使うクライアントなど）が必要としていることもあるので、外す前にpip show h2の「Required-by」を確かめます。

Twisted 26.10.0の修正の効き方

26.10.0では、相手がストリームを中止する頻度に上限が付きました。ソースでは、中止は一度に1,000回まで、その後は毎秒33回ずつ回復し、使い切った接続はENHANCE_YOUR_CALMの理由を付けて切断します。設定を変えなくても初期設定で効きます。上限の値は名前が_で始まる内部の値で、設定項目としては公開されていません。[2][7]

CVE-2023-44487の番号と、この件の関係

Twistedのアドバイザリと、GitHub Advisory Database（日本時間10月30日に収録）のCVE欄は空欄です。一方で26.10.0のリリースノートは、この件を「CVE-2023-44487 (GHSA-vpp8-g58w-m8mp)」として載せています。CVE-2023-44487は2023年に多くの製品で同時に公表されたHTTP/2の仕様の番号です。[1][2][10]

このため、CVEの番号で照らし合わせる脆弱性スキャナーでは、2023年の他の製品の件と混ざったり、番号の無い件として出たりします。Twistedについては、GHSAの番号とTwistedの版で判断します（当社の整理）。

脆弱性の公表・更新一覧で、Pythonの関連情報を調べることもできます。

EchoのProxyミドルウェアで起きることと仕組み

EchoのProxyミドルウェアは、利用者がWebSocketへの切り替え（アップグレード）を求めると、上流のサーバーが受け入れたかを確かめる前に、接続をそのまま中継する方式（生のトンネル）に切り替えていました。上流が通常のHTTP応答を返して接続を保ったままにすると、その接続で続けて送られるHTTPリクエストは、Echoのルーターやルートごとのミドルウェアを通らずに、同じ上流へ直接届きます。[1]

このため、Echoのルートだけで行っている認証・認可を回避されるおそれがあります。Echoは、任意のホストへ中継できるわけではなく、上流自身の認証を回避するものでもないと説明しています。修正版では、アップグレードをGoの標準のリバースプロキシで扱い、上流が正しく受け入れたときだけ中継に切り替えます。断られたアップグレードは通常のHTTPリクエストのままです。[1]

Echoの脆弱性の影響を受ける条件

Echoのアドバイザリは、悪用には次の3つがそろう必要があるとしています。Proxyミドルウェアを使っていないアプリは、この脆弱性の対象になりません。[1]

• 外部から届くルートに、Proxyミドルウェア（middleware.Proxy・middleware.ProxyWithConfig）を置いている
• 上流のサーバーが、アップグレードを断っても接続を閉じない
• 狙われる上流のリソースが独自の認可を持たず、Echoのルートでの確認に頼っている

影響を受ける版について、Echoはv4・v5の全系列で生のトンネルの実装があったとし、v4.15.0・v4.16.0・v5.0.0・v5.4.0で再現を確かめ、v4.0.0のソースにも同じ確認の抜けがあると書いています。[1]

Echoの脆弱性の悪用の状況

11月1日に確かめた時点で、米CISAの悪用が確認された脆弱性の一覧（KEV、10月30日版）には載っていません。CVEの記録に米CISAが付けた評価（SSVC、10月30日）も、悪用は「なし」です。[3][4]

Echoのアドバイザリには再現を確かめた版の記載がありますが、攻撃のコード（PoC）は載っておらず、公開されたPoCも確認できませんでした。今後30日に悪用される見込みの推定（EPSS）は0.43%です（10月31日時点）。深刻度は、EchoとCVEの採番機関のGitHubの評価でCVSS 4.0の9.1（緊急）です。NVDは11月1日時点で分析中で、独自の値を付けていません。[1][5][6]

Echoの対象の版と推奨する版

今回の脆弱性は4.16.1と5.4.1で直ります（どちらも10月23日公開）。ただ、4.16.1の時点ではv4に、クライアントが送ったIPのヘッダーを信頼してしまう2件（CVE-2026-118651、CVE-2026-118653）が残っていました。この2件はEchoのv4.16.3のリリースノートで修正済みとされています（GitHub Advisory Databaseの修正版の欄は、11月1日時点で空欄です）。v5は5.4.3で別の問題（GHSA-v97q-3xf5-rj74）が直り、5.4.4でProxyのX-Real-IPの扱いがさらに直されています。[2][7][8][9]

推奨する版は、Echoのアドバイザリ・リリースノートと、Goのモジュールのプロキシ（proxy.golang.org）で公開済みの版から出しました（11月1日確認）。更新の前に、Echoのリリースノートで変更点を確かめてください。[2][7][10]

Echoの版を確かめて上げる手順

1. 間接的な依存も含めて、v4・v5のどちらが何の版で入っているかを確認します。

   ターミナル

   go list -m all | grep labstack/echo

2. Proxyミドルウェアを使っている箇所を探します。見つからなければ、この脆弱性の対象ではありません（他の修正のために上げることは勧めます）。

   ターミナル

   grep -rn 'middleware.Proxy' --include='*.go' .

3. v4を4.16.3に上げる場合は、Goの版が1.26以上かを確かめます。プロキシの裏で動かしているなら、先にIPExtractorを設定します。

   ターミナル

   go version
   grep -rn 'IPExtractor' --include='*.go' .

4. 推奨する版へ上げ、go.mod・go.sumを整えます（使っている系列の行を実行します）。

   ターミナル

   go get github.com/labstack/echo/v4@v4.16.3
   go get github.com/labstack/echo/v5@v5.4.4
   go mod tidy

5. テストを通したあと、組み上がったバイナリに記録された版を確かめます。コンテナイメージの中のバイナリでも同じ確認をします。

   ターミナル

   go list -m github.com/labstack/echo/v4 github.com/labstack/echo/v5
   go version -m ./app | grep labstack/echo

すぐ上げられないときの回避策

Echoのアドバイザリが挙げる回避策は次の2つです。[1]

• 影響するProxyのルートに届く前に、WebSocketのアップグレード要求を拒否する
• 上流の各リソースで、Echoとは別に認可を行う

上流から101以外の応答を返すようにするだけでは、問題の中継は防げないと書かれています。WebSocketを使っていないProxyのルートなら、前段のロードバランサーやEchoの手前のミドルウェアでUpgradeヘッダー付きの要求を断る形が、1つめの回避策に当たります。[1]

4.16.3に上げる前のIPExtractorの設定

4.16.3では、Echo#IPExtractorを設定していない場合、Context.RealIP()がX-Forwarded-For・X-Real-IPを使わず、接続元のアドレスを返すように変わりました。Proxyミドルウェアが上流へ送るX-Real-IPも、この値で置き換えます。[7][10]

ロードバランサーなどの裏で動かしているアプリは、設定しないまま上げると、利用者全員がプロキシのアドレスに見えます。回数制限、IPによるアクセス制限、ログに影響するため、Echoは上げる前に、自社のプロキシだけを信頼するIPExtractor（ExtractIPFromXFFHeaderかExtractIPFromRealIPHeaderにTrustIPRangeを指定）を設定するよう求めています。プロキシを置かない場合はExtractIPDirect()を使います。v5は5.4.4でもこの移行は要りません。[7][9][10]

govulncheckで出ない間の確かめ方

Goの脆弱性データベース（vuln.go.dev）には、11月1日時点でEchoのv4が3件（GO-2021-0051・GO-2022-1031・GO-2026-6293）、v5が2件（GO-2026-4502・GO-2026-6293）しか載っておらず、今回のCVE-2026-118264や同じ時期のEchoのアドバイザリは収録されていません。govulncheckやそれを使うCIの検査で何も出なくても、対象外とは判断できません。[11]

当面は、go list -mや、組み上がったバイナリに記録されたモジュールの版で、v4・v5の版を直接確かめます。Echo v4は、最新版に対して不具合の修正を2026年12月31日まで、セキュリティの修正を2027年12月31日まで行うとしています。新しく作るものにはv5を勧めています。[10]

脆弱性の公表・更新一覧で、Goの関連情報を調べることもできます。

Brotliの脆弱性CVE-2026-111497で起きることと深刻度

CVEの記録（採番機関はGoogle）によると、展開処理（c/dec/decode.c）の不備で、認証のない遠隔の攻撃者が細工した圧縮データを送ると、展開の状態を持つメモリの破壊、メモリ内容の漏えい、サービス停止、場合によっては任意のコード実行につながるおそれがあります。対象は1.0.3〜1.2.0で、修正版は1.0.10・1.1.1・1.2.1です。Googleは日本時間の10月22日早朝にこの3つを公開しました。[1][4]

深刻度は、Googleの評価でCVSS 4.0の9.2、NVDの評価でCVSS 3.1の9.8です。米CISAは10月27日（米国時間）、この脆弱性を「Google Brotli」としてKEVに追加しました。[1][2][3]

Brotliの脆弱性の影響を受ける条件

問題が起きるのは圧縮データを展開するときで、圧縮するだけの使い方は対象の記載がありません。[1][2][5][8][13]

直接入れた覚えがなくても、他のパッケージの依存で入っていることがあります。たとえばurllib3は、brotliかbrotlicffiが入っていると、Brotliで圧縮された応答を展開します。requestsなどurllib3を使うライブラリも同じ経路を通ります。[11]

外部のデータを展開する経路は、アプリが直接呼ぶ場合に限りません。Node.js組み込みのfetch()はBrotliで圧縮された応答をnode:zlibで展開し、Express 5が使うbody-parser 2は、Brotliで圧縮された要求の本文を初期設定で展開します。[12][17]

悪用の状況

米国のCISAは2026年10月27日、CVE-2026-111497を「悪用が確認された脆弱性の一覧（KEV）」に追加しました。実際の攻撃で使われていることを示すため、優先して対応します。

CVEの記録に参考として載るセキュリティ会社ELLIOによると、PoCは公開されていて、ELLIOはそれを写した攻撃の通信を10月26日（協定世界時）に観測しました。当社はPoCを検証していません。今後30日に悪用される見込みの推定（EPSS）は82.6%です（10月31日時点）。[15][16]

攻撃を受けていないかの確認

悪用が確認された脆弱性は、更新に加えて、更新前に攻撃を受けていないかを確認します。

1. 公開していた期間のWebサーバー・アプリケーションのログで、異常終了や不審な要求がないか確認します。
2. 見覚えのないファイル（Webシェルなど）や、設定・アカウントの変更がないか確認します。
3. サーバーから見覚えのない宛先への通信がないか確認します。
4. 痕跡が見つかった場合は、ログや機器の状態を保全し、専門の窓口に相談します。

Brotliの対象の版と推奨する版

言語ごとに、Brotliがどの形で入っているかと、修正版が次のとおり違います。[1][2][5][8][13]

PythonとNode.jsでBrotliを確認・更新する手順

1. Pythonで、brotliとbrotlicffiの版を確かめます。表示の「Required-by」に、そのパッケージを必要としている別のパッケージが出ます。

   ターミナル

   python -m pip show brotli brotlicffi

2. ロックファイルに古い版が固定されていないかも確かめます。

   ターミナル

   grep -i -n "brotli" requirements*.txt poetry.lock uv.lock

3. brotliは1.2.1以上、brotlicffiは1.2.1.0以上に上げます。ロックファイルを使っている場合は、ロックファイルも更新します。

   ターミナル

   python -m pip install --upgrade "brotli>=1.2.1" "brotlicffi>=1.2.1.0"

4. Node.jsは本体の版を確かめます。22系は22.23.4、24系は24.22.1、26系は26.12.1以上なら修正済みです。process.versions.brotliの表示では判断しません。

   ターミナル

   node -v

5. OSのパッケージでBrotliを入れている場合（Debian・Ubuntuの例）は、パッケージの版を配布元の告知と照らし合わせます。

   ターミナル

   dpkg -l 'libbrotli*' 'python3-brotli*'

6. 更新後は、アプリやコンテナのイメージを作り直して再起動し、動いている環境の中でもう一度版を確かめます。

   ターミナル

   docker exec <コンテナ名> node -v
   docker exec <コンテナ名> python -m pip show brotli brotlicffi

すぐ上げられないとき

回避策を示しているのは、確認した一次情報では.NETだけです。Microsoftは、ASP.NET CoreとHttpClientは初期設定ではBrotliを自動で展開しないと説明し、更新まで信頼できないBrotliデータを展開しないこと、使っている場合は展開の設定からbrを外すことを示しています。[13]

Python・Node.js・Googleの告知には回避策がありません。条件から見ると、外部から受け取ったBrotliデータを展開しなければ影響の経路から外れます。body-parserには圧縮された本文を拒否するinflate: falseの設定がありますが、これは当社の整理で、提供元がこの脆弱性の回避策として示したものではありません。[12]

Pythonのbrotli・brotlicffiの確かめ方と修正版

GitHub Advisoryは、PyPIのbrotli（1.0.3以上1.2.1未満）とbrotlicffi（1.0.3以上1.2.1.0未満）を対象としています。PyPIのbrotliには1.1.1や1.0.10が無く、修正版は1.2.1だけです。1.2.1は10月22日（日本時間）にPyPIへ公開されました。[8][9]

brotlicffi 1.2.1.0では、圧縮データの後ろに余分なバイトがあると例外を出すように変わりました。これまで通っていた入力が失敗する場合があるので、更新後に動作を確かめます。[10]

OSのパッケージ（Debianのpython3-brotliなど）で入れた場合は、OSのBrotliが更新対象です。DebianはBrotliの修正を元の番号のまま取り込み、bookwormでは1.0.9-2+deb12u1、trixieでは1.1.0-2+deb13u1が修正済みです。番号の頭だけで判断せず、配布元の告知の版と照らし合わせます。[14]

Node.jsは本体の版で判断する

Node.jsは10月21日（日本時間）に22.23.4・24.22.1・26.12.1を公開しました。公式の告知は、node:zlibで外部のBrotliデータを展開するアプリで、異常終了、メモリの漏えい、遠隔からのコード実行につながるおそれがあるとしています。重要度はNode.jsの評価で「High」です。[5]

Node.jsはGoogleの修正だけを取り込んでいて、同梱のBrotliの番号は変えていません。修正版でもprocess.versions.brotliは22系で1.1.0、24系・26系で1.2.0と表示されます。判断にはNode.js本体の版を使います。[6][7]

20系などサポートが終わった系列について、告知は「サポートが終わった版は常に影響を受ける」としていて、修正版はありません。22・24・26のいずれかへ移ります。公式の告知に回避策の記載はありません。[5]

脆弱性の公表・更新一覧で、Pythonの関連情報を調べることもできます。

Crassの脆弱性で起きることと仕組み

CSSの中の不正なURLは、ブラウザが従う仕様（CSS Syntax Level 3）では、次の「)」で終わります。Crassは、エスケープしたバックスラッシュ（\\）の後の「)」を終わりと認めず、その先の「)」か入力の終わりまでを不正なURLの一部として読んでいました。[1]

ブラウザにとっては有効なCSSの部分を、Crassは不正なURLの中身として扱うため、CSSを検査して出力し直すサニタイザーがその部分を素通りさせます。Crassの作者は、サニタイザーが削除するはずの宣言、スタイルのルール、@importなどを通されるおそれがあり、画面に偽の要素を重ねる攻撃（クリックジャッキングやフィッシング）、外部の資源の読み込み、CSSを使った情報の持ち出しに使われうると説明しています。最近のブラウザでスクリプトが実行されることはないとしています。[1]

Crassの脆弱性の影響を受ける条件

Crassの作者は、Crass単体では読み取りを誤るだけで、影響はCrassで判断してCSSを出力し直すサニタイザーに出るとしています。Chromiumで確かめた例として、次の使い方を挙げています。[1]

• Sanitize 7.0.0以下：Sanitize::CSS.propertiesとstyle属性、Sanitize::CSS.stylesheetと<style>要素
• Loofah：Loofah::HTML5::Scrub.scrub_css（style属性の無害化）
• rails-html-sanitizer：sanitize_cssと、styleを許可したsanitize

悪用には、サニタイザーが不正なURLを含むCSSを拒否していないことが必要です。Railsのsanitizeの初期設定で許可される属性にはstyleが入っていないため、attributes:やallowed_attributesでstyleを足しているかが、Railsアプリで見る点になります。[1][7]

Crassの脆弱性の悪用の状況

11月1日に確かめた時点で、米CISAの悪用が確認された脆弱性の一覧（KEV、10月30日版）には載っていません。[2]

Crassの作者のアドバイザリは、問題を起こす文字の並び（\\の後の「)」）と、Chromiumで確かめたサニタイザーの例を書いていますが、攻撃のコード（PoC）は載っていません。公開されたPoCも確認できませんでした。今後30日に悪用される見込みの推定（EPSS）は0.35%です（10月31日時点）。深刻度は、Crassの作者とCVEの採番機関のGitHubの評価でCVSS 4.0の5.3（警告）です。NVDは評価を保留（Deferred）にしています。[1][3][4]

Crassの対象の版と推奨する版

Crassは1系だけで、1.0.7以下のすべての版が対象です。1.0.8（10月22日公開）で直っています。Crassでは、6月26日公開の1.0.7で直ったサービス停止の4件（CVE-2026-61845〜61848）も公表されていて、1.0.8に上げれば合わせて直ります。[1][5][6]

推奨する版は、Crass・Sanitizeのアドバイザリと、RubyGems.orgで公開済みの版から出しました（11月1日確認）。更新の前に、各gemのリリースノートで変更点を確かめてください。[1][5][8]

Crassの版を確かめて上げる手順

1. Crassの版と、どのgemを通じて入っているかを確認します。

   ターミナル

   bundle info crass
   grep -n 'crass' Gemfile.lock

2. CSSを無害化している箇所を探します。style属性を許可したsanitizeや、sanitize_css・Sanitize::CSSがあるかを見ます。

   ターミナル

   grep -rnE 'sanitize_css|scrub_css|Sanitize::CSS|allowed_attributes|attributes:.*style' app lib config

3. Crassだけを上げます。Sanitizeを使っている場合は、Sanitizeも一緒に上げます（使っている行を実行します）。

   ターミナル

   bundle update --conservative crass
   bundle update --conservative sanitize crass

4. Gemfile.lockと、実際に読み込まれる版を確かめます。

   ターミナル

   bundle info crass
   bundle exec ruby -e 'require "crass"; puts Crass::VERSION'

5. bundler-auditを使っている場合は、データベースを更新してから検査します。

   ターミナル

   bundle exec bundle-audit check --update

すぐ上げられないときの回避策

Crassの作者は、更新以外に実用的な回避策はないとしています。そのうえで、次の方法は既知のきっかけを防げますが、正当なCSSまで拒否するおそれがあると書いています。[1]

• \\（エスケープしたバックスラッシュ）を含むCSSの入力を拒否する

Railsに入る経路と、Loofahを上げても残る理由

Railsのビューのsanitizeはrails-html-sanitizerを使い、rails-html-sanitizerはLoofahを、LoofahはCrassを使います。そのため、多くのRailsアプリのGemfile.lockにはCrassが入っています。[7][8]

Loofahは11月1日時点の最新版2.25.2でも、Crassに「1.0.2以上・1.1未満」を求めるだけで、1.0.7以下も許します。rails-html-sanitizerの最新版1.7.1が求めるのもLoofah 2.25.2以上で、Crassの版には触れていません。bundle update railsやbundle update loofahだけでは、Crassが1.0.7以下のまま残ることがあります。Sanitizeを使っている場合は、7.0.1がCrass 1.0.8以上を必須にしているので、Sanitizeを上げればCrassも上がります。[8]

Sanitizeは7.0.1で別の迂回も直っている

Sanitizeの作者は、Crass 1.0.8と同じ10月22日に、Sanitize 7.0.1を公開しました。7.0.1は、CSSの入れ子（CSS nesting）を使って許可していないプロパティやURLを通される別の問題（GHSA-wgw9-qhqg-8hv5、Sanitizeの評価でCVSS 4.0の5.3）を直しています。この問題はCrassを上げても直らないため、Sanitizeを使っている場合はSanitize自体も7.0.1に上げます。11月1日時点で、この件はSanitizeのリポジトリでだけ公表され、CVEは付いていません。[5]

脆弱性の公表・更新一覧で、Rubyの関連情報を調べることもできます。

Vite 6.4.4の脆弱性で起きること

Viteの開発サーバーは、server.fs.denyに一致するファイルを返さないようにしています。公式アドバイザリによると、6.4.4では要求に?raw、?import&raw、?import&url&inlineなどのクエリを付けると、この設定で拒否した.envや*.crtなどが正常な応答（HTTP 200）で返ります。[1]

.envには鍵やパスワードを置くことが多く、条件がそろうと認証なしで中身を読まれるおそれがあります。深刻度は、Viteの評価（CVEの採番機関のGitHubも同じ値）でCVSS 4.0の6.9（警告）です。NVDは独自の評価をまだ付けていません。GitHub Advisory Databaseへの収録は10月30日（日本時間）で、提供元の公表より後です。[1][3][12]

Viteの開発サーバーが対象になる条件

公式アドバイザリは、次の3つの条件がすべてそろうアプリだけが影響を受けるとしています。表の初期値は、Vite公式の設定文書の記載です。[1][2]

初期値のままなら、プロジェクトのルートにある.envは2つ目と3つ目の条件に当てはまります。分かれ目は1つ目の公開の有無です（公式文書の初期値から見た当社の整理）。コンテナの中の開発サーバーに外から接続する構成では、--hostを付けて公開していることがあります。アドバイザリの条件は開発サーバーについてのもので、vite previewやビルドした成果物の記載はありません。[1][2]

Viteのこの脆弱性の悪用の状況

米CISAの「悪用が確認された脆弱性の一覧（KEV）」には、11月1日の確認時点（10月30日版）で載っていません。今後30日に悪用される見込みの推定（EPSS）は0.3%です（10月31日時点）。[7][13]

アドバイザリには問題を起こすクエリが書かれていて、再現に必要な情報は公開されています。開発サーバーを公開した場合に?raw?importなどで拒否を回避できた、よく似たViteの過去の脆弱性CVE-2025-31125は、2026年1月22日からKEVに載っています。[1][7]

Viteの系列ごとの対象と推奨する版

推奨する版は、Viteの公式アドバイザリと、npmに公開済みの版から出しました（11月1日確認）。上げる前に、Viteの変更履歴で変更点を確かめてください。[1][5][6]

Viteの方針では、6系は「2つ前のメジャー版」にあたり、最新のマイナー版（6.4）だけがセキュリティの修正を受けます。6.4.5の後に6系の新しい版は出ていません（11月1日確認）。[6][11]

Viteの版と公開の有無を確かめて、6.4.5へ上げる手順

1. 使っているViteの版を、間接の依存まで含めて確かめます。pnpmはpnpm why vite、Yarnはyarn why viteで同じことを確かめられます。6.4.4が1か所でも出れば対象です。

   ターミナル

   npm ls vite --all

2. 開発サーバーをネットワークに公開していないかを、起動スクリプトと設定ファイルで確かめます。

   ターミナル

   grep -n -- "--host" package.json
   grep -n "host" vite.config.*

3. Viteを直接入れている場合は、6.4.5以上に上げます。

   ターミナル

   npm install -D vite@^6.4.5

4. Astroなど上位のツールの依存で6.4.4が入っている場合は、package.jsonのoverridesで版を指定し、npm installし直します。Viteを直接の依存にも書いている場合は、値を"$vite"にします。[15]pnpmはpnpm.overrides、Yarnはresolutionsに同じ指定を書きます。

   package.json

   "overrides": {
     "vite": "^6.4.5"
   }

5. 開発サーバーを起動し直し、動いているViteの版を確かめます。

   ターミナル

   npx vite --version
   npm ls vite --all

6. 自分の開発サーバーで、拒否したファイルが返らないことを確かめます。プロジェクトのルートに.envがある状態で、応答が200以外（拒否）になれば直っています。

   ターミナル

   curl -s -o /dev/null -w "%{http_code}\n" "http://localhost:5173/.env?raw"

すぐに6.4.5へ上げられないとき

公式のアドバイザリに回避策の記載はありません。条件から見ると、開発サーバーをネットワークに公開しない（--hostやserver.hostを外し、localhostだけで待ち受ける）環境は影響の条件から外れます。これは当社の整理で、提供元が示した回避策ではありません。[1][2]

公開していた期間に.envへ置いていた鍵は、読まれた可能性を前提に替えるかを判断します（当社の整理）。また、publicディレクトリのファイルは拒否の設定にかかわらずそのまま配信されるので、機密のファイルを置いていないかも確かめます。[4]

10月6日の更新で6.4.4にした環境が対象になった理由

Viteは10月6日、開発サーバーの別の脆弱性（GHSA-rq7h-c2jc-7f22、GHSA-9jrq-w75r-8gcw）を公表し、6系の修正版として6.4.4を出しました。公式の説明では、6.4.4はその修正のために変更（#20410）を取り込みましたが、組み合わせて必要な変更（#22160）を取り込みませんでした。このため、4月に7系・8系で直った同じ種類の問題（GHSA-v2wj-q39q-566r）が、6系で起きるようになりました。[1][8][9][14]

10月6日の告知に応じて6.4.4へ上げた環境ほど対象になり、6.4.3以前に留まった環境はこの件の対象外です。ただし6.4.3以前は10月6日の2件の対象なので、戻すのではなく6.4.5へ進みます。6.4.4が6系の最新だったのは、npmに出た日本時間の10月6日14時49分から、6.4.5が出た21日14時35分までです。この間にnpm installやロックファイルの作り直しで6系の範囲を解決した環境に入りえます。[6]

Astro 5などが引き込む6系のVite

Viteを直接入れていなくても、上位のツールの依存で入ります。たとえばAstro 5系の最終版5.18.2は、Viteを^6.4.1の範囲で求めます。Astroの版は変えていなくても、ロックファイルを作った時期によってViteは6.4.4になります。判断には、上位のツールの版ではなく、npm ls viteに出るViteの版を使います。[10]

脆弱性の公表・更新一覧で、JavaScript / TypeScriptの関連情報を調べることもできます。

Tomcatの脆弱性8件で起きることと深刻度

ASFのセキュリティ告知は、8件のうち3件を「Important」、5件を「Low」としています。ASFはCVSSを付けていません。CVEの記録では、米CISAが補足としてCVSSを付けていて、Importantの3件はいずれも9.1です（CVE-2026-101296はCVSS 4.0、他の2件はCVSS 3.1）。[1][2][3][4][5]

どの件も、該当するかは使っている機能で決まります。件ごとの内容と、該当する使い方は次のとおりです。範囲は告知の記載で、系列によって対象外のものがあります。[1][2][3]

TomcatでHTTP/2・JNDIRealm・AJPを使っているかの確かめ方

単体のTomcatでは、HTTP/2はコネクタの中にHttp2Protocolを書いたときに有効になります。配布物のserver.xmlでは、HTTP/2を使う例とAJPのコネクタはどちらもコメントになっています。[6][7]

Spring Bootの組み込みTomcatでは、HTTP/2はserver.http2.enabledで有効にし、初期値は無効です。[8]

CVE-2026-101356は版の範囲が新しく、たとえば9.0系では9.0.118〜9.0.122だけが対象です。古い版はこの件の対象外でも、JNDIRealmの件（CVE-2026-101296）は全系列が対象です。この件はauthentication属性にGSSAPI以外のSASLの方式を指定している場合が該当します。[1][9]

悪用の状況

2026年11月1日時点で、米国のCISAが公開している「悪用が確認された脆弱性の一覧（KEV）」には載っていません。

PoCの公開は、ASFの告知とCVEの記録では確認できていません。CVEの記録のCISAの評価（SSVC）では、8件とも悪用は「none」です。

Tomcatの系列ごとの修正版とサポート終了の版

修正版は10月12日にASFから公開され、Maven Centralにも置かれています。脆弱性の公表（10月20日）より前に出ているので、すでに11.0.27・10.1.61・9.0.123以降に上げていれば、8件の修正は入っています。必要なJavaの版は系列ごとに決まっていて、同じ系列の中の更新では変わりません。[10][11]

CVEの記録は、サポートが終わった8.5系・7.0系も、JNDIRealmの件とJSTLの件の対象だとしています。修正版は出ないので、サポート中の系列へ移ります。[4]

Tomcatの版と設定を確認・更新する手順

1. 単体のTomcatは、版を表示して系列と番号を確かめます（Windowsではversion.bat）。

   ターミナル

   $CATALINA_HOME/bin/version.sh

2. アプリに組み込んだTomcat（Spring Bootなど）は、依存関係から版を確かめます。Gradleでは./gradlew dependencyInsight --dependency tomcat-embed-coreです。

   ターミナル

   mvn dependency:tree -Dincludes=org.apache.tomcat.embed

3. server.xmlで、HTTP/2・AJP・JNDIRealm・Unixドメインソケット・FIPSモードの設定があるかを確かめます。コメントの中の行も表示されるので、有効な設定かを見分けます。

   ターミナル

   grep -n -E "Http2Protocol|AJP/1.3|JNDIRealm|unixDomainSocketPath|FIPSMode" $CATALINA_BASE/conf/server.xml

4. Spring Bootでは、HTTP/2を有効にしているかを設定ファイルで確かめます。

   ターミナル

   grep -rn "server.http2.enabled" src/main/resources/

5. Spring Bootの3.5系で、すぐに4系へ上げられない場合は、組み込みTomcatの版を指定します。指定後はテストで動作を確かめます。

   pom.xml

   <properties>
     <tomcat.version>10.1.61</tomcat.version>
   </properties>

6. 更新して再起動したあと、もう一度版を確かめます。

   ターミナル

   $CATALINA_HOME/bin/version.sh

すぐ上げられないとき

ASFの告知に、更新以外の回避策はありません。表の使い方に当てはまらなければその件の経路から外れますが、これは当社の整理で、ASFが示した回避策ではありません。JNDIRealmの件は認証に関わるので、該当する設定がある場合は更新を先にします。[5]

Spring Bootの組み込みTomcatの版

Spring Bootは、使うTomcatの版を依存関係の一覧（spring-boot-dependencies）のtomcat.versionで決めています。Maven Centralの記載では、10月22日に公開された4.0.9と4.1.2が11.0.27を使います。[12]

3.5系の最後の公開版3.5.16は10.1.55を使っていて、CVE-2026-101356とCVE-2026-101296の範囲に入ります。3.5系の無償サポートは2026年6月30日に終わっています。4系へ上げられない間は、tomcat.versionで10.1.61を指定できますが、Spring Bootの文書は、版を上書きすると互換性の問題が起きることがあると注意しています。[12][13][14]

9.0系のサポート終了と9.1系への移行

ASFは、9.0系のサポートを2027年3月31日で終えると告知しています。その後は脆弱性の報告が9.0系に照らして確かめられなくなります。最後の9.0系の公開は3月31日の少し前の予定です。[15]

同じ時期に9.1系の公開が始まり、2030年12月31日まで続きます。9.0系との違いは小さく、HTTP・HTTPS・AJPのAPR/Nativeコネクタが無くなる点です。APR/Nativeコネクタを使っている場合は、NIOのコネクタへの移行が勧められています。CVE-2026-80353はこのAPR/Nativeコネクタの件です。[3][15]

脆弱性の公表・更新一覧で、Java / JVMの関連情報を調べることもできます。

LaravelのTokenGuardで起きることと仕組み

TokenGuardは、要求に含まれるAPIトークンを取り出し、そのトークンを持つ利用者をデータベースから探す仕組みです。トークンは、URLのクエリや送信された値のapi_token、Authorization: Bearerヘッダーなどから読み取ります。[1][6]

Laravelのアドバイザリによると、MySQL・MariaDBの一部の構成で、文字列でない形に細工した値を送ると、認証の検索の処理で正しく扱われず、本来は失敗するはずの問い合わせが別の利用者の行に一致します。攻撃者は、相手のAPIトークンを知らないまま、既存の利用者として認証されるおそれがあります。そのガードで守ったルートでは、認証の回避とアカウントの乗っ取りにつながります。どの構成が対象かは、アドバイザリに記載がありません。[1]

修正は、TokenGuardが受け取ったトークンが文字列かを確かめ、文字列でなければ検索しないようにしたものです。修正のコミットのテストでは、配列の値を送る例が使われています。[5]

Laravelの脆弱性の影響を受ける条件

次の条件がそろう環境が対象です。[1]

• 標準のトークン方式のAPIガード（TokenGuard）でルートを守っている。config/auth.phpのguardsに'driver' => 'token'がある
• データベースがMySQLまたはMariaDBで、影響を受ける構成になっている（具体的な構成はアドバイザリに記載なし）
• laravel/frameworkが13.29.0未満、または12.68.0未満

Laravelの脆弱性の悪用の状況

11月1日に確かめた時点で、米CISAの悪用が確認された脆弱性の一覧（KEV、10月30日版）には載っていません。CVEの記録に米CISAが付けた評価（SSVC、10月28日）も、悪用は「なし」です。[2][3]

攻撃のコード（PoC）として公開されたものは確認できませんでした。ただし、修正のコミットのテストに、問題を起こす入力の形が載っています。今後30日に悪用される見込みの推定（EPSS）は0.78%です（10月31日時点）。深刻度は、LaravelとCVEの採番機関のGitHubの評価でCVSS 4.0の9.2（緊急）です。NVDは11月1日時点で分析待ちで、独自の値を付けていません。[4][5][7]

Laravelの対象の版と推奨する版

今回の修正版は13.29.0と12.68.0で、12.68.0は8月25日、13.29.0は8月26日（いずれも日本時間）にPackagistで公開されています。公表が修正版の公開から約2か月後だったため、すでに上げている環境もあります。同じ時期のLaravelのアドバイザリも直る版は、13系が13.30.0、12系が12.69.0です。13.30.0・12.69.0では、APP_DEBUG=trueのときのエラー画面のXSS（CVE-2026-102279、低）が直っています。[1][8][9]

推奨する版は、Laravelのリポジトリで公表されたアドバイザリと、Packagistで公開済みの版から出しました（11月1日確認）。13系はPHP 8.3以上、12系はPHP 8.2以上が必要です。更新の前に、Laravelのリリースノートで変更点を確かめてください。[1][8][10]

Laravelの版とガードを確かめて上げる手順

1. composer.lockに記録されたlaravel/frameworkの版を確認します。

   ターミナル

   composer show --locked laravel/framework

2. TokenGuard（ドライバーtoken）のガードがあるか、どのルートがそのガードを使っているかを確認します。

   ターミナル

   grep -n "'driver'" config/auth.php
   grep -rn "auth:api\|guard('api')" routes app

3. 推奨する版へ上げます。13系なら13.30.0以上、12系なら12.69.0以上になるよう、composer.jsonの指定を確かめてから実行します。

   ターミナル

   composer update laravel/framework --with-dependencies
   composer show --locked laravel/framework

4. Packagistに登録された脆弱性の情報で、他に残っているものがないかを確かめます。

   ターミナル

   composer audit --locked

5. 本番に反映したあと、実際に動いているLaravelの版を確かめます。コンテナイメージやデプロイ先でも同じ確認をします。

   ターミナル

   php artisan --version

すぐ上げられないとき

Laravelのアドバイザリには、回避策の記載がありません。対応は修正版への更新です。[1]

TokenGuardを使っていないアプリ（'driver' => 'token'のガードが無いアプリ）は、この脆弱性の条件に当てはまりません。その場合も、同じ版で直る他の脆弱性のために、上の表の版へ上げることを勧めます。

TokenGuardかSanctumかの見分け方

LaravelのAPI認証には、標準のTokenGuard（ドライバーtoken）のほかに、Sanctum（ドライバーsanctum）やPassportがあります。アドバイザリが対象として挙げるのはTokenGuardだけです。SanctumはLaravel\Sanctum\Guardという別のクラスで、personal_access_tokensの表からトークンを探します。[1][6][11]

Sanctumを使っていても、古いガードの設定がconfig/auth.phpに残っていて、一部のルートだけがそちらで守られていることがあります。auth:apiなどのミドルウェアの指定が、どのガードを指しているかを手順で確かめます。

11系以前を使っている場合

アドバイザリは影響範囲を「12.68.0未満」としており、11系以前も対象に含まれますが、11系以前の修正版は記載していません。Laravelのサポートの方針では、セキュリティの修正の提供は11系が2026年3月12日、10系が2025年2月4日に終わっています。[1][12]

なお、Laravelのリポジトリでは、11系の11.56.1（8月25日公開）と10系の10.50.4（10月27日公開）のTokenGuardに、同じ文字列の確認が入っています。これはアドバイザリが示す修正版ではなく、他の脆弱性の修正も保証されないため、12系以上へ移るまでのつなぎとして扱います。[8][13]

脆弱性の公表・更新一覧で、PHPの関連情報を調べることもできます。

zipクレートのCVE-2026-115905で起きること

ZIPファイルでは、各ファイルの名前が、本体の直前（ローカルファイルヘッダー）と末尾の目録（セントラルディレクトリ）の2か所に書かれます。提供元のアドバイザリによると、9.0.4以下のZipArchiveは目録の名前だけを使い、逐次読み込みのZipStreamReaderは本体の直前の名前だけを使って展開します。2か所の名前を食い違わせたZIPは、読む部品によって別のファイルに見えます。[1]

アドバイザリの例では、目録にdoc_report.pdf、本体の直前にcron_worker.shと書いたZIPが、目録で確かめる検査を通り、ZipStreamReaderでの展開で既存のスクリプトを上書きします。既存のファイルを書き換えられると、サービスの停止や、仕込まれたスクリプトによるコード実行につながるおそれがあります。[1]

深刻度は、提供元の評価でCVSS 4.0の10.0（緊急）です。NVDは11月1日時点で独自の評価をしておらず、提供元と同じ値を載せています。[1][3]

zipクレートの脆弱性の対象になる構成

提供元が影響を受けるとしているのは、目録を基準にする読み方を信じた処理と、本体の直前のヘッダーを基準にする読み方の処理が組み合わさる場合です。逆の組み合わせも含みます。[1]

提供元は、利用者が送ったZIPを自動で展開するサービスや、検査と展開を別の部品で行う構成を、影響を受ける例に挙げています。ZipStreamReaderはzip::unstable::streamにあるので、コードの中でこの名前を探すと見分けの手がかりになります。[1]

悪用の状況

2026年11月1日時点で、米国のCISAが公開している「悪用が確認された脆弱性の一覧（KEV）」には載っていません。

今後30日以内に悪用される確率の推定値（EPSS）は0.3%です（2026-11-01時点）。見込みは高くない部類ですが、推定値で、悪用されないことを保証するものではありません。

提供元のアドバイザリには、検査をすり抜けて既存のスクリプトを上書きするまでを再現するテストのコード（PoC）と、その実行結果が載っています。当社はPoCを検証していません。[1]

zipクレートの対象の版と推奨する版

GitHub Advisoryの記載は「9.0.4以下が対象、修正版は9.0.5」です。9.0.5は日本時間の10月18日に公開されました。8系以前に向けた修正版は、アドバイザリに記載がありません。[1][2][9]

9.0.5で止めないのは、提供元が10月27日（日本時間）に公表した別の2件が残るためです。ZipArchive::newが前の目録に戻って読み、他の道具と違う中身に見える問題（GHSA-wjr6-mhvj-cjvm、2.1.4〜9.0.5）と、厳密な検査が末尾の欠けたZIPを通してしまう問題（GHSA-gmfj-vffv-32pw、9.1.0未満）で、どちらも9.1.0で直りました。9系に必要なRustは1.88以上で、8系と同じです。[7][8][9]

zipクレートを確かめて上げ、検査を有効にする手順

1. 使っているzipの版と、どのクレートが使っているかを確かめます。複数の版が入っていると表示されたら、cargo tree -i zip@8.6.0のように版を付けます。

   ターミナル

   cargo tree -i zip

2. Cargo.lockに記録された版も確かめます。

   ターミナル

   grep -n -A1 'name = "zip"' Cargo.lock

3. コードの中で、逐次読み込みの部品を使っている箇所を探します。

   ターミナル

   grep -rn -E 'ZipStreamReader|unstable::stream' --include='*.rs' .

4. Cargo.tomlの指定を9.1.0以上が入る範囲にしてから更新します。8系以前からは大きな版の更新です。他のクレートが古い版を求めている場合は、そのクレートも更新します。

   ターミナル

   # Cargo.toml の [dependencies] を zip = "9.1" にしてから
   cargo update -p zip

5. 展開の処理で、食い違いの検査を有効にします（使っている部品の行だけを入れます）。

   Rust

   use zip::read::ExtractOptions;
   use zip::unstable::stream::ZipStreamReader;
   
   // 逐次読み込みで展開する場合
   ZipStreamReader::new(reader).enforce_header_consistency(true).extract(&dir)?;
   
   // ZipArchiveで確かめて展開する場合（extract_with_optionsは9.1.0以降）
   archive.validate_header_consistency()?;
   archive.extract_with_options(&dir, ExtractOptions::default().enforce_header_consistency(true))?;

6. テストを通したあと、もう一度版を確かめます。本番で動いている成果物（コンテナのイメージなど）も作り直します。

   ターミナル

   cargo test
   cargo tree -i zip

すぐに上げられないとき

提供元のアドバイザリに回避策の節はありません。示されている対応は、更新と、9.0.5で追加された検査を有効にすることです。[1][4]

当社の整理では、更新までの間は、確認と展開に同じ読み方を使うこと（ZipArchiveで確かめた一覧をZipArchiveから展開する）と、展開後のファイル名が確認したときの一覧と一致するかを確かめることが考えられます。これは提供元が示した回避策ではありません。

上げても既定では検査されない。有効にする書き方

9.0.5で入った修正は、本体の直前のヘッダーと目録の食い違いを見つける検査です。修正のコミットとソースには「互換性のため、ZipStreamReader::newはヘッダーの一致を確かめない」と書かれていて、11月1日時点の最新の9.2.1でも既定は無効のままです。版を上げただけでは、展開の動きは変わりません。[4][5]

検査を有効にする書き方は、使っている部品で次のように違います。[4][5][6]

食い違いが見つかると、展開はZipError::InvalidArchiveで止まります。9.2.1のvalidate_header_consistency()は、目録に同じ名前が重複している場合も誤りを返します。[5]

cargo auditやDependabotで見つからないことがある

cargo auditは、RustSecのデータベースでCargo.lockを調べます。11月1日時点で、RustSecにあるzipの記録は4件で、CVE-2026-115905は含まれていません。cargo auditで何も出なくても、対象外とは判断できません。[10]

この件はGitHub Advisory DatabaseとOSVに載っていますが、9.0.5に残る2件は提供元のリポジトリにだけ公表されていて、11月1日時点でGitHub Advisory Databaseに収録されていません。OSVで9.0.5を調べても何も出ないため、これらを使う道具では9.0.5で解決と表示されることがあります。Cargo.lockの版を、提供元のアドバイザリの一覧と照らし合わせます。[2][7][8][11]

脆弱性の公表・更新一覧で、Rustの関連情報を調べることもできます。

Pillowの脆弱性で起きることと仕組み

Pillowは、FPXファイルに含まれるJPEGのタイルを展開するとき、書き込み先のバッファを1画素あたり2バイト分で確保します。ところが、FPXが指すJPEGの色の形式をPillowが判別できないと、libjpegは1画素あたり4バイト（4成分）で書き出します。この結果、確保した2バイト分のバッファに4バイト分が書き込まれ、ヒープの範囲外への書き込みが起きます。書き込む長さ（画像の幅）と中身（画素のデータ）は、ファイルを作る側が決められます。[1]

深刻度は、CVEの採番機関であるGitHubの評価でCVSS 4.0の9.2（緊急）です。NVDも同じ値を二次評価として載せています。弱点の分類はCWE-122（ヒープベースのバッファオーバーフロー）とCWE-787（範囲外への書き込み）です。[1][3]

影響を受ける条件

次の条件がすべてそろう環境が対象です。

• Pillowが12.3.0以前である（修正版は13.0.0）。[1]
• 任意依存のolefileが入っている。PillowはFPXを読むのにolefileを使い、olefileが無い環境ではFPXの読み込み機能自体が登録されません。[1][7]
• 外部から受け取ったファイルをImage.open()で開く（アップロード画像のサムネイル作成、アバターや文書の変換など）。形式はファイルの先頭の印（OLE2）で判定され、拡張子は見ません。[1]

対象の場合、受け取ったファイルを自動で開く処理で、利用者の操作なしに、画像処理を行うプロセスの権限でメモリを壊されます。条件がそろえば任意のコマンドの実行に至りますが、より起こりやすいのはクラッシュやサービス停止です。[1]

悪用の状況

2026年11月1日時点で、米国のCISAが公開している「悪用が確認された脆弱性の一覧（KEV）」には載っていません。

今後30日以内に悪用される確率の推定値（EPSS）は0.7%です（2026-11-01時点）。見込みは高くない部類ですが、推定値で、悪用されないことを保証するものではありません。

アドバイザリには、細工したFPXファイルを作るプログラム（PoC）と再現の手順が公開されています。ただし、報告者がコマンドの実行まで示したのは、ASLR（メモリ配置の乱数化）を無効にし、インタープリターが固定アドレスで動く検証用のDocker環境です。実環境で任意のコード実行まで持ち込むには、これらの前提をそろえる必要があり、CVSS 4.0で攻撃の難しさが「高」とされているのはこのためです。[1]

対象のバージョンと推奨する版

修正版は13.0.0です。Pillowは12.3.0以前が影響を受け、12系に修正版はありません。13.0.0（13系）へのメジャーバージョンの更新が必要です。配布元（PyPI）で公開済みの版で、確認日は2026年11月1日です。更新の前に、提供元のリリースノートで変更点を確かめてください。[6][7]

13.0.0はPython 3.10に対応しません。Python 3.10は2026年10月に提供が終わったためで、3.10で動かしている場合は、先にPython 3.11以上へ上げる必要があります。[6][7]

13.0.0は、今回のFPXの問題と同時に、JPEG・TIFF・PDFなどの読み書きで見つかった約40件（緊急2件・高13件を含む）をまとめて直した版です。すぐに上げられない事情があるときは、次の節のolefileを外す対処も検討します。[7]

Pillowがどこから入っているか確かめて上げる手順

1. 使っている版と、どのパッケージが連れてきているか（Required-byの行）を確認します。依存はrequirements.txt・poetry.lock・uv.lockにも記録されています。

   ターミナル

   python -m pip show pillow

2. 任意依存のolefileが入っているかを確認します。「見つからない（Package(s) not found）」なら、FPXの経路には届きません。

   ターミナル

   python -m pip show olefile

3. olefileが入っている場合、Pillowが実際にFPXを開ける状態かを確認します。Trueなら、受け取ったファイルをImage.open()に渡す箇所が対象になりえます。

   ターミナル

   python -c "from PIL import Image; Image.init(); print('FPX' in Image.OPEN)"

4. 13.0.0はPython 3.11以上が必要です。実行中のPythonの版を確認します。

   ターミナル

   python -V

5. 13.0.0以上へ更新します。間接依存で入っている場合は制約ファイルで下限を指定し、uvやPoetryでは各ツールの行でlockを更新します。

   ターミナル

   python -m pip install --upgrade "pillow>=13.0.0"
   # 間接依存のとき
   echo "pillow>=13.0.0" >> constraints.txt && python -m pip install -r requirements.txt -c constraints.txt
   uv lock --upgrade-package pillow
   poetry update pillow

6. 読み込まれる版を確かめます。本番の成果物（コンテナイメージなど）でも更新後の版か確認し、受け取ったファイルをそのまま開いている箇所も探します。

   ターミナル

   python -c "import PIL; print(PIL.__version__)"
   grep -rn "Image.open" --include="*.py" .

すぐに更新できないときの対処

GitHub Advisoryに回避策の節はありません。次は、公表された成立条件から導ける緩和策です。[1]

• olefileを外せるか確認する。olefileが無ければFPXの読み込み機能は登録されず、この経路には届きません。FPXやMIC形式を扱っていなければ、依存から外すことを検討します。[1][7]
• Image.open()のformats引数で、受け付ける形式を実際に使うものだけに絞る（一般的な緩和策）。[1]

拡張子では防げない理由と、経路の断ち方

Pillowは、ファイルの拡張子ではなく先頭の数バイト（OLE2の印）でFPXと判定します。そのため、.jpgや.pngに見せかけたファイルでも、olefileが入っていればFPXとして展開されます。アップロードの受け口で拡張子やContent-Typeだけを確認していても、この経路は塞げません。[1]

すぐに13.0.0へ上げられない事情（Python 3.10を使っている、13系の互換性の確認が終わっていない、など）があるときは、olefileを外してFPXの読み込み自体を無効にする対処が、影響の範囲を狭めたうえで経路を断てます。FPXやMICを使っていないことを確かめてから外します。[1][7]

脆弱性の公表・更新一覧で、Pythonの関連情報を調べることもできます。

snappy-javaのCVE-2026-93451で起きること

提供元のアドバイザリによると、Snappy.uncompressCharArray・uncompressShortArray・uncompressIntArray・uncompressLongArray・uncompressFloatArray・uncompressDoubleArrayは、圧縮データに書かれた展開後の大きさ（バイト数）を要素の大きさで割って配列を用意していました。一方、ネイティブのコードはバイト数をそのまま書き込みます。展開後の大きさが要素の大きさの倍数でないと、配列の末尾を最大7バイト越えて書き込み、Javaのヒープを壊します。[1]

深刻度は、提供元の評価でCVSS 3.1の7.5（可用性への影響が高）です。CVEを採番したVulnCheckは、CVSS 4.0で6.9、CVSS 3.1で6.5と評価し、書き込む内容を攻撃者が制御できるとしています。NVDは11月1日時点で独自の評価をしていません。[1][3]

報告のissue（#729）は日本時間の9月14日に公開され、VulnCheckのCVEの記録は9月18日に公開されました。提供元のアドバイザリの公表は10月4日、GitHub Advisory Databaseへの収録は10月28日です。[1][2][3][4]

snappy-javaの脆弱性の対象になる使い方

この件の対象は、外部から受け取ったデータ、または外部の影響を受けるデータを、上の6つのメソッドで展開している場合です。Snappy.uncompress(byte[])やSnappyInputStreamなど、他の展開の方法はこの件の対象として書かれていません。[1]

ただし、同じ1.1.10.9では、Snappy.uncompress(ByteBuffer, ByteBuffer)の範囲外の書き込み（CVE-2026-90559）や、圧縮データで宣言された大きさのまま最大2GBのメモリを確保してしまう問題（GHSA-q233-g92q-qxp6、SnappyInputStreamなども対象）も直っています。型付き配列のメソッドを使っていなくても、上げる理由は残ります。[5][6]

悪用の状況

2026年11月1日時点で、米国のCISAが公開している「悪用が確認された脆弱性の一覧（KEV）」には載っていません。

今後30日以内に悪用される確率の推定値（EPSS）は0.3%です（2026-11-01時点）。見込みは高くない部類ですが、推定値で、悪用されないことを保証するものではありません。

報告のissue（#729）には、展開後の大きさをずらした圧縮データで書き込みを再現するコード（PoC）が公開されています。当社はPoCを検証していません。CISAのコーディネーターがCVEの記録に付けた評価（SSVC）は、9月21日時点で悪用「なし」です。[3][4]

snappy-javaの対象の版と推奨する版

版ごとの状態は次のとおりです（11月1日時点、Maven Centralの最新は1.1.10.12）。[1][7][8][9][13][14]

1.1.10.9に残る2件は、SnappyFramedInputStreamが確保に失敗したときにバッファを二重に返し、別のストリームと同じ配列を共有してしまうおそれ（GHSA-c73m-r934-8qvg）と、SnappyInputStreamの再帰による異常終了と大きなメモリの確保（GHSA-6gp7-6wmv-gxqw）で、いずれも1.1.10.10で直りました。1.1.10.9は日本時間の10月3日、1.1.10.10は10月4日にMaven Centralへ公開されています。Hadoop互換の圧縮の不具合は、よくある質問で説明します。[7][8][9]

snappy-javaの版を確かめて指定する手順

1. Mavenでは、snappy-javaの版と、どのライブラリを通じて入っているかを確かめます。

   ターミナル

   mvn dependency:tree -Dincludes=org.xerial.snappy:snappy-java

2. Gradleでは、実行時に使われる版と、そう決まった理由を確かめます。

   ターミナル

   ./gradlew dependencyInsight --dependency org.xerial.snappy:snappy-java --configuration runtimeClasspath

3. 自分のコードで、型付き配列のメソッドを使っている箇所を探します。

   ターミナル

   grep -rn -E 'uncompress(Char|Short|Int|Long|Float|Double)Array' --include='*.java' --include='*.kt' --include='*.scala' .

4. Mavenでは、dependencyManagementで版を指定すると、間接的に入るsnappy-javaもその版になります。

   pom.xml

   <dependencyManagement>
     <dependencies>
       <dependency>
         <groupId>org.xerial.snappy</groupId>
         <artifactId>snappy-java</artifactId>
         <version>1.1.10.12</version>
       </dependency>
     </dependencies>
   </dependencyManagement>

5. Gradleでは、依存の制約（constraints）で版を指定します。Gradleは、制約と他のライブラリの指定のうち高い版を選びます。

   build.gradle.kts

   dependencies {
       constraints {
           implementation("org.xerial.snappy:snappy-java:1.1.10.12")
       }
   }

6. もう一度版を確かめ、アプリやコンテナのイメージを作り直します。Kafka・Spark・Hadoopを使う場合は、圧縮と展開の動作もテストで確かめます。

   ターミナル

   mvn dependency:tree -Dincludes=org.xerial.snappy:snappy-java

すぐに上げられないとき

提供元のアドバイザリは回避策として、これらのメソッドを呼ぶ前に、Snappy.uncompressedLength(input)が要素の大きさの倍数かを確かめることを示しています。要素の大きさは、char・shortが2、int・floatが4、long・doubleが8バイトです。[1]

この回避策で防げるのは今回の件だけで、同じ版で直った他の件は防げません（当社の整理）。上のライブラリの都合で上げられない場合も、次の節の方法でsnappy-javaの版だけを指定できることがあります。

Kafka・Spark・Hadoopを上げても、snappy-javaは古いまま残る

snappy-javaは、圧縮を扱うJavaのライブラリの依存として入ります。Maven Centralに登録された主なライブラリの指定は、11月1日時点で次のとおりで、いずれも対象の版です。[10][11][12]

Kafkaは開発中のリポジトリで1.1.10.11に上げていますが、公開済みの4.4.0には入っていません。Mavenは、依存の木で近い指定を優先して版を決めます。自分のpom.xmlでsnappy-javaの版を指定しない限り、これらのライブラリの指定が使われます。[10][15][16]

脆弱性の公表・更新一覧で、Java / JVMの関連情報を調べることもできます。

better-authの脆弱性で起きることと仕組み

攻撃者は、ねらった相手のメールアドレスで社外のOAuthサインインを始め、返ってきたstateの値を、そのアドレスのMagic Linkサインインの確認に送ります。better-authは、OAuthのstateとMagic Linkのトークンを同じ保存先に同じ識別子で記録していたため、Magic Linkの処理が両者を区別できませんでした。結果として、攻撃者はメールを受け取れることを証明しないまま、その利用者としてサインインできます。[1]

深刻度は、CVEの採番機関であるGitHub（GitHub_M）の評価でCVSS 3.1の9.1（緊急）です。この問題には、VulnCheckが別にCVE-2026-110862を採番し、CVSS 4.0で9.3（緊急）と評価しています。弱点の分類はCWE-287（不適切な認証）です。[1][3][4]

影響を受ける条件

アドバイザリは、次がすべて当てはまる構成を対象としています。独自のハッシュ関数を使っている場合は、Magic LinkとOAuthのstateが同じ保存値にならないかを確かめます。

• better-authが1.4.0-beta.18以上、1.7.7未満である。[1]
• Magic Linkプラグインが有効で、トークンの保存が既定のstoreToken: "plain"、または"hashed"かつ全体のverification.storeIdentifierも"hashed"になっている。[1]
• 組み込みのソーシャルログイン、またはGeneric OAuthが有効である。[1]
• OAuthのstateをデータベースに保存している（account.storeStateStrategy: "database"。データベースまたはセカンダリストレージを設定したときの既定）。stateをCookieに保存している場合、この経路は塞がれます（ただし後述のOAuth Proxyの条件に注意）。[1]

対象の場合、認証していない攻撃者が、相手のメールアドレスを知っているだけでその利用者のセッションを得て、アカウントの権限をすべて使えます。メールボックスやOAuth提供元へのアクセスは要りません。Magic Linkでの新規登録が有効で、そのアドレスの利用者がまだいなければ、「メール確認済み」と誤って記録されたアカウントを作られます。確認済みのメールアドレスやドメインを信頼して権限を与えるアプリでは、影響が広がります。[1]

悪用の状況

2026年11月1日時点で、米国のCISAが公開している「悪用が確認された脆弱性の一覧（KEV）」には載っていません。

今後30日以内に悪用される確率の推定値（EPSS）は0.4%です（2026-11-01時点）。見込みは高くない部類ですが、推定値で、悪用されないことを保証するものではありません。

アドバイザリに再現用のコード（PoC）の公開はありません。KEVには載っておらず、実際の悪用の報告もありません。[1]

対象のバージョンと推奨する版

修正版は1.7.7です。1.4.0-beta.18以上1.7.7未満が影響を受けます。配布元（npm）で公開済みの版で、確認日は2026年11月1日です。1.7.7はアドバイザリと同じ2026年10月1日（日本時間）にnpmで公開されています（アドバイザリ本文には公表時点で未公開とありますが、収録までに公開されました）。更新の前に、提供元のリリースノートで変更点を確かめてください。[1][7][8]

1.7.7は、今回のMagic Linkの問題と同時に、OAuth Proxyで別人としてサインインできる問題（高）も直しています。[1][8][10]

better-authがどこから入っているか確かめて上げる手順

1. 使っている版と、どのパッケージが連れてきているかを確認します。依存はpackage-lock.json・yarn.lock・pnpm-lock.yamlにも記録されています。

   ターミナル

   npm ls better-auth

2. 対象の構成かを設定で確かめます。Magic Linkの指定、storeToken、verification.storeIdentifier、account.storeStateStrategyの指定を探します（指定が無ければ既定値で判断します）。

   ターミナル

   grep -rn -E "magicLink|storeToken|storeStateStrategy|storeIdentifier" --include="*.ts" --include="*.js" .

3. 1.7.7以上へ更新します。別に入れている@better-auth/のアダプター・プラグインも同じ版にそろえます。

   ターミナル

   npm install better-auth@1.7.7

4. 間接依存で入っている場合は、package.jsonのoverridesで版を固定して入れ直します（yarnはresolutions、pnpmはpnpm.overrides）。

   package.json

   "overrides": {
     "better-auth": "1.7.7"
   }

5. 更新後の版を確かめます。更新すると既存のMagic Linkと途中のサインインは無効になるため、利用者への案内も用意します。

   ターミナル

   npm ls better-auth

すぐに更新できないときの対処

更新できるまでの間は、アドバイザリが挙げる次のいずれかで緩和します。[1]

• account.storeStateStrategyを"cookie"にする。OAuth Proxyを使う場合は、先に各環境の全体用の秘密鍵とは別の専用secretを、関係するすべての環境に設定します（共有したままだと別の乗っ取り経路が開きます）。[1]
• Magic LinkのstoreTokenを"hashed"にし、全体のverification.storeIdentifierは未設定か"plain"にする。[1]
• Magic Link、またはソーシャル・Generic OAuthのサインインを止める。[1]

Magic LinkのdisableSignUp: trueだけでは足りません。新しい確認済みアカウントの作成は止まりますが、既存アカウントの乗っ取りは防げません。[1]

1.7.7へ上げるときの段取り

更新すると、それまでに発行したMagic Linkと、処理の途中だったOAuthサインインのstate・SAMLの途中状態は使えなくなります。利用者はサインインやアカウント連携をやり直すことになります。データベースのスキーマ移行は要りません。[1][8]

別に入れている@better-auth/のアダプター・プラグイン（例：@better-auth/drizzle-adapter）は、本体と同じ版にそろえて更新します。検証用の保存先を共有する複数のサーバーや、OAuth Proxyに参加するすべての環境（本番・プレビュー・開発）は、同じタイミングで切り替えます。混在すると途中状態をやり取りできません。[1][8]

1.6系から上げる場合は、1.7系で入った設定・スキーマの変更（アカウントのissuer必須化、Generic OAuthの書き換え、OIDC/MCPプラグインの分離など）があります。1.7系に修正版が出ているため、1.6系に留まったままの対処はありません。提供元の1.7アップグレード手順に沿って進めます。[9]

脆弱性の公表・更新一覧で、JavaScript / TypeScriptの関連情報を調べることもできます。

LiteLLMの脆弱性2件で起きることと仕組み

今回の2件の脆弱性は、どちらもLiteLLMのプロキシの認証の問題です。[1][2]

CVE-2026-114612は、internal_userの権限を持つ利用者がproxy_adminに昇格できる問題です。公式の説明では、プロキシは保存する秘密情報の暗号化と、セッションのトークンの発行に同じ鍵を使っていました。偽の管理者情報を入れたAPIキーを作らせ、暗号化されて返った値をトークンとして示すと、管理者として扱われます。管理者になると、MCPのstdioのエンドポイントからホスト上でコマンドを実行できます。深刻度はLiteLLMの評価でCVSS 3.1の9.9（緊急）で、GitHub Advisory DatabaseはCVSS 4.0の7.7も付けています。[1][3]

CVE-2026-59822は、MCPのStreamable HTTPのエンドポイントで、LiteLLMのキーの確認に失敗しても、空の認証情報で処理が続いた問題です。任意のBearerトークンを付けた認証なしの要求で、設定済みのMCPのツールを一覧・呼び出しできるおそれがあります。深刻度はLiteLLMの評価でCVSS 4.0の8.8、NVDの評価でCVSS 3.1の8.2（重要）です。[2][4]

LiteLLMの脆弱性の影響を受ける条件

LiteLLMは、プロキシとして起動すると、利用者ごとのAPIキーを発行・管理する窓口になります。SDKとしてだけ使う場合の扱いは、アドバイザリに書かれていません。[1][2]

10月21日の不正な1.107.0は、脆弱性とは別に確かめる

10月21日の件は、コードの不具合ではなく、配布物の差し替えです。LiteLLMの告知によると、PyPIの1.107.0は日本時間の20時39分から22時23分まで公開されていました。Docker HubとGHCRのイメージ（タグはv1.107.0、latest、main-latest、main-stable）も、20時46分から最長で23時20分まで不正なものを指していました。GitHubのv1.107.0のソースに不正なファイルは無く、プライベートのエンタープライズ版も影響を受けていないと説明しています。侵入の経路は、10月23日の続報で一部が訂正されています。[5][7]

不正なファイルはPythonの起動時に読み込まれるため、LiteLLMを読み込まないプログラムでも動きます。提供元は、外部に通信できる環境で1.107.0を入れた場合は持ち出しが成功したと考えるよう求めています。その環境から届く認証情報（クラウドの権限、プロキシのデータベースに保存した各社のAPIキー、マスターキーと発行したキー、DATABASE_URLのパスワードなど）はすべて交換します。ファイルが見つからないことは、安全の証明にならないとも書いています。不正なイメージは古い鍵の有効な署名を持つため、署名だけでは判断できません。[5]

11月1日時点のPyPIでは1.107.0は取得できず、1.107系は開発版と候補版（1.107.0rc1・rc2）だけです。提供元は、それより前の版は安全だと説明しています。3月24日にも1.82.7と1.82.8が不正に公開され、削除されました。[5][6][8]

LiteLLMの脆弱性の悪用の状況

今回の権限昇格（CVE-2026-114612）は、2026年11月1日時点で、米国のCISAが公開している「悪用が確認された脆弱性の一覧（KEV）」に載っていません。一方、同じLiteLLMのプロキシでは、ほかの脆弱性がKEVに載っています。[9]

同じLiteLLMでKEVに載っているのは、SQLインジェクション（CVE-2026-42208、5月8日）、コマンド実行（CVE-2026-42271、6月8日）、MCPの認証不備（CVE-2026-59822、9月2日）の3件で、いずれも1.84.0以降で直っています。CVE-2026-114612の今後30日に悪用される見込みの推定（EPSS）は0.3%です（10月31日時点）。アドバイザリは手口を文章で説明していますが、再現用のコード（PoC）の公開は確認できていません。[9][13]

攻撃を受けていないかの確認

KEVに載っている3件は1.84.0より前の版が対象です。1.84.0より前の版をインターネットから届く状態で動かしていた場合は、更新に加えて、更新前に攻撃を受けていないかを確認します。

1. 公開していた期間のWebサーバー・アプリケーションのログで、異常終了や不審な要求がないか確認します。
2. 見覚えのないファイル（Webシェルなど）や、設定・アカウントの変更がないか確認します。
3. サーバーから見覚えのない宛先への通信がないか確認します。
4. 痕跡が見つかった場合は、ログや機器の状態を保全し、専門の窓口に相談します。

LiteLLMの対象の版と推奨する版

問題ごとの対象のバージョンと、直った版・扱いは次のとおりです。

2件の脆弱性は、1.104.0以降の正式版ならどちらも直っています。KEVに載っているLiteLLMの3件も、1.84.0以降で直っています。そのうえで不正な配布物を避けるため、提供元が示した1.106.2か、それ以降に公開された版を==で固定し、1.107.0は使いません。[1][2][5][9]

プロキシとして使う場合は、下で動くStarletteの版も確かめます。1.84.0〜1.87系はFastAPIを0.124.4に固定しているため、Starletteが、脆弱性BadHost（CVE-2026-48710）の直った1.0.1に上がりません。1.88.0以降はStarlette 1.0.1以上を求めます。Starletteの確かめ方はStarletteのBadHostの記事で説明しています。[10][11]

LiteLLMのバージョンを確かめて上げる手順

1. 稼働中の環境で、LiteLLMの版を確認します。1.107.0、1.82.7、1.82.8なら、更新の前に手順3へ進みます。

   ターミナル

   python -m pip show litellm

2. Dockerで使っている場合は、イメージの識別値（digest）を確認します。提供元は、sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339eのイメージを動かしたコンテナを、侵害されたものとして扱うよう求めています。[5]

   ターミナル

   docker images --digests | grep -i litellm

3. 1.107.0を入れた環境では、先にpip installを実行しません。site-packagesのcook.pth、cook.py、sitecustomize.pyとそれぞれの.pycを消し、/tmp/remote_code_loader.lockを持つPythonのプロセスを止めます。提供元は、環境を作り直すほうがよいとしています。[5]

   ターミナル

   find / -path '*site-packages/*' \( -name 'cook.pth' -o -name 'cook.py' -o -name 'sitecustomize.py' -o -name 'litellm-1.107.0.dist-info' \) 2>/dev/null
   ls -l /tmp/remote_code_loader.lock

4. 版を固定して入れ直します。提供元が名指しで案内している1.106.2に固定します。11月1日時点のPyPIには、告知の後に公開された1.106.6もありますが、提供元はこの版を名指ししていません。[5][6]

   ターミナル

   python -m pip install "litellm[proxy]==1.106.2"

5. requirements.txt・poetry.lock・uv.lockに古い版や1.107.0が残っていないかを確かめ、もう一度版を確認します。

   ターミナル

   grep -n -i 'litellm' requirements*.txt poetry.lock uv.lock
   python -m pip show litellm

すぐ上げられないときの回避策

提供元のアドバイザリが示す回避策は次の2つです。CVE-2026-114612では、EXPERIMENTAL_UI_LOGIN=falseにすると問題の認証の経路が無効になります。ただし、CLIのSSOとClaude Codeのゲートウェイのログインが使えなくなります。CVE-2026-59822では、MCPの経路を無効にするか、リバースプロキシやAPIゲートウェイで/mcp/などへの接続を止めます。[1][2]

管理画面とAPIを社内のネットワークからだけ使えるようにすることも、届く経路を減らします。これは当社の整理で、提供元が示した回避策ではありません。

脆弱性の公表・更新一覧で、Pythonの関連情報を調べることもできます。

ImageSharpのCVE-2026-106113で起きること

提供元のアドバイザリによると、HistogramEqualization()は、画素の明るさ（輝度）からヒストグラムの位置を計算し、その値を確かめずにメモリ上の位置として使っていました。32ビット浮動小数点のTIFFに「正の無限大」の値を入れると、計算した位置が範囲を外れ、安全でないメモリへのアクセスが起きます。[1]

報告者の再現では、2.0.0・3.1.12・4.0.0・4.1.1でAccessViolationExceptionが起き、プロセスが終了しました。画像を処理するサービスが止まるおそれがあります。深刻度は提供元の評価でCVSS 3.1の7.5（可用性への影響が高）で、NVDも同じ値を載せています。[1][3]

ImageSharpの脆弱性の対象になる処理

次の3つがそろう場合が対象です。報告の対象はHistogramEqualizationだけで、適応型のヒストグラム平坦化とAutoLevelは含まれていません。[1]

• SixLabors.ImageSharpが2.0.0以上3.2.0未満、または4.0.0以上4.1.2未満（TIFFの読み込みは2.0.0から）
• 攻撃者が用意した32ビット浮動小数点のTIFFを、Image<HalfVector4>として読み込む
• 読み込んだ画像にHistogramEqualization()をかける

Webの画像の変換に使われるImageSharp.Webの標準の処理（リサイズ、形式、画質、背景色、向きの補正）には、ヒストグラム平坦化は含まれていません（当社がソースで確認）。自分のコードでHistogramEqualizationとHalfVector4を使っているかを探すと、見分けがつきます。[5]

悪用の状況

2026年11月1日時点で、米国のCISAが公開している「悪用が確認された脆弱性の一覧（KEV）」には載っていません。

今後30日以内に悪用される確率の推定値（EPSS）は0.4%です（2026-11-01時点）。見込みは高くない部類ですが、推定値で、悪用されないことを保証するものではありません。

提供元のアドバイザリには、無限大の画素を持つTIFFを作ってプロセスを終了させるまでの再現用のコード（PoC）とDockerfileが載っています。アドバイザリには「悪用の事例は知られていない」と書かれていて、CISAのコーディネーターがCVEの記録に付けた評価（SSVC）も10月7日時点で悪用「なし」です。当社はPoCを検証していません。[1][3]

ImageSharpの対象の版と推奨する版

系列ごとの対象と修正版は次のとおりです。必要な.NETの版は、NuGetに登録された対応の環境です。[1][2][4]

3系の修正版3.2.0は、4系の4.1.2から約4週間後の10月9日に公開され、アドバイザリも同じ日に更新されました。NVDの説明文は11月1日時点でも「4.1.2未満が対象、4.1.2で修正」のままで、これを写した脆弱性データベースでは3.2.0も対象と表示されることがあります。提供元のアドバイザリとNVDの対象の定義（CPE）は、どちらも3.2.0を修正版としています。[1][3]

ImageSharpの版を確かめて上げる手順

1. プロジェクトが参照しているImageSharpの版を、間接的な依存も含めて確かめます。

   ターミナル

   dotnet list package --include-transitive | grep -i imagesharp

2. NuGetの脆弱性の情報で、対象の版が入っていないかも確かめます。

   ターミナル

   dotnet list package --vulnerable --include-transitive

3. コードの中で、該当の処理を使っているかを探します。

   ターミナル

   grep -rn -E 'HistogramEqualization|HalfVector4' --include='*.cs' .

4. 使っている系列の修正版へ上げます（4系か3系の、どちらかの行を実行します）。

   ターミナル

   dotnet add package SixLabors.ImageSharp --version 4.1.3
   dotnet add package SixLabors.ImageSharp --version 3.2.0

5. ライセンスキーを環境変数から渡す場合は、プロジェクトファイルに次を足し、SIXLABORS_LICENSE_KEYに発行されたライセンスの全文を入れます（Six Laborsの文書の例）。

   csproj

   <PropertyGroup>
     <SixLaborsLicenseKey>$(SIXLABORS_LICENSE_KEY)</SixLaborsLicenseKey>
   </PropertyGroup>

6. Releaseでビルドできることを確かめ、もう一度版を確かめます。コンテナのイメージなども作り直します。

   ターミナル

   dotnet build -c Release
   dotnet list package --include-transitive | grep -i imagesharp

すぐに上げられないとき

提供元のアドバイザリに回避策の節はありません。次は、公表された成立条件から当社が整理した緩和策で、提供元の推奨ではありません。

• 外部から受け取った浮動小数点のTIFFに、HistogramEqualization()をかけない
• 処理の前に、画素に無限大などの有限でない値が含まれていないかを確かめる
• TIFFを受け付ける必要がなければ、読み込む前に形式を確かめて拒否する

3.2.0と4系は、ビルドにライセンスキーが要る

Six Laborsの文書は、ImageSharpを直接参照するプロジェクトには、3系では3.2.0から、4系では4.0.0から、ビルドの際に有効なライセンスキーが必要だと説明しています。間接的な依存として入る場合は対象外で、提供元は「既存のライセンス条件の適用で、条件の変更ではない」としています。[6]

3.2.0のパッケージにはビルドのときにライセンスを確かめる処理が入っていて、キーが見つからないと、Debugのビルドは続けられますが、Releaseのビルドは失敗します。キーは、sixlabors.licをプロジェクトのフォルダに置くか、SixLaborsLicenseKey・SixLaborsLicenseFileのプロパティで渡します。[6][7]

3系以降のライセンスはSix Labors Split Licenseで、オープンソースのソフトウェアでの利用、非営利の団体、年間の総収入が100万米ドル未満の企業などはApache License 2.0で使え、それ以外は商用ライセンスが必要です。2系はApache License 2.0でした。前者に当たる場合も、キーの申し込みが要ります。[4][7][8]

2系・.NET Frameworkで使っている場合

2系向けの修正版は、アドバイザリに記載がありません。2系の最新は2025年11月の2.1.13で、NuGetはこの版にもこの件を表示しています。2系は.NET Framework 4.7.2や.NET Standard 2.0に対応していますが、3.2.0は.NET 6、4系は.NET 8向けで、.NET Frameworkのアプリには入れられません。[1][4]

その場合は、.NET 6以降へ移って3.2.0か4系を入れるか、移るまでの間、前の節の緩和策で該当の処理を止めます。2系から上げるときは、ライセンスの条件とキーの用意も確かめます。

脆弱性の公表・更新一覧で、.NETの関連情報を調べることもできます。

StarletteのBadHostで起きることと仕組み

Starletteは、受け取った要求のURL（request.url）を、Hostヘッダーとパスをつないで組み立て直します。公式アドバイザリによると、1.0.0以前はこのときHostヘッダーを検証していませんでした。Hostに/、?、#などを含めると、組み立て直したURLのパスが、実際に要求されたパスとずれます。[1]

振り分け（ルーティング）は実際のパスで行われるため、本来のエンドポイントは動いたまま、request.url.pathだけが別のパスに見えます。特定のパスの下だけを守るミドルウェアがrequest.url.pathで判定していると、その確認を回避されるおそれがあります。[1]

StarletteのBadHostの影響を受ける条件

公式は、前段のプロキシやロードバランサーが不正なHostを拒否または正規化し、かつアプリがX-Forwarded-Hostなど攻撃者が操作できるヘッダーを他の箇所で信頼していない場合に限り、影響が抑えられると説明しています。[1]

対象の版と影響する使い方は次のとおりです。

悪用の状況

米国のCISAは2026年9月2日、CVE-2026-48710を「悪用が確認された脆弱性の一覧（KEV）」に追加しました。実際の攻撃で使われていることを示すため、優先して対応します。

発見者のX41 D-Secは、再現用のアプリと攻撃のコード（PoC）、検出用のスクリプトを公開しています。今後30日に悪用される見込みの推定（EPSS）は70.3%です（10月31日時点）。KEVの説明には、LiteLLMのコマンド実行の脆弱性（CVE-2026-42271、6月8日からKEV）と組み合わせられるおそれがあると書かれています。[4][5][6]

攻撃を受けていないかの確認

悪用が確認された脆弱性は、更新に加えて、更新前に攻撃を受けていないかを確認します。

1. 公開していた期間のWebサーバー・アプリケーションのログで、異常終了や不審な要求がないか確認します。
2. 見覚えのないファイル（Webシェルなど）や、設定・アカウントの変更がないか確認します。
3. サーバーから見覚えのない宛先への通信がないか確認します。
4. 痕跡が見つかった場合は、ログや機器の状態を保全し、専門の窓口に相談します。

Starletteの対象の版と推奨する版

1.0.1は、Hostヘッダーを規格（RFC 9112・RFC 3986）の文法で確かめ、不正な値のときは接続の情報（scope["server"]）を使うように直した版です。その後、パスの側からホスト名を偽れる低い深刻度の問題（GHSA-jp82-jpqv-5vv3）が1.3.0で、別の高い深刻度の問題（CVE-2026-54283など）が1.1.0と1.3.1で直っています。上げるなら1.3.1以上にします。[1][13][14]

0系には修正版が無いため、0.52.1以前からは1系への更新になります。1.0.0では、on_startup・on_shutdown、on_event()、@app.route()などの古い書き方が削除されました。Starletteを直接使っているアプリは、検証環境で起動と動作を確かめます。最新の1.10.0はPython 3.11以上が必要で、Python 3.10の環境には1.7.0までが入ります。[13]

Starletteの版を確かめて上げる手順

1. 稼働中の環境で、Starletteの版と、どのパッケージが使っているか（Required-byの行）を確認します。

   ターミナル

   python -m pip show starlette

2. FastAPIの版も確認します。FastAPI 0.132系以前はStarletteを1.0.0未満に制限しているので、Starletteを1.0.1以上にするには、FastAPIを0.133.0以上にします。[7]

   ターミナル

   python -m pip show fastapi

3. lockファイルに記録された版を確認します。上のパッケージを更新しても、lockファイルのStarletteが古いままのことがあります。

   ターミナル

   grep -n -i -A1 'name = "starlette"' poetry.lock uv.lock
   grep -n -i 'starlette' requirements*.txt

4. Starletteを直接指定して上げます。FastAPIを使っている場合は一緒に指定します。uvやPoetryでは、lockファイルのStarletteだけを更新できます（使っているツールの行を実行します）。

   ターミナル

   python -m pip install --upgrade "starlette>=1.3.1" "fastapi>=0.133.0"
   uv lock --upgrade-package starlette
   poetry update starlette

5. 実際に読み込まれる版を確かめます。コードの中でrequest.url.pathで判定している箇所も探します。

   ターミナル

   python -c "import starlette; print(starlette.__version__)"
   grep -rn 'request.url.path' --include='*.py' .

すぐ上げられないとき

Starletteのアドバイザリが示す対応は更新で、更新できないときの回避策は書かれていません（前段のプロキシで抑えられる条件は、影響を受ける条件の節のとおりです）。発見者のX41 D-Secは、パスではなくエンドポイントで認証すること、request.url.pathの代わりにrequest.scope["path"]を使うこと、不正なHostを拒否するリバースプロキシやASGIサーバーを置くことを挙げています。これは発見者の推奨で、Starletteが示した回避策ではありません。[1][2]

FastAPI・vLLM・LiteLLMを上げても、古いStarletteが残る理由

pipの--upgradeは、指定したパッケージを上げ、その依存は条件を満たしていればそのまま残します（初期設定のonly-if-needed）。FastAPIは、11月1日時点の最新版0.162.0でも、Starletteに0.46.0以上しか求めていません。そのため、古いStarletteが入った環境でFastAPIだけを上げても、Starletteは対象の版のまま残ります。[7][8]

逆に、上のパッケージが古いStarletteしか許さない場合もあります。PyPIに登録された依存の指定は次のとおりです。[7][9][10][11]

LiteLLMは1.84.0で、自分の認証の判定がStarletteの組み立て直したパスに頼っていた問題（CVE-2026-49468）を直しました。これはLiteLLM側の修正で、同じ環境のStarletteの版は変わりません。LiteLLMそのものの脆弱性と版の切り分けは、LiteLLMの脆弱性とバージョンの記事で説明しています。[12]

脆弱性の公表・更新一覧で、Pythonの関連情報を調べることもできます。