curlの重大脆弱性CVE-2026-92392：HTTP/2アップロードの影響版と修正手順

HTTP/2は、1つの接続上で複数の通信を扱う仕組みを持つHTTPの版です。curlの公式勧告によると、アップロード中にサーバーから特定理由のRST_STREAMを受けた際の処理で、解放後のCurl_easyオブジェクトを使ってしまいます。RST_STREAMは通信の流れをリセットするための通知です。公式セキュリティ勧告

Use-After-Freeは、不要として解放したメモリーを、まだ有効なものとして扱う不具合です。その領域が別用途に使われると、想定外のデータを参照するなどの問題が起き得ます。今回は単にアップロードに失敗する可能性だけを考えればよい問題ではありません。

公式勧告は、悪意あるサーバーが複数の厳しい条件を満たした場合、リモートコード実行（RCE）へつなげられることが実証されたとしています。実行側の版・構造、CPUアーキテクチャ、メモリー割り当て、TLSの挙動、並行転送のタイミングなどの条件が挙げられています。ここでは攻撃の再現方法ではなく、影響の判断と修正に焦点を当てます。

これは「脆弱なcurlへ通信すれば、どの環境でも必ず乗っ取れる」という意味ではありません。一方、成立条件が複雑だから更新不要とも言えません。本記事では、実際の攻撃での悪用の有無を確認できていません。成立を実証したことと、実被害の観測は区別します。

版は数値の構造とブランチで比較します。例えば8.20.2は8.23.0より数字が小さくても、この勧告では修正済みの例外です。OSや製品に付属するlibcurlは、提供元の修正版パッケージまたは製品更新を使います。OS管理下のライブラリを別のファイルで上書きする手順は取りません。

先頭の出力はPATHで選ばれるcurlの場所、次はその実行ファイルの版や機能です。出力にHTTP2があるかも確認します。ただしHTTP2対応のビルドであることと、その業務が実際にHTTP/2アップロードを行うことは別です。また、この結果だけで同じ端末のすべてのアプリを検査したことにはなりません。

libcurlの実行版を自社コードから確認する場合は、公式のバージョン情報APIも参考になります。ビルド時のヘッダーの版だけを見ず、実際にリンク・ロードされるライブラリを確認してください。

• HTTP/2を有効にしたビルド・実行経路か。
• アップロードを行う処理か。フォーム、ファイル送信、APIへのデータ送信などの実装を確認する。
• 接続先やリダイレクト先を外部入力で指定できるか。許可済みの接続先であっても信頼境界を確認する。
• アプリがどの権限で動き、どの情報へアクセスできるか。影響の大きさを判断する。

「Webページを表示するだけのサービス」といった業務名では判断できません。内部で別サービスへアップロードする機能がある場合もあります。呼び出し箇所や設定の証拠が取れない対象は、未確認として担当者に割り当てます。

1. 1配布元と実行版を特定し、8.23.0、公式の修正済み保守版、または修正を含む配布元パッケージを選ぶ。
2. 2検証環境で更新し、アップロードと接続先の互換性、エラー処理を確認する。
3. 3本番へ反映し、必要なサービス再起動・再デプロイを行う。稼働プロセスが古いlibcurlを保持していないか確認する。
4. 4同じ版確認を稼働環境で行い、転送失敗率・時間・エラーを確認する。
5. 5未確認の製品や更新待ちの資産を台帳に残す。完了した資産と混ぜない。

公式の選択肢は、修正版への更新、修正パッチの適用、HTTP/2を使わないことです。すぐ更新できない場合のHTTP/2無効化は暫定策として管理します。CLIでは対象の呼び出しに--http1.1を指定する方法がありますが、他のコマンドや組み込みlibcurlへは自動的に広がりません。アプリ側の設定と実際の通信を確認します。

HTTP/2を止めると接続先との互換性や性能が変わる場合があります。業務が成功することと、問題のあるHTTP/2経路を使わなくなったことの両方を確認します。回避策を入れたという理由だけで恒久修正を完了扱いにしません。

公式勧告の影響範囲、修正済み版、回避策を確認しました。掲載コマンドはローカルの場所・版を表示する例です。読者の環境への影響判定、脆弱性の攻撃再現、RCEの追試、製品ごとの更新確認は実施していません。LLM用の指示例も、事故防止効果を実測したものではありません。

出典：curl公式勧告（2026年10月14日）、curlコマンドのマニュアル、curl_version_info。一般の進め方は脆弱性の影響判断と修正確認を参照してください。