curl 8.23.0 で修正されたCVE-2026-92392 — 「深刻度High」の内実をHTTP/2アップロード処理のUse-After-Freeで読む

curlの開発チームは2026年10月14日、HTTP/2でのアップロード処理に存在するUse-After-Free(解放済みメモリの使用、CWE-416)の脆弱性「CVE-2026-92392」を修正したバージョン8.23.0を公開しました。深刻度は「High」です。アップロード中にサーバーから送られるHTTP/2のRST_STREAMをcurlが誤って処理し、struct Curl_easyオブジェクトが解放された後も使われる状態になるというのが問題の核です。この記事で確認できるのは、この脆弱性の仕組み、「High」という深刻度の内実、そして自社のcurl利用箇所が実際に影響を受けるかどうかの切り分け方です。

何が起きているか——RST_STREAMの誤処理からUse-After-Freeへ

curl公式のCVEページによれば、問題が起きるのはHTTP/2でファイルなどをアップロードしている最中です。サーバー側がアップロードを拒否する際に送るRST_STREAM(ストリームのリセット)には、理由コードが付いています。今回問題になったのは、理由コードがHTTP_1_1_REQUIREDまたはREFUSED_STREAMのRST_STREAMを受け取った場合の処理です。

curlはこのRST_STREAMを受け取った後の処理で、リクエストを表すstruct Curl_easyオブジェクトを誤って解放してしまい、その後も同じオブジェクトを参照し続けてしまいます。解放済みのメモリ領域を使い続けるこの状態がUse-After-Freeで、メモリ管理の不整合としてはよく知られた型の欠陥です。

この欠陥自体は、HTTP/2でアップロードを行い、かつサーバー側が該当の理由コードでRST_STREAMを送ってくれば発生します。ここまでは確実に起きる挙動です。問題は、この先の「何に使われ得るか」の部分です。

「High」の内実——悪用には多くの前提条件が要る

curl公式のCVEページは、悪意あるサーバーが特定の条件(バージョン・メモリ配置・libc情報など多くの前提条件)を満たせば、この欠陥をリモートコード実行に転用できる可能性があるとアドバイザリに記載しています。「可能性がある」という書き方そのものが、確実な悪用手段が公開されているわけではないことを示しています。Use-After-Freeが起きることは確実でも、それがリモートコード実行につながるかは、攻撃者が制御できない要素(メモリ配置やlibcの実装差)に依存するというのが、この脆弱性の実際の形です。

一般に脆弱性の深刻度は、想定される最悪のケースを基準に評価されることが多く、「High」という判定も「今すぐ全ての利用箇所で任意のコードが実行される」ことを意味するものではありません。Impress Watch(2026-10-15)の報道によれば、curl 8.23.0は合計24件の脆弱性を修正したとされ、そのうち深刻度Highは本CVEの1件のみ、残り23件はLowだったと報じています。この「24件」はImpress Watch側の集計であり、curl公式のチェンジログが個別項目をすべて脆弱性として明示分類しているわけではないため、集計の基準がcurl公式のCVE追跡と同一かどうかは確認できていません。その留保を踏まえても、curl公式が独立したCVEとして追跡しているのは本CVEのみという事実は変わらず、「High」の判定を軽視も過大評価もせず、次の影響範囲の確認につなげるのが実務上の要点です。

ラベル(深刻度)と悪用条件の両方を見て優先度を判断するのが、脆弱性対応の実務です。「High」の一語だけで対応の緊急度を決めるのではなく、「自社のcurlがHTTP/2アップロードを実際に使っているか」「影響バージョンに該当するか」を次に確認する必要があります。

影響バージョンの正確な切り分け

curl公式のCVEページが示す影響バージョンは、curl 8.12.0から8.22.0まで(両端を含む)です。8.12.0より前のバージョン、および8.23.0以降は影響を受けません。curlコマンドラインツールも対象で、libcurlだけの問題ではありません。

ここで見落としやすいのが、点リリースの系列ごとに、すでにそれより前の時点で修正済みの分岐がある点です。curl公式によれば、8.20.x系列は8.20.2以降、8.16.x系列は8.16.2以降、8.14.x系列は8.14.3以降であれば、8.23.0への更新を待たずに元から影響を受けません。つまり「8.23.0にジャンプしないと安全にならない」わけではなく、使っている系列によっては既存の運用のまま安全な場合があります。

自社のcurlバージョンがどの系列のどの時点かを確認することが、対応の優先度を決める最初の一歩になります。

対処——アップグレード・パッチ・一時停止の3択

curl公式が示す対策は3つです。推奨はcurl 8.23.0へのアップグレードで、これが最も確実です。アップグレードがすぐにできない場合は、修正パッチの適用、または一時的にHTTP/2の使用を停止するという選択肢もあります。HTTP/2を止める対応は、アップロード機能自体を止めるものではなく、プロトコルのバージョンを落とすことで今回のRST_STREAM誤処理の経路そのものを避ける、応急的な回避策です。

なお、この脆弱性はLuna with Claude(Anthropic)という報告者からcurlプロジェクトへ報告され、Stefan Eissing氏が修正したと公式ページに記載されています。報告から公開までの経緯の詳細は公式ページに記載がなく、本稿ではこの事実の範囲でのみ扱います。

自社のcurl利用箇所を今日から確認する

自社でcurl・libcurlを使っている箇所がある場合、今日から確認できる手順は3つです。

• 使っているcurl/libcurlのバージョンを確認します。CLI・各言語のHTTPクライアントライブラリが内部で使うlibcurlの両方を確認対象にします。
• バージョンが8.12.0〜8.22.0の範囲に入っているか、かつ8.20.2/8.16.2/8.14.3のような先行修正点より前かを照合します。範囲外、または先行修正済みの系列であれば、今回のCVEによる対応は不要と判断できます。
• すぐにアップグレードできない事情があるなら、パッチ適用かHTTP/2の一時停止で時間を作れます。該当する場合の第一候補は、それでもcurl 8.23.0へのアップグレードです。

まとめ

8.20.2/8.16.2/8.14.3のいずれかを既に使っているチームにとって、今日やることは「何もしない」で確定します。これも確認した上で出てくる分岐の1つで、深刻度Highという言葉だけでは見えてきません。

自社のcurl/libcurlのバージョンを次に確認する時の基準は、「8.23.0にしたか」ではなく「そもそも影響範囲に入っているか」です。

関連

自社サイトの状態が気になったときは、URL を入れるだけで使える無料の診断ツールを公開しています。

• 安心チェック｜Web セキュリティ簡易診断

出典

• curl.se: CVE-2026-92392
• curl.se: changes.html(8.23.0 リリースノート)
• Impress Watch(窓の杜): curl 8.23.0 で24件の脆弱性を修正(2026年10月15日)

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)