Rustのzipクレートの脆弱性CVE-2026-115905、検査をすり抜けて別のファイルを上書きされるおそれ。9.0.5以降も既定で無効の検査を有効にする方法

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]

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

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

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

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

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

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]

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は、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の関連情報を調べることもできます。