Skip to content
Published on

curl 8.21.0のCVE18件 — バグバウンティ廃止のあとに来た「高品質カオス」

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに — 1リリースでCVE18件

2026年6月24日、curl 8.21.0がリリースされました。Daniel Stenbergがリリースごとに付ける統計は今回も変わらず添えられていますが、その中の一行が目に刺さります。275回目のリリース、56日周期、コミット531件、バグ修正276件、新機能6件——そしてセキュリティ修正18件。

1リリースでCVE18件は、curlプロジェクト史上最多です。2026年の年間発行数としてもすでに記録です。この数字だけ切り取れば「curlに何が起きたのか」と思いますが、18件を分解すると話は変わります。Medium 4件、Low 14件。HighもCriticalもありません。curl最後のHigh等級CVEは、2023年10月のCVE-2023-38545(SOCKS5ヒープオーバーフロー)がいまだに最後です。

つまりこのリリースの本当の話は「curlが危険になった」ではありません。セキュリティ報告のエコシステムが今年構造的に変わり、curlはその最前線にいる、ということです。本稿はその過程を——スロップの時代、バグバウンティ廃止、GitHub移行の失敗、そしてStenbergが「High-Quality Chaos(高品質カオス)」と呼ぶ現在まで——一次資料で追いかけ、実務で何が変わるのかを整理します。

まず数字を検算する — curlの2026年上半期

curlは自身の脆弱性履歴全体を機械可読データ(vuln.json)として公開しています。ブログの主張をそのまま書き写す代わりに、このファイルを自分で数えてみました。発行日ベースの年別CVE件数はこうなります。

年発行CVE数
20206
202113
202221
202318
202411
20259
2026年(6月24日まで)36

2026年のリリース別に見ると、1月7日(8.18.0)に6件、3月11日(8.19.0)に4件、4月29日(8.20.0)に8件、6月24日(8.21.0)に18件。合計36件で、上半期が終わる前に、これまでの最多年だった2022年(21件)をすでに上回っています。単一発行日ベースでも今回の18件が最多で、これまでの記録は2016年11月2日の11件でした。ブログの「記録」という主張は、データと正確に一致します。

一つ注意点があります。これは「curlのコードが急に悪くなった」のグラフではなく、「発見のペースが変わった」のグラフです。その区別が、この記事全体のテーマです。

ここまでの経緯 — スロップの時代とバグバウンティの終わり

タイムラインを押さえてこそ、今の状況が読めます。すべてStenberg本人の記録です。

  • 2019年4月 — HackerOneでcurlバグバウンティ開始。廃止までの累計で確定した脆弱性87件、研究者への報酬支払い総額10万ドル超。
  • 2024年1月 — "The I in LLM stands for intelligence"。LLMがでっち上げた脆弱性報告が公に議論され始める。
  • 2025年7月 — "Death by a thousand slops"。スロップが急増。例年15%を超えていた報告確認率(提出数に対する実際の脆弱性の割合)が、2025年に入り5%を割り込む——20件に1件も本物ではなくなる。
  • 2026年1月26日 — バグバウンティ終了の発表。1月31日付で報酬を全面廃止。「でっち上げた嘘を提出する動機をなくすため」という理由で、報告チャネルもHackerOneからGitHubの非公開脆弱性報告(Private Vulnerability Reporting)へ移行。
  • 2026年2月25日 — わずか1か月でHackerOne復帰を発表。報酬は引き続きなしだが、プラットフォームは3月1日から再びHackerOneに。

GitHub移行がなぜ失敗したかも記録に残しており、このリストは脆弱性受付システムを検討するチームならそのままチェックリストとして使えます。報告全文が通知メールに平文で送られるのを止められない(早期流出のリスク)、無効判定された報告を公開状態に切り替える方法がない(curlは誤った報告も含めて全部公開するのを原則としています)、curlは自前のCNAなのでCVE番号を自ら発行するがGitHubフォームのCVE欄は編集できない、スロップの統計を取るためのラベル機能もない。Stenbergの結論は「バウンティなしでまともな脆弱性受付をしようとするオープンソースプロジェクトのためのツールは、総じて貧弱だ」というものでした。

「High-Quality Chaos」 — スロップではなく本物が押し寄せる

バウンティをなくしたので報告は減ったのでしょうか。正反対のことが起きました。その数字は4月の「High-Quality Chaos」と5月の「The pressure」にあります。

  • スロップはもう問題ではなくなりました。代わりに報告頻度が2024年の4〜5倍、すでに倍になっていた2025年のさらに2倍——平均で1日1件以上。
  • 確認率はAI以前の水準(15〜16%台)に戻り、むしろ上回っています。脆弱性ではないが実際のバグである報告の割合も、以前よりずっと高くなりました。
  • そしてほぼすべての報告にAIを使った痕跡があります。文体で、構成で、そして人間が書いたのでは出せない水準まで精巧な重複報告が同時に届くことでわかる、とのことです。

つまり、2025年の問題が「AIがでっち上げた偽物」だったとすれば、2026年3月以降の問題はAIで武装した研究者たちが、人間には処理しきれない速度で本物のバグを見つけ出すことです。Stenbergは4月時点で「このペースなら今年CVE50件に近づくかもしれない」と見通しを語りましたが、6月24日時点ですでに36件なので、その見通しどおりに進んでいます。

これがcurl固有の話ではないことも重要です。StenbergがMastodonで行った非公式アンケートに、Apache httpd、BIND、Django、Firefox、git、glibc、GnuTLS、HAProxy、Linuxカーネル、OpenLDAP、Python、Ruby、urllib3、Wireshark、wolfSSLといったプロジェクトが同じ傾向を確認してくれました。あなたの依存関係ツリー全体でCVE発行のペースが上がっていると仮定しておくほうが安全です。

一方、5月には面白い対照例もありました。Anthropicが「セキュリティ欠陥の検出能力が危険なほど優れているため、当面は選別的に公開する」と話題になったモデルMythosが、Linux Foundation経由でcurlをスキャンしたところ、結果は確定した脆弱性わずか1件(Low)でした——報告が主張した「確定5件」をセキュリティチームが検証すると、誤検知3件、単なるバグ1件と判明しました。同じ記事でStenbergは、AISLE、Zeropath、OpenAI Codex SecurityといったAI分析ツールが直近8〜10か月ですでにcurlに200〜300件のバグ修正と十数件以上のCVEをもたらしたと明かしています。彼の評価は両義的です。特定モデルの神秘化はマーケティングに近いが、AIコード分析器全般が既存の静的解析器より確実によく見つけるのも事実だ、と。そして核心的な観察が一つ——AIは新しい種類の脆弱性を発明するのではなく、すでに知られている種類の新しいインスタンスをより多く見つけ出すだけです。

18件のCVEは実際に何を直したのか

その観察は8.21.0のCVE一覧でそのまま確認できます。2026年のCVE36件のタイトルをざっと見ると、一つの単語が繰り返されます。reuseです。私の集計では36件中10件のタイトルに"reuse"が入っています——wrong STARTTLS connection reuse、wrong reuse of SMB connection、connection reuse ignores TLS requirement、incomplete mTLS config matching in conn reuseなど。

偶然ではありません。libcurlは送信が終わったコネクションをプールに保持しておき、設定が合致する後続の送信で再利用しますが、「設定が合致する」の判定は、信頼に影響するあらゆる次元——ホスト、ポート、プロトコル、TLSオプション、クライアント証明書、プロキシ、認証状態——を漏れなく比較して初めて安全になります。次元を一つ見落とすたびに、「別のセキュリティ文脈のコネクションを誤って再利用する」バグが一つ生まれます。一件がCVEとして公開されると、AIツールを手にした研究者たちが同じクラスの変種を組織的に掘り始めます。2026年のCVEクラスタは、その採掘の痕跡です。

個別の案件のうち、プロトコル配管の観点から見ておきたいものを挙げるとこうです(深刻度と影響バージョンはcurl自身の公表に基づきます)。

  • CVE-2026-9545 — HTTP/3 early dataの露出(Low)。 TLSセッションキャッシュとCURLSSLOPT_EARLYDATAを有効にした状態で同じホストに再接続すると、証明書検証の失敗が確定する前に0-RTTでリクエストのバイトが先に出てしまうことがありました。8.11.0(2024年11月)から存在。0-RTTがデフォルトで無効になっている理由——「再送攻撃だけでなく検証順序という罠もある」——を示す教科書的な事例です。
  • CVE-2026-11352 — QUICの長さ0 UDPデータグラムによるbusy-loop(Low)。 受信ヘルパーが長さ0のデータグラムを呼び出しごとのパケット予算に数えずに捨てていたため、悪意あるサーバーが空のデータグラムを流し続けるとクライアントが無期限に固まってしまいました。8.18.0(2026年1月)で入ったリグレッションが6月に見つかったものです。QUICは受信経路がユーザースペースにあるため、こうした予算ロジックの一つ一つがそのまま可用性の境界になるという点は、QUIC受信側のCPUコストの回で扱った通りです。
  • CVE-2026-10536 — HTTP/2ストリーム依存関係ツリーのUAF(Low)。 CURLOPT_STREAM_DEPENDSで依存関係ツリーを作り、curl_easy_reset()後にクリーンアップすると、解放済みの構造体を再び触っていました。7.88.0(2023年2月)から存在。興味深いのは対応の仕方です——8.21.0はこのバグを直すだけにとどまらず、ストリーム依存関係追跡機能をまるごと削除しました。RFC 7540の優先度ツリーは後続の標準ですでに廃止扱いになっているメカニズムなので、ほとんど使われもしない危険な表面を維持するより、取り除いたわけです。
  • CVE-2026-8924 — 末尾ドットのsuper cookie(Low)。 クッキーパーサーのPublic Suffix Listチェックを回避され、悪意あるサーバーが無関係なサードパーティドメインに送信されるクッキーを仕込めました。導入バージョンは7.46.0——2015年12月です。10年以上、ファザーも静的解析器も監査もすべてくぐり抜けて潜伏していたバグが、今回の波で捕まりました。

Medium 4件は、SASLのダブルフリー、プロキシ/クロスオリジンのDigest認証状態漏洩2件、そして長らく存在していたプロキシパスワードの漏洩です。認証状態がコネクションやリダイレクトの境界を越えるという部類で、プロキシを挟んだ構成では実質的な意味があるので、一覧を自分で確認する価値があります。

導入バージョンの分布も注目に値します。2015年のものから今年1月のリグレッションまで混在しています。発見のための道具が良くなると、古い沈殿物と新しいミスがまとめて引っかかってきます。

CVEにならなかったバグ — 初のCNA紛争

CVEが押し寄せる話の反対側に、同じ日に公開された初のCVE紛争の話があります。curlは2024年1月から自前のCNAなので、自分の領域内でCVEを発行するかどうかを自ら決めますが、その決定が初めてMITREにまで持ち込まれた事件です。

バグそのものは実在しました。ワイルドカード証明書のマッチング関数が、https://.example.com/のようにドットで始まるホスト名を*.example.comワイルドカードと誤ってマッチさせてしまう問題で、2025年12月8日に修正されました。ただし、ドットで始まる名前はDNS上は不正なので/etc/hostsのようなローカルの介入なしには到達自体ができず、攻撃者がその該当ワイルドカード証明書まで握っている必要があるなど前提条件が幾重にも重なるため、curlのセキュリティチームはこれを内部用語で「Lowより下」と判定し、CVEを発行しませんでした。報告者はこれを不服としてMITREに紛争を申し立て、MITREは2月、5月、6月の3回にわたって同じ質問を繰り返した末、6月24日に最終判定を下しました——CVE不発行、CNAの判断維持。

このエピソードが重要なのは、判定の結果そのものより、その裏にあるコストの論理です。Stenbergの推算では、libcurlは世界中で数百億台(彼の言葉を借りれば200億から300億台の間)にインストールされており、CVEが一つ発行されるたびに世界中のセキュリティチームのスキャナーが鳴り、パッチと更新作業が連鎖的に発生します。そのコストを払うのはcurlではなくエコシステムです。だからこそ、実際には到達不可能な理論上の問題に警報を鳴らさないことも、CNAの責任だというわけです。CVE36件を発行した年に、CVE一件を発行しないために4か月以上争った――この2つの事実は同じ原則から出てきています。数ではなく、実質的なリスクを基準にする、という原則です。

機能面 — MASQUEプロキシ、named glob、そして削除予告

セキュリティの話に埋もれていますが、8.21.0の新機能6件の中にも配管の観点で骨太なものがあります。公式チェンジログ基準です。

  • HTTP/3プロキシ対応 — CONNECTとMASQUE CONNECT-UDP(ngtcp2 QUICビルド限定)。これまでcurlのプロキシはHTTP/1.1かHTTP/2どまりでしたが、これでプロキシ区間そのものをHTTP/3で通し、その上にUDP(つまりエンドツーエンドのQUIC)をCONNECT-UDPとして運ぶ構成が可能になります。MASQUE系プロキシを、iCloud Private Relayのような大規模展開の外でも試せる道具が一つ増えたことになります。
  • named glob — URLグロブに名前を付けて出力ファイル名から参照するCLIの利便機能で、アップロード側のグロブ参照も含みます。
  • 削除されたもの: HTTP/2ストリーム依存関係追跡(前述)、そしてIE6互換用だったCURLAUTH_DIGEST_IE。

そしてリリースノート末尾の削除予告リストが、実務者にとってはむしろ一番差し迫った部分かもしれません。自前のcrypto実装、NTLM、SMB、TLS-SRPが削除候補に挙がっており、該当機能を使っているなら今すぐcurl-libraryリストで声を上げるよう明記されています。レガシーな認証・プロトコルを取り除いていくこの流れは、OpenSSH 10.4の廃止リストとまったく同じ方向です。NTLMプロキシ認証に頼っている企業内ネットワークの自動化がまだどれだけ多いかを考えると、この予告は静かに読み流していい項目ではありません。

次のリリースは夏季休止のためサイクルを2週間延ばし、9月2日を予定しています。

実務で何が変わるのか

libcurlを直接リンクしていても、ベースイメージのディストリビューションパッケージとして入っているだけでも、この流れがあなたのチームに触れるポイントはおおよそこうです。

スキャナーのノイズが増えます。 年9〜11件だったcurlのCVEが今年36件以上に跳ね上がったので、コンテナイメージのスキャン結果でcurl項目が目に見えて増えます。幸い、curlの公表品質は業界最高水準です——案件ごとの詳細ページに導入コミットから修正バージョンまで明記され、vuln.jsonがOSV互換スキーマで提供されるので、「自分たちのバージョンが実際の影響範囲に入るか」を自動判定するパイプラインを組めます。

深刻度は再評価して使う値です。 curlの等級は「ユーザーがどう使っているかはわからない」という前提に立った、curl視点の等級です。たとえばCURLSSLOPT_EARLYDATAを有効にしたことがなければCVE-2026-9545は無関係ですし、ストリーム依存関係APIを使ったことがなければCVE-2026-10536も無関係です。逆に、プロキシ+認証の組み合わせが多い環境なら、Medium4件は等級以上に真剣に見る必要があります。

パニックには根拠がありません。 近年のcurlの脆弱性がすべてLow/Mediumで、Highは2023年10月が最後だという事実は、桁違いのスクルーティニーを何十年も受けてきたコードベースの実測値です。ただし、その反対方向の教訓も同時に持ち帰るべきです——これだけ徹底的に調べ尽くされたコードでさえ、道具が良くなっただけで半年で36件出ました。スキャン履歴の浅いあなたの社内Cコードなら、はるかに多く出るでしょう。Stenbergの言葉を借りれば、AI分析器を回さないプロジェクトは、攻撃者が同じ道具で先に見つける時間を稼いでやっているようなものです。

メンテナー側のコストも視野に入れてください。 1日1件以上のセキュリティ報告を検証・修正・公表する作業は、現在ごく少数の人が担っており、Stenbergは5月の記事で初めて健康と労働時間への懸念を公に語り、商用利用者に対して支援契約を求めました。この傾向が依存関係全体に広がるとき、各プロジェクトの対応能力はそのままあなたのサプライチェーンリスクになります。この波がファジングのようにいつか停滞期に達するかどうかは、彼自身も「見てみないとわからない」としか言っていません。

おわりに

まとめるとこうです。curl 8.21.0のCVE18件は、コードが悪くなったという合図ではなく、2026年3月以降にセキュリティ研究のエコシステムがAIで再武装し、発見のペースが構造的に跳ね上がったという合図です。スロップの時代はバグバウンティとともに終わり、今来ているのは本物のバグの洪水です——大半がLowで、古い沈殿物と新しいリグレッションが入り混じり、コネクション再利用のような特定のバグクラスに集中した洪水です。

curlはこの波を記録的な透明性で乗り切りつつあります。案件ごとの詳細な公表、機械可読データ、そしてCVEを作るときと同じ真剣さでCVEを拒否する原則まで。私たちがすべきことはシンプルです。スキャナー結果で増えたcurl項目を、実際の影響範囲を基準にトリアージするパイプラインを備えること、NTLM・SMBのような削除予告リストに自分のワークロードが引っかかっていないか今のうちに確認すること、依存関係全体でCVE発行のペースが上がる時代に合わせてパッチのケイデンスを調整すること。そしてどこかのリリースノートで「セキュリティ修正18件」を見たとき、数字に驚く前に深刻度と前提条件をまず読む習慣——それがこの新しい時代の基本動作です。

参考資料

Discuss on Twitter • View on GitHub