curlのHTTP/2アップロード処理に解放後使用の脆弱性、特定条件下でコード実行の恐れ

多くのシステムやアプリケーションでデータ転送に利用されているcurlおよびlibcurlにおいて、HTTP/2によるアップロード処理に起因する解放後使用の脆弱性（CVE-2026-92392）が報告されました。悪意あるサーバーへ接続した場合にクライアント側で任意のコードが実行される可能性が実証されており、プロジェクトはリリース周期を前倒しして修正版となるcurl 8.23.0などを公開しました。

The Hacker News：curl Patches HTTP/2 Upload Flaw After PoC Demonstrates Client-Side Code Execution

この記事のポイント

影響のあるシステム

• curlおよびlibcurlのバージョン8.12.0から8.22.0まで
• Debian 13（trixie）の修正前パッケージ（DSA-6558-1適用前の8.14.1-2+deb13u7未満）

推奨される対策

• curlおよびlibcurlを修正済みのバージョン8.23.0へアップデートする
• 各サポート系統で公開されている修正版（8.20.2、8.16.2、8.14.3など）またはDebianセキュリティ更新を適用する
• 即座に更新できない環境では、コマンドラインで「–http1.1」を指定するか、CURLOPT_HTTP_VERSIONでCURL_HTTP_VERSION_1_1を設定してHTTP/2の利用を停止する
• libcurlをHTTP/2サポート無効で再コンパイルし、影響を受ける通信経路を遮断する

HTTP/2アップロード処理に潜む解放後使用の不具合と影響範囲

curlプロジェクトは2026年10月14日、データ転送ツールcurlおよび中核ライブラリであるlibcurlに存在する解放後使用の脆弱性（CVE-2026-92392）に関するセキュリティ情報を公開しました。この問題は2025年2月にリリースされたバージョン8.12.0で混入し、8.22.0までのバージョンに影響します。curlプロジェクト独自の4段階評価において、本件は高深刻度（High）と位置付けられています。これは2023年10月のSOCKS5に関する不具合以来の高深刻度分類であり、プロジェクトは通常の8週間のリリース周期を2週間短縮して対応を行いました。

本脆弱性は、クライアントがHTTP/2を使用して攻撃者の管理下にあるサーバーへ約135KBのファイルをアップロードする際に顕在化します。libcurlでは 8.23.0では合計24件の脆弱性が修正されており、残りの23件は低深刻度（Low）とされています。

参考：curl project「curl – HTTP/2 upload Use-After-Free – CVE-2026-92392」

悪意あるサーバーによるコード実行の成立要件と攻撃の制約

この不具合は、サーバーからHTTP/2のRST_STREAMフレーム（HTTP_1_1_REQUIREDまたはREFUSED_STREAM）を受信した際の処理に起因します。サーバー側がウィンドウサイズをゼロにして通信を遅延させた後、ストリームをリセットすると、curlは通信の再試行を試みます。そのクリーンアップ処理において、内部オブジェクトであるstruct Curl_easyの解放タイミングに不整合が生じ、古い接続側で解放済みメモリへのポインタが保持され続ける状態が発生します。

実証環境では、サーバーから送信されたデータが解放済みメモリ領域に配置され、関数ポインタを上書きすることで遠隔コード実行へつなげられることが確認されています。ただし、攻撃の成立には厳格な条件を満たす必要があります。

• 稼働しているcurlの正確なバージョン、構造体配置、CPUアーキテクチャが特定されていること
• libcアロケータのビルド形式やヒープ配置、TLS 1.3およびnghttp2のメモリ挙動が一致していること
• 並行して実行される2つの転送処理のタイミングが精密に制御されていること
• 攻撃ペイロードが約23バイトという短いコマンド制約に収まっていること

curlプロジェクトの開発責任者であるDaniel Stenberg氏は、これらの前提条件が極めて厳格であるため、実際の攻撃では成功確率が低く、大半はクライアントの異常終了（クラッシュ）で終わると説明しています。この攻撃難度の高さが、最高深刻度のCriticalではなくHighに分類された理由となっています。

参考：curl project「curl – HTTP/2 upload Use-After-Free – CVE-2026-92392」

提供されている修正バージョンと一時的な回避手順

不具合の修正は、Stefan Eissing氏によってlib/multi.c内の処理順序を見直す形で行われました。残余データをフラッシュした後にハンドルへの参照を適切に破棄するように変更されています。利用者に対しては、最新のcurl 8.23.0への更新、またはローカルビルドへの修正コミット適用が案内されています。また、過去の系統向けには8.20.2、8.16.2、8.14.3といった修正版が提供されており、LinuxディストリビューションでもDebian 13向けにDSA-6558-1による修正パッケージが配布されています。

システム環境の都合などにより直ちにバージョンアップが実施できない場合には、HTTP/2プロトコルを使用しない運用へ切り替える回避策が推奨されています。curlコマンドラインツールを利用している場合はオプション「–http1.1」を明示的に付与し、独自アプリケーションでlibcurlを組み込んでいる場合はCURLOPT_HTTP_VERSIONをCURL_HTTP_VERSION_1_1に設定します。また、libcurlをコンパイルする段階でHTTP/2サポートを無効化しておくことでも、脆弱性が存在する通信経路への到達を防ぐことが可能です。

参考：curl project「curl – HTTP/2 upload Use-After-Free – CVE-2026-92392」、curl project「CURLOPT_HTTP_VERSION」

参考文献・記事一覧

• The Hacker News「curl Patches HTTP/2 Upload Flaw After PoC Demonstrates Client-Side Code Execution」
• curl project「curl – HTTP/2 upload Use-After-Free – CVE-2026-92392」
• curl project「curl – How To Use」
• curl project「CURLOPT_HTTP_VERSION」