curl、クライアント側でのコード実行を可能にする高深刻度のHTTP/2アップロード欠陥を修正

curlプロジェクトは10月14日にバージョン8.23.0をリリースし、HTTP/2アップロード中に悪意のあるサーバーがクライアントメモリを破損させることを可能にする高深刻度の脆弱性を修正しました。CVE-2026-92392として追跡されているこの欠陥は、AnthropicのLuna Tong氏によって発見され、8.12.0から8.22.0までのすべてのcurlおよびlibcurlのバージョンに影響を与えます。

何が起きたか

この脆弱性は、攻撃者が制御するサーバーが、データをアップロードしているクライアントマシン上でリモートコード実行を引き起こすことを可能にします。攻撃には、標準的な検証チェックを通過する証明書を持つ悪意のあるサーバーに対して、約135KBのファイルをHTTP/2経由でアップロードする必要があります。理論上の影響には完全なシステム侵害が含まれますが、curlのメンテナーは、実際のシナリオでは成功したエクスプロイトは困難であり、多くの場合、コード実行ではなくクラッシュにつながると指摘しています。

このバグは、2025年2月にリリースされたバージョン8.12.0以降のすべてのcurlリリースに存在していました。これは2023年10月のSOCKS5ヒープオーバーフロー以来、プロジェクトにとって初めての高深刻度欠陥です。発見への対応として、curlチームは通常8週間のリリースサイクルを2週間短縮し、迅速にパッチを提供しました。現時点では、この脆弱性を利用した活発なエクスプロイトは報告されていません。

今回のリリースでは合計24件のCVEに対応していますが、他の23件は低深刻度と評価されています。プロジェクトはまた、Rock-solid curlリリースとして知られる長期サポートラインを更新し、このセキュリティパッチに合わせています。古いサポートブランチを使用しているユーザーは、特定の修正済みバージョンにアップグレードする必要があります：8.14.xブランチでは8.14.3、8.16.xでは8.16.2、8.20.xでは8.20.2です。

仕組み

この脆弱性は、libcurlがHTTP/2転送を管理する方法に根ざしたuse-after-freeエラーです。HTTP/2では単一の接続上で複数の同時ストリームが可能であり、libcurlはeasy handleと呼ばれるオブジェクトを使用して各転送を追跡します。アップロード中、悪意のあるサーバーはHTTP/2ウィンドウサイズをゼロに設定し、レスポンスの一部を返してから、基盤となる接続を開いたままストリームをリセットすることで、転送を停滞させることができます。Curlはこのリセットを転送のリトライ信号として解釈します。

このリトライロジックのクリーンアップフェーズにおいて、curlは以前、残りの未送信アップロードデータをフラッシュする前に、HTTP/2層に対して転送が完了したことを通知していました。この順序により、残ったバイトは登録された転送がない接続に書き込まれました。これらのバイトがHTTPリクエスト行に似ている場合、curlは新しいストリームを開き、easy handleへのポインタを保存します。アプリケーションが最終的に新しいHTTP/1.1接続でのリトライ完了後にハンドルを解放すると、古い接続はまだその解放されたメモリへのダングリングポインタを保持していました。

攻撃者はその後、最近解放されたメモリ空間に着地する古いストリーム上のデータを送信できます。アドレス空間レイアウトランダム化（ASLR）を回避するためにローカルアドレスを漏洩させることで、攻撃者はそのメモリ内の関数ポインタを上書きできます。curlがその後そのポインタを呼び出すと、攻撃者のコードが実行されます。Stefan Eissingによるlib/multi.c内の6行の並べ替えという修正は、残りのデータがフラッシュされた後にのみ、HTTP/2層がハンドルへの参照を解放するように保証します。

主要な詳細

• 影響を受けるバージョン: curlおよびlibcurl 8.12.0から8.22.0。
• 修正済みバージョン: 8.23.0へアップグレードするか、古いブランチの場合は8.14.3、8.16.2、8.20.2へアップグレードしてください。
• 攻撃ベクトル: 約135KBのHTTP/2アップロードを受信する悪意のあるサーバー。
• 深刻度: curlプロジェクトによりHighと評価；CVSSスコアは公開されていません。
• 発見: Luna Tong氏（Anthropic）により9月15日にHackerOneを通じて報告されました。
• 緩和策: 即時のパッチ適用が不可能な場合は、--http1.1またはCURLOPT_HTTP_VERSION_1_1を使用してHTTP/2を無効にしてください。

なぜ重要なのか

ソフトウェアエンジニアやDevOpsチームにとって、この事件は広く使用されているインフラライブラリに伴うリスクを浮き彫りにします。Curlはコマンドラインスクリプトから複雑なバックエンドサービスまで、無数のアプリケーションに組み込まれています。libcurlはデフォルトでHTTPS URLに対してHTTP/2をネゴシエートするため（サーバーがサポートしている場合）、明示的な構成変更を行わなくても多くのアプリケーションが脆弱である可能性があります。脆弱性のエクスプロイトには特定のビルド環境と正確なタイミングが必要という事実も、特に既知のインフラに対する標的型攻撃の場合、リスクを否定するものではありません。

発見プロセスはまた、オープンソースセキュリティ脆弱性がどのように見つかるかの変化を示唆しています。報告者は、人間のレビューなしで結果をメールするAI駆動ツールであるAnthropicのOSS Scannerを使用しました。これは、AIモデルが従来のファジングで見逃される可能性のある複雑なメモリ破損バグを識別できるようになるにつれ、脆弱性研究の将来について疑問を投げかけます。しかし、メンテナーが低品質なAI生成レポートの増加を指摘しているように、ノイズも生じさせます。

あなたができること

• curl --versionを実行して現在のcurlバージョンを確認し、直ちに8.23.0または修正済みブランチバージョンへアップグレードしてください。
• すぐに更新できない場合は、CURLOPT_HTTP_VERSIONをCURL_HTTP_VERSION_1_1に設定して、アプリケーションでHTTP/1.1を強制してください。
• libcurlビルドにHTTP/2サポートが含まれているかどうかを確認してください。含まれていない場合、この特定の欠陥に対して脆弱ではありません。
• Debian 13 (trixie) を使用している場合は、Debianセキュリティトラッカーを監視してください。DSA-6558-1を通じてパッチ8.14.1-2+deb13u7を受け取りました。
• ファイル転送のために古いバージョンのcurlをバンドルしているカスタムDockerコンテナやCI/CDパイプラインを見直してください。
• 厳密に必要でない内部サービスではHTTP/2を無効にして、攻撃面を削減することを検討してください。