curlプロジェクトは2026年10月14日、curl 8.23.0をリリースしました。同じ日に24件のCVEが公開されており、うち1件のCVE-2026-92392は、HTTP/2でアップロード中に起きる解放後使用（Use-After-Free）で、深刻度はHighです。悪意のあるサーバーが特定の条件をすべてそろえた場合に、リモートコード実行につながりうる、とアドバイザリは説明しています。影響を受けるのはcurl 8.12.0〜8.22.0（コマンドラインツールを含む）で、対処は8.23.0への更新です。
この記事の目次
HTTP/2のRST_STREAMで、アップロード中に解放後使用が起きる
アドバイザリによると、アップロードの最中にサーバーからHTTP/2のRST_STREAM（理由が HTTP_1_1_REQUIRED または REFUSED_STREAM）を受け取ると、curlがこれを誤って処理し、内部の Curl_easy 構造体で解放後使用が発生します。CWEは416、深刻度はHigh。curlは、この問題を「Cを使っていなければ避けられた可能性が高いミス」としています。
注目したいのは「リモートコード実行に変換できると実証された」という点です。ただし、それには悪意のあるサーバー側で多くの前提が必要だと、アドバイザリは並べています。たとえば、使われているcurlのバージョンと構造体の配置が分かっていて攻撃用のオフセットを計算できること、アーキテクチャの詳細、互換性のあるlibcのアロケータとヒープの配置、nghttp2やOpenSSL（TLS 1.3）の挙動、固定されたCAバンドル、被害側で並行して走る2つの転送のタイミングが合っていること、libcのリークとシンボルのオフセットなどです。また、現時点で実証されたエクスプロイトは、実行できるコマンドが約23バイトまでという制約つきだとされています。「誰でもすぐに悪用できる」という書き方ではありません。ただ、サーバーが攻撃者の側にある状況（悪意のあるサイトへのアップロードや、リダイレクト先の誘導など）を想定すると、軽く見てよい話でもありません。
どのバージョンが対象か、どう直すか
アドバイザリが示す対象範囲は次のとおりです。
- 影響あり：curl 8.12.0〜8.22.0（libcurlを組み込んだアプリと、コマンドラインのcurlの両方）
- 影響なし：8.12.0より前、および8.23.0以降
- アドバイザリには、8.20.x系は8.20.2以降、8.16.x系は8.16.2以降、8.14.x系は8.14.3以降も影響なしと書かれています（今回確認したcurlのリリース一覧（Changes）には、これらの版は見当たりませんでした。ディストリビューションなどが修正を取り込んだ版を指している可能性があります）
推奨される対処は3つ挙げられています。A. curl 8.23.0へ更新する。B. 手元のバージョンにパッチを当てる。C. HTTP/2を使わない。Cは、更新できない環境での一時的な回避策になります。アドバイザリには、libcurlは多くのアプリに使われているが、そのことが明記されているとは限らない、とも書かれています。自分で入れたcurlだけでなく、使っているツールやコンテナイメージが内部でlibcurlを使っていないかも、棚卸しの対象になります。
まず curl --version で手元のバージョンを確かめ、8.12.0〜8.22.0なら更新を計画するのが先です。アドバイザリによると、この問題は2026年9月15日にcurlへ報告され、修正はStefan Eissing氏によるものです。報告者の欄には「Luna with Claude, Anthropic」と記載されています。
同じ日に出た「ほかの23件」は、いずれも深刻度Low
curlの脆弱性一覧（CVE一覧）では、2026年10月14日の公開分は24件で、High以外の23件の深刻度はすべてLowです。ここでは一覧のタイトルをもとに、Web開発者に関係しそうなものを拾います。
- CURLINFO_EFFECTIVE_URLでのパスワード漏えい（CVE-2026-94266。対象は7.62.0〜8.22.0）
- Authorization: Negotiateが別のオリジンに送られる（CVE-2026-94265。対象は8.21.0〜8.22.0）。同じ版の範囲には、Negotiateの認証情報がリダイレクト先へ送られる問題（CVE-2026-86413）や、Negotiate接続が別オリジンで再利用される問題（CVE-2026-87861）もあります
- HTTPプロキシへのホスト認証情報の漏えい（CVE-2026-86414）
- SFTP・SCPへのリダイレクトでホスト検証が回避される（CVE-2026-86410。ツール側）
- サーバーが設定したCookieによる、Cookie jarの読み込み中断や消去（CVE-2026-92386、CVE-2026-86412）
- HSTSキャッシュの取り込み・更新まわりの問題（CVE-2026-87862、CVE-2026-87863）
どれも深刻度はLowですが、認証情報やCookieなど、アプリの秘密を扱う部分に集中しています。詳しい条件は、各CVEのアドバイザリで確認してください。
SMB対応の廃止と、保存ファイル名の変更
脆弱性以外の変更点（curl 8.23.0のChanges）には、SMBのサポートを廃止する項目が含まれています。ツール側では、保存先の上書きを避けるno-clobberの番号を拡張子の前に入れるように変わり、重複するときは .9999 まで試すようになりました。なお、-J（サーバー指定のファイル名で保存）とno-clobberの組み合わせでは、103 Early Hintsを使うと保証を回避できる問題（CVE-2026-92390。深刻度はLow）もあわせて修正されています。SMBでcurlを使っている環境があれば、更新の前に影響を確認しておく必要があります。バグ修正は、Cookie、HSTS、接続の再利用など多岐にわたります。
HTTP/2のアップロード先が信頼できるかで、優先度が変わる
今回の件は、「HTTP/2でアップロードするコードがあるか、信頼できないサーバーへつなぐか」で優先度が決まります。さらにRCEの前提には「2つの並列転送」があるため、-Z やmulti interfaceで並列にアップロードする構成ほど、前提に近づきます。サーバーが自社の管理下にあり、アップロード先も固定なら、緊急度は下がります。一方、利用者が指定したURLへ（Webhookの送信、外部サービスへのファイルの転送など、POSTやPUTで送る処理）サーバー側からcurlでアクセスする仕組みでは、相手が悪意を持ちうるので、更新を急ぐべきです。更新できるまでの間は、アドバイザリのCにあるとおり、HTTP/2を無効にするのが現実的な回避策になります。
見落としやすいのは、curl --version で分かるのがコマンドラインのcurlだけだという点です。PHPのcurl拡張やpycurlが使うlibcurlは、実行環境ごとに確かめる必要があります（たとえばPHPなら php -r 'echo curl_version()["version"];'）。また、ディストリビューションは版番号を据え置いたまま修正を取り込むことがあるため、番号だけで判断せず、提供元の情報も確認しておきたいところです。
また、Low判定の23件は、個別には小さく見えますが、認証情報やCookieを扱う部分が多く、バージョンをまとめて上げるほうが管理は楽です。8.23.0へ上げれば、24件がまとめて解消します（うち3件は影響の最終版が8.21.0なので、8.22.0を使っている人にとっては21件です）。
出典
- CVE-2026-92392: HTTP/2 upload Use-After-Free（curl Security Advisory、2026年10月14日）
- curl CVEs（curl公式の脆弱性一覧）
- Fixed in 8.23.0 – October 14 2026（curl Changes）
- データ転送ライブラリ「curl」に特定の条件でリモートからコードを実行される脆弱性（窓の杜、2026年10月15日）
2026年10月19日時点の情報です。
