curlに四半世紀前からの脆弱性｜CVE-2026-8932の中身と8.21.0での修正点

2026年7月、curl プロジェクトは CVE-2026-8932 に対処した curl 8.21.0 をリリースしました。CVSSv3 スコアは 8.1（High）で、リダイレクト追跡時の URL スキーム正規化処理に起因するサーバーサイドリクエストフォージェリ（SSRF）に近い挙動を引き起こす可能性があります。開発チームが修正作業の過程でコードの起源を追ったところ、問題の根は 2001年ごろに書かれたマルチプロトコル対応コードにあることが確認されました。「四半世紀前からの脆弱性」という表現が広まっていますが、より正確には当時の設計判断が後年の機能追加と組み合わさって顕在化した脆弱性です。本記事では、この脆弱性の背景・仕組み・影響範囲・8.21.0 での修正内容・自環境での確認と更新手順を順に整理します。

「四半世紀前のコード」という異例の背景

curl は 1997年に初版がリリースされたコマンドラインツールです。2001年ごろにはすでに HTTP・HTTPS・FTP・FTPS・LDAP など複数のプロトコルに対応しており、その実現のためにゼロから設計された URL パーサーとスキーム識別ロジックが当時のコードベースに書かれました。

このスキーム識別ロジックは当時の前提に基づいて設計されており、スキーム名はそのまま文字列比較すれば十分でした。その後 20年以上にわたって curl は対応プロトコルを増やし続け、URL のパーセントエンコーディングを処理する機能も複数箇所に分散する形で追加されてきました。この「段階的デコード処理」と「旧来の文字列比較ロジック」が予期せぬ形で組み合わさることで、特定の条件下でスキーム検証をすり抜けられる経路が生じていたのが今回の脆弱性の本質です。

curl のコードは長年にわたって多くの目に触れてきたオープンソースプロジェクトです。それでも 25年間発見されなかった理由は、通常の HTTP → HTTP リダイレクトには影響せず、パーセントエンコードされたスキームを含む特殊な Location ヘッダーへの応答という、ごく稀な条件でのみ顕在化するためと説明されています。現場でこの条件が自然発生することはまずなく、攻撃者が意図的に細工した応答を返す状況に限られます。

脆弱性の仕組み――URL スキーム正規化のすり抜け

CVE-2026-8932 の攻撃経路を具体的に見ていきます。libcurl がリダイレクト（HTTP 3xx）を追跡するとき、新しい Location ヘッダーの URL を正規化してからスキームの変更可否を判定します。このとき、攻撃者が制御するサーバーが次のような応答を返すとします。

HTTP/1.1 302 Found
Location: f%74p://internal.example.local/config

f%74p はパーセントデコードすると ftp になりますが、修正前の libcurl はデコード前の文字列を使ってスキームの比較を行うため、「ftp への変更」を検知できませんでした。その結果、curl はユーザーの意図しない形で内部ネットワーク上の FTP サーバーへ接続しようとします。

内部に FTP や LDAP サーバーが稼働している環境では、外部からのリクエストを引き金に内部サービスへのアクセスが発生するため、SSRF と同質の脅威になります。ただし攻撃者は MitM（中間者）の位置か、curl の接続先として信頼されたサーバーを制御できる状況にある必要があります。インターネット越しに一方的に悪用できる性質ではなく、CVSS の攻撃複雑度（AC）が「高」と評価されている理由もここにあります。

影響を受けるバージョンと CVSS スコアの詳細

公式アドバイザリによると、curl 7.1（1998年リリース）から curl 8.20.x までのすべてのバージョンが影響を受けます。実質的に curl の全歴史にわたる範囲であり、libcurl を動的・静的にリンクしたアプリケーションも同様の影響を受けます。CVSSv3.1 のベーススコア 8.1 を構成する各指標は次のとおりです。

• 攻撃経路（AV）：ネットワーク――リモートから到達可能
• 攻撃の複雑さ（AC）：高――MitM 位置またはサーバー制御が必要
• 必要な権限（PR）：不要
• ユーザー操作（UI）：不要――curl が自動でリダイレクトを追跡する場合
• 影響の範囲（S）：変更あり――内部サービスへの波及が可能
• 機密性（C）：高――内部リソースへのアクセスで情報漏洩の可能性
• 完全性（I）：低
• 可用性（A）：なし

攻撃の複雑さが「高」のため、スコアは 9点台には達していません。とはいえ、CI/CD パイプラインや API ゲートウェイなど、外部エンドポイントへのリダイレクトを自動追跡する構成では現実的なリスクになり得ます。「自分たちには関係ない」と判断する前に、リダイレクト追跡を有効にしたまま外部 API を呼び出しているジョブがないかを確認することを推奨します。

curl 8.21.0 での修正内容

curl 8.21.0 における修正は大きく 2点です。

1. リダイレクト先 URL のスキーム検証をデコード後に実施。従来はパーセントエンコードされた状態の文字列でスキームを比較していた箇所を、URL デコードと小文字正規化を施したあとに比較するよう修正されました。この変更は libcurl 内部の curl_url_set() のリダイレクト追跡パスに適用されています。

2. --proto-redir のデフォルト値の厳格化。以前は未指定の場合にすべてのプロトコル変更を暗黙的に許可していましたが、8.21.0 からはデフォルトで HTTP → HTTPS への変更のみを許可し、それ以外のスキーム変更はブロックされます。FTP や LDAP へのリダイレクト追跡を意図的に行っているスクリプトでは、--proto-redir +ftp のように明示的なオプション追加が必要になります。

このデフォルト変更は後方互換性を一部破る可能性があります。自動化スクリプトやアプリケーションが curl のリダイレクト追跡に依存している場合は、本番環境への適用前に動作確認を行うことが不可欠です。

自環境の確認と更新手順

まず現在インストールされている curl のバージョンを確認します。

curl --version | head -1

出力に curl 8.21.0 以降が表示されていれば修正済みです。8.20.x 以前であれば更新が必要です。libcurl を使用するアプリケーションは、動的リンクしているライブラリのバージョンも別途確認してください。

ldconfig -p | grep libcurl

Ubuntu 24.04 / Debian 12 では、セキュリティリポジトリ経由でバックポートパッケージが提供されています。

sudo apt-get update && sudo apt-get install --only-upgrade curl libcurl4

RHEL 9 / Rocky Linux 9 / AlmaLinux 9 では RHSA アドバイザリが発行されており、dnf で更新できます。

sudo dnf update curl libcurl

Alpine Linux（コンテナ環境で多用）は次のコマンドで更新できますが、ビルド済みコンテナイメージは古い libcurl を内包したまま稼働し続ける点に注意が必要です。ベースイメージのリビルドと再デプロイをセットで実施してください。

apk upgrade curl

更新後は再度 curl --version でバージョンを確認し、出力中の libcurl バージョン番号も 8.21.0 以降になっていることを確かめます。CLI の curl と libcurl はパッケージが分離しているディストリビューションもあるため、両方のバージョンを目視で確認する習慣を持つことが運用上有用です。

2026 年の現行環境で押さえておきたい注意点

コンテナイメージの棚卸し。Kubernetes クラスターに展開済みのイメージには、修正前の libcurl が含まれている可能性があります。Trivy や Grype などのイメージスキャナーが CVE-2026-8932 の検出シグネチャを提供し次第、CI/CD パイプラインに組み込んでレジストリ内の既存イメージを再スキャンすることを推奨します。稼働中のワークロードをスキャンするだけでなく、ベースイメージを固定しているリポジトリのロックファイルも見直してください。

静的リンクバイナリの個別確認。OS パッケージとして管理されている libcurl を更新すれば動的リンクのケースは解消されますが、libcurl を静的リンクしたバイナリ（一部の組み込み環境向けツールや社内配布 CLI）は個別の再ビルドが必要です。社内に配布しているカスタムバイナリがある場合は、ビルドスクリプトで参照している libcurl のバージョンを確認してください。

--proto-redir デフォルト変更の影響確認。8.21.0 へのアップデート後、HTTP → FTP などのプロトコル間リダイレクトを自動追跡していたスクリプトは動作が変わります。バックアップ取得やデータ転送のジョブで curl の -L オプションを使っている場合は、ステージング環境で事前に動作確認を行ってから本番へ適用するフローを取ることが望ましいです。

エグレスフィルタリングとの組み合わせ。本脆弱性に対する根本対処は curl の更新ですが、アウトバウンドの HTTP リクエストをプロキシ経由に集約し、許可されたホストのみへのアクセスに限定する設計を取り入れている環境では、仮に古い curl が残存していても内部サービスへの誘導を抑止する多層防御が機能します。curl の更新と並行して、アーキテクチャ側の対策の見直しも検討に値します。