curl 脆弱性 CVE-2026-92392 は、curl と libcurl の HTTP/2 アップロード処理に見つかった use-after-free（解放済みメモリの参照）だ。2026-10-14 に公開された curl 8.23.0 で修正されている。影響を受けるのは 8.12.0 から 8.22.0 までで、curl コマンド（CLI）も対象に含まれる。この記事は一次情報である curl 公式アドバイザリと Debian セキュリティトラッカーを突き合わせ、何が起きるのか・自分の版をどう確かめるか・何をすればいいかを煽らずに整理する。

WHAT HAPPENS何が起きるか

HTTP/2 アップロード中の use-after-free

  1. HTTP/2 でアップロード

    curl がサーバーへ送信中

  2. サーバーが RST_STREAM

    特定の理由でストリームを打ち切る

  3. 解放済みメモリを参照

    use-after-free が起きる

  4. 大半はクラッシュ

    RCE は多条件が揃った時だけ

出典: curl アドバイザリ CVE-2026-92392

30秒でわかる CVE-2026-92392（2026-10-25時点）

  • ・何が：curl / libcurl の HTTP/2 アップロードでの use-after-free
  • ・影響版：8.12.0〜8.22.0（修正は 8.23.0・2026-10-14 公開）
  • ・深刻度：curl の 4 段階評価で High。多くはクラッシュで、RCE は多条件が揃った時だけ
  • ・対策：8.23.0 以降へ更新。難しければ HTTP/2 を避ける

まずやること

  • ・curl --version の先頭行で、自分の版が 8.12.0〜8.22.0 に入るかを見る
  • ・入っていれば 8.23.0 以降へ更新。すぐ更新できなければ、アップロードで HTTP/2 を使わない

OSS の依存を狙う攻撃と防御の全体像は、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。本記事はその一事例として、広く使われる curl の一件を扱う。

curl 脆弱性 CVE-2026-92392 のタイムライン｜8.23.0 で修正

公表されている事実を、公表日を軸に時系列で並べる。進行中の未確定情報ではなく、修正公開後の整理である。

・2026-10-14：curl 8.23.0 公開。CVE-2026-92392 を含む複数の脆弱性を修正
・同日：curl 公式アドバイザリ（CVE-2026-92392.html）で影響版・条件・対策を開示
・バックポート：8.14.x・8.16.x・8.20.x の各系列にも修正を提供
・ディストロ：Debian など各ディストリビューションが順次、修正パッケージを配布

報告は Anthropic の Luna（Claude を用いた調査）によるもので、HTTP/2 まわりの修正は curl の HTTP/2 実装を担う Stefan Eissing が書いている。公開日時点で NVD の解析は未了のため、深刻度は curl 自身の 4 段階評価（High）を基準に見るのがよい。

何が起きたか｜HTTP/2 アップロードの use-after-free

curl が HTTP/2 でサーバーへデータをアップロードしている最中に、サーバーが特定の理由コードで RST_STREAM（ストリームの打ち切り）を返すと、curl 側に解放済みの内部オブジェクトを指したままのポインタが残る。これを参照してしまうのが use-after-free で、結果としてメモリが壊れる。攻撃者はアップロード先のサーバー側にいる必要があるため、通りすがりに誰でも成立する類いの不具合ではない。

MYTH VS REALITY誤解と実態

RCE に必要な条件は多い

受けがちな誤解

実際の難しさ

受けがちな誤解: HTTP/2 なら誰でも乗っ取られる

実際の難しさ: 攻撃者が接続先サーバーである必要がある

受けがちな誤解: 更新しないと即コード実行

実際の難しさ: 正確なビルドとメモリ配置の把握が要る

受けがちな誤解: どの環境でも再現する

実際の難しさ: libc とヒープの一致・CA バンドルの固定が要る

受けがちな誤解: 確実に任意コードが走る

実際の難しさ: 2 転送の精密なタイミングと短い命令の制約

受けがちな誤解: 最悪は常に RCE

実際の難しさ: 最も起きやすいのはクラッシュ

出典: curl アドバイザリ CVE-2026-92392

公式アドバイザリはこの use-after-free を任意コード実行（RCE）に変換できることを示しつつ、それが成立するのは多くの条件が同時に揃った場合に限ると明記している。具体的には、正確なビルドとメモリレイアウトの把握、一致する libc のアロケータとヒープ、固定された CA バンドル、2 つの並列転送の精密なタイミング、そして実行に使える領域が約 23 バイトという短さの制約などである。これらが外れると成立しない。curl のアドバイザリは、最も可能性が高い結果はクラッシュだとしている。つまり「怖い 0day」として身構えるより、落ち着いて更新する種類の問題だと捉えるのが実態に近い。

この不具合が HTTP/2 に限られるのは、RST_STREAM が HTTP/2 のフレームだからだ。HTTP/2 は 1 本の接続の上で複数のストリームを多重化し、サーバーは個別のストリームだけを途中で打ち切れる。アップロード中にそれが起きたときの後片付けに取りこぼしがあり、解放したオブジェクトへの参照が残った。HTTP/1.1 のアップロード経路は同じ仕組みを持たないため、この問題の対象にならない。回避策として HTTP/1.1 を使う案が成り立つのはこのためだ。

なお本記事では、攻撃を再現する手順や実証コードは扱わない。読者が自分の環境を守るために必要なのは、版の確認と更新であって、攻撃の作り方ではないからだ。報告が Anthropic の Luna による Claude を用いた調査から来ている点は、こうしたメモリ安全性の不具合を見つける作業に AI が使われ始めている流れの一例でもある。

対策｜8.23.0 への更新と HTTP/2 の回避

やることは多くない。順番に片づける。

WHAT TO DO対策

自分の版の確認と更新

  1. 1.自分の curl の版を確認

    curl --version の先頭行を 8.23.0 と比べる

  2. 2.8.23.0 以降へ更新

    またはディストロの修正パッケージへ

  3. 3.更新できなければ HTTP/2 を避ける

    アップロードは --http1.1 で送る

  4. 4.ディストロ版は各トラッカーで確認

    パッケージ版番号は上流版と別物

出典: curl アドバイザリ CVE-2026-92392

・更新する：上流版なら 8.23.0 以降へ。古い系列を使い続ける事情があれば、8.14.x・8.16.x・8.20.x のバックポート版へ
・回避する：更新できない間は、HTTP/2 を使わない。curl コマンドのアップロードなら --http1.1 を付ける。これは一時的な回避で、恒久対策は更新
・ディストロ版を確かめる：OS のパッケージで入れている場合、版番号は上流と別物。各ディストロのトラッカーで CVE-2026-92392 の状態を見る

影響版かどうかの対応は次の表のとおり。上流の版番号とディストロの版番号が別軸であることに注意したい。

区分 版・ビルド 状態
上流 curl / libcurl 8.12.0〜8.22.0 影響あり
上流 curl / libcurl 8.23.0（2026-10-14 公開） 修正
上流バックポート 8.14.x / 8.16.x / 8.20.x 系列 修正あり
Debian trixie 8.14.1-2+deb13u7（DSA-6558-1） 修正
Debian sid 8.23.0-1 修正
Debian bookworm （該当コードを含まない） 影響なし

Debian bookworm が「影響なし」なのは、問題のコードがその版に含まれていないためで、Debian のトラッカーがそう判定している。このように、上流の版番号だけを見て一律に当てはめると取り違える。Homebrew で入れた 8.22.0 は上流の最終影響版にあたるため、8.23.0 以降が配られるまでは影響版として扱うのが安全だ。依存を定期的に上げておく運用そのものの作り方は、Renovate と Dependabot で依存更新を自動化するで扱っている。

自分の curl の版を確認する

自分の環境がどの版かを、実際のコマンドで確かめる。以下はすべて読み取り系で、環境を変えない。

# 1) curl コマンド（CLI）の版。先頭行の版を 8.23.0 と比べる
curl --version | head -1

# 2) Debian / Ubuntu 系のパッケージ版（上流版とは別番号）
dpkg -l curl libcurl4 2>/dev/null

# 3) RPM 系（Fedora / RHEL など）
rpm -q curl 2>/dev/null

# 4) Homebrew（macOS / Linuxbrew）
brew list --versions curl 2>/dev/null

先頭行には curl 8.x.y (...) libcurl/8.x.y ... nghttp2/... のように版と HTTP/2 ライブラリ（nghttp2）が並ぶ。版が 8.12.0〜8.22.0 の範囲なら影響版、8.23.0 以降なら修正済みだ。ただし、この版表示だけでは、配布ビルドに修正が取り込まれているかの確定診断ではない。ディストロが古い版番号のまま修正だけを当てていることがあるからで、最終的な可否は各ディストロのトラッカーで CVE-2026-92392 を引いて確かめる。アプリに同梱された libcurl（コンテナ内や言語ランタイム経由のもの）は、OS の curl とは別に版を持つ点にも注意する。

影響範囲とまとめ｜curl 脆弱性にどう対処するか

影響を受けるのは、信頼できないサーバーへ HTTP/2 でアップロードする経路だ。curl コマンドの CLI も、libcurl を組み込んだアプリケーションも、どちらも対象になる。ファイルのアップロード、API への PUT/POST、CI からの成果物送信など、送信を伴う用途は一度棚卸ししておきたい。逆に、HTTP/1.1 しか使わない経路や、自分が管理する信頼できる相手だけに送る経路は、相対的に優先度が下がる。

見落としやすいのが libcurl を間接的に使っているケースだ。多くの言語ランタイムやツール（各種 HTTP クライアント、パッケージマネージャ、監視エージェントなど）が内部で libcurl にリンクしている。OS の curl コマンドを 8.23.0 に上げても、アプリに同梱された古い libcurl はそのまま残ることがある。コンテナイメージも同じで、ベースイメージの curl / libcurl を更新し、イメージを作り直すまで古い版が動き続ける。自分のスタックのどこで HTTP/2 アップロードが走るかを、この機会に一度たどっておくとよい。

もう一度まとめると、CVE-2026-92392 は curl / libcurl 8.12.0〜8.22.0 の HTTP/2 アップロードでの use-after-free で、8.23.0 で修正済み。RCE 化には多くの条件が要り、最も起きやすいのはクラッシュだ。やることは、版を確かめて 8.23.0 以降へ更新し、更新できない間は HTTP/2 を避けること。ディストロ版は上流版と別番号なので、各トラッカーで状態を確かめる。別の RCE 事例として、Anthropic 製 MCP の stdio 実装に見つかった RCE 脆弱性も、条件と対処を同じ型で整理している。

参照ソース

・curl security advisory CVE-2026-92392（公式） — 影響版・条件・対策の一次情報（2026-10-25 時点）
・Debian security tracker CVE-2026-92392 — ディストロの修正状況（trixie 8.14.1-2+deb13u7 / DSA-6558-1、bookworm 影響なし）
・curl/curl（公式リポジトリ） — 開発版 RELEASE-NOTES（clone 時点で 8.23.1、8.23.0 公開済みを確認）