undici の共有キャッシュで他人のCookieが配られる

Critical（CVSS 9.1）に分類されるOpenJS Foundation / Node.js undici（cache interceptor）の脆弱性です。Node.js の HTTP クライアント undici の cache interceptor に、2つの欠陥がある。ひとつめは情報漏えいで、上流が返す Cache-Control の private ディレクティブが壊れた形（private が空値、つまり private="" のような degenerate qualified private directive）で来ると、undici がそれを「共有キャッシュに入れてよい応答」と誤って判定し、既定の共有キャッシュへ格納する。同じキャッシュキーで後から来た別の呼び出し元に、その応答がそのまま配られる。NVD の記述と GitHub Security Advisory GHSA-4cwx-7wf7-3272 はいずれも、漏れる対象に応答本文だけでなく Set-Cookie を含むヘッダが入ると明記している。つまり利用者ごとに異なるはずの応答が、別の利用者に渡る。ふたつめは可用性で、Cache-Control に修飾なしの private と修飾つきの private が混在したヘッダが来ると、cache-control のパーサで未捕捉の TypeError が発生する。その要求は失敗し、呼び出し側のエラー処理次第ではプロセスごと落ちる。成立条件は advisory が明示していて、(1) cache interceptor が shared モードで有効になっていること（これは既定の構成を含む）、(2) 上流が壊れた Cache-Control を返すこと、(3) 後続の要求が同じキャッシュキーに当たること、の3つがそろったときである。逆に言えば、攻撃者が任意に条件を作れるわけではなく、上流の応答ヘッダに依存する。CVSS は評価者によって割れている。NVD が付けた主評価（Primary・source は nvd@nist.gov）は 9.1 Critical で、ベクタは AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H である。一方、ベンダー側の評価（Secondary・GHSA-4cwx-7wf7-3272 に対応）は 7.4 High で、ベクタは AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H。差は攻撃条件の複雑さ AC の一項目だけで、NVD が AC:L（条件は単純）、ベンダーが AC:H（条件が複雑）と見ている。上に書いた成立条件3つのうち、「上流が壊れた Cache-Control を返すこと」を攻撃者が自由に作れると見るかどうかで、この差が生まれている。当サイトは NVD の主評価に合わせて 9.1 Critical を採用する（2026-08-22 の再点検で、従来採用していた 7.4 High からこちらへ切り替えた。ベンダー評価が 7.4 のまま併存していることは変わらない）。運用判断としては、低いほうの評価でも High であり、いずれにせよ更新対象である。影響範囲は undici 7.0.0 以上 7.29.0 未満と、8.0.0 以上 8.9.0 未満。NVD の公開は 2026年7月29日、最終更新は 2026年8月4日である。CISA KEV への収載は 2026年8月22日の再点検時点でも確認できていない。

対応は undici を 7.29.0 または 8.9.0 以降へ更新することである。両系列とも修正版が出ているので、7 系を使い続ける場合も 8 系へ上げる必要はない。すぐに更新できない場合、advisory が回避策を3つ挙げている。第一に、利用者ごとに異なる応答（認証後のページ、個人設定、Set-Cookie を伴う応答）に共有キャッシュを使わないこと。第二に、cache interceptor の type を 'private' に指定して共有モードを外すこと。この脆弱性は共有モードでのみ成立するので、これが最も直接的な緩和になる。第三に、問題のある上流オリジンについてキャッシュそのものを無効化すること。運用側で確認しておきたいのは、自分のコードが undici を直接使っていなくても依存の奥で使われている場合があるという点である。npm ls undici で依存ツリー上の実バージョンを確認し、複数バージョンが同居していないかを見ること。ロックファイルを更新せずに package.json だけ直しても実体は変わらない。なお、cache interceptor は明示的に組み込む機能であり、これを使っていなければこの2つの欠陥は成立しない。まず「shared モードの cache interceptor を使っているか」を切り分けてから、更新の緊急度を決めるのが実務的である。Node.js 本体が同梱する undici についてこの CVE がどう扱われるかは、2026年8月21日時点で Node.js のセキュリティリリース情報から確認できていないため、後述のとおり要確認とする。 --- **【2026-09-11 追記・Linux ディストリビューション側の扱い】** 初出時に「ディストリが配布する nodejs パッケージ側の扱いは各トラッカーで確認する」として保留していた点を、実際に確認した。 **Debian セキュリティトラッカーの `node-undici` の状態（2026-09-11 実測）** | リリース | 収録版 | 状態 | |---|---|---| | bookworm | 5.15.0+dfsg1+~cs20.10.9.3-1+deb12u4 | vulnerable（`<postponed>` / Minor issue）| | trixie | 7.3.0+dfsg1+~cs24.12.11-1 | vulnerable（`<no-dsa>` / Minor issue）| | forky, sid | 8.10.2+dfsg+~cs3.2.2-1 | **fixed**（修正が入ったのは 8.9.0+dfsg+~cs3.2.0-1）| **読み方は1つである。安定版では当面パッケージ更新で直らない。**trixie は `<no-dsa>`（DSA を出さない）、bookworm は `<postponed>`（延期）で、どちらも Minor issue と分類されている。**`apt upgrade` を待つ運用は、この CVE については成立しない。** **そもそも見る場所が違う、というのがこの追記の要点である。**undici は npm パッケージであり、多くの場合は**アプリケーションの `node_modules` に直接入っている**か、Node.js 本体に組み込まれた形で使われる。ディストリの `node-undici` パッケージを入れて使っている構成は、実際にはそれほど多くない。**`npm ls undici` で、自分のアプリが何版を抱えているかを確かめるのが先である。**推移的依存として入っていることもある。 **bookworm については、範囲の食い違いも見ておく。**bookworm が収録するのは 5.15.0 系で、本 CVE が影響範囲として挙げる **7.0.0〜7.29.0 未満 / 8.0.0〜8.9.0 未満**には入らない。それでも Debian は vulnerable と記録している。**この食い違いはトラッカー側の判断なので、本サイトでは断定しない。**bookworm 上で動かしている場合も、結論は同じで「アプリが依存している undici の版を実測する」ことになる。

OpenJS Foundation / Node.js undici（cache interceptor） を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-13697）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。