脆弱性報告を抱えきれないcurl、低・中深刻度は公開で対応へ

curlプロジェクトは2026年10月20日、深刻度がLOWまたはMEDIUMと判断される脆弱性の報告を、10月26日からGitHubの公開issueで扱う方針を発表した。HIGHとCRITICALに分類される脆弱性については、従来どおりHackerOneを通じて非公開で対応する。curlの開発を主導するDaniel Stenberg氏は、増え続ける脆弱性報告への対応によって主要メンテナーの負担が限界に近づいていると説明しており、外部の協力者を増やすことで対応作業を分担する狙いがある。脆弱性情報を早期に公開すれば攻撃者に悪用される危険も高まるが、curlは比較的深刻度の低い問題から対応をオープンにし、プロジェクトの持続可能な保守体制を構築しようとしている。

10月26日から脆弱性の深刻度に応じて報告先を変更

新方針では、LOW／MEDIUMに該当する脆弱性の報告先が、curlのGitHubリポジトリに変更される。ただし、報告する問題の深刻度を判断できない研究者は、従来どおりHackerOneを利用できる。HackerOneで受け付けた報告がLOW／MEDIUMと判定された場合、報告者にはGitHubへの再投稿を求め、HackerOne側の報告は情報提供として扱い、クローズしたうえで公開する方針だ。

Stenberg氏によると、過去数年間に提出された報告の90％以上は、短時間の評価でHIGH未満と判断できたという。ただし、この割合は提出された報告全体に対するものであり、実際に確認された脆弱性の割合や、AIによって生成された報告の比率を示すものではない。具体的な集計期間や報告件数も明らかにされていない。それでも、従来は非公開の窓口で処理していた報告の相当部分を、公開の場に移せる可能性があることを示している。

なお、LOWやMEDIUMはcurlプロジェクトが独自に定める4段階の深刻度分類である。curlは共通脆弱性評価システム（CVSS）による数値評価を採用しておらず、攻撃の難易度、必要な設定、影響を受ける環境などを総合的に判断して深刻度を決めている。LOWには攻撃の成立が極めて難しい問題や、まれな条件が重なった場合にのみ発生する問題が含まれる。一方、MEDIUMはLOWよりも攻撃の成立条件が緩いものの、重大な被害を引き起こすには追加の条件が必要となる問題などを指す。したがって、これらの名称をCVSSのスコア区分にそのまま当てはめることはできない。

修正コードだけでなく、脆弱性の評価や検証も公開へ

今回の変更で重要なのは、単に脆弱性の修正コードを公開するだけでなく、報告内容の評価やセキュリティ勧告の作成まで、外部の開発者が参加できるようにする点だ。従来もLOW／MEDIUMの脆弱性については、通常の公開プルリクエスト（PR）で修正コードを取り込むことが認められていた。ただし、その段階ではセキュリティ上の問題であることを明示せず、限られた担当者が非公開で評価を進める仕組みだった。

curlの従来の脆弱性公開方針と、Stenberg氏が10月20日に発表した新方針を比較すると、変更点は次のようになる。

LOW／MEDIUMへの対応	従来の方針	10月26日からの新方針
報告の受付・評価	HackerOneで受け付け、限られた担当者が非公開で調査	GitHubの公開issueで扱い、外部の参加者も評価や調査に協力
修正コードの公開	通常の公開PRでの修正も可能。ただし、脆弱性であることは明示しない	報告段階から公開し、修正の妥当性や類似する欠陥の有無も共同で検証

この変更はLOW／MEDIUMの脆弱性に限られ、HIGH／CRITICALは引き続き非公開で対応する。従来の方針では、低・中深刻度の脆弱性について修正コードを先に公開する余地を残しつつ、正式なセキュリティ勧告は修正版の公開に合わせていた。新方針では、これまで限られたメンテナーが担当していた報告の評価や原因の調査、修正内容の説明にも、外部からの協力を得られるようにする。

具体的には、脆弱性の報告内容が正しいかどうかの評価、セキュリティ勧告の執筆、問題がどのバージョンで混入したかの特定などを、共同作業の対象として想定している。さらに、修正箇所の周辺に似た欠陥が残っていないかを調べ、修正が実際に有効であることを確認する作業も含まれる。脆弱性への対応には、問題を修正するコードを書くだけでなく、その原因や影響範囲を調査し、利用者に正確な情報を伝える仕事が必要になるからだ。

もっとも、作業を公開したからといって、脆弱性1件当たりに必要な仕事が減るわけではない。Stenberg氏も、公開の場で対応するようになっても、受け取った報告ごとの作業量そのものは変わらないと認めている。今回の変更で期待しているのは、対応できる人を増やして主要メンテナーへの負担集中を緩和するとともに、議論や調査の過程を公開することで、ほかの参加者も知見を共有できるようにする効果だ。

Stenberg氏は、修正版とCVE情報が公開された後、AIを活用する研究者が同様の欠陥や修正漏れを探し、新たな報告を提出する傾向にも言及している。curlは、こうした追加検証をリリース前の公開作業に取り込むことで、後から同種の報告への対応に追われる状況を改善できると期待している。問題を発見する手段が増える一方、それらを正確に評価し、修正を完了させるための人手が不足していることが、今回の方針転換の背景にある。

AIによる脆弱性発見は成果を上げる一方、報告の増加が負担に

AIを活用した脆弱性調査は、curlのセキュリティ改善に実際の成果をもたらしている。Stenberg氏は10月14日に公開した監査に関する記事で、Aisleの複数の技術者が約1年間にわたってAIツールをcurlのコードに適用し、35件の脆弱性が発見・公開され、CVEが付与されたと報告した。Stenberg氏が高く評価したのは発見件数だけではない。熟練した技術者がAIによる分析を支え、詳細かつ正確な報告を提出したことで、従来以上のペースで脆弱性を修正できた点も重視している。

同じ10月14日に公開されたcurl 8.23.0では、合計24件の脆弱性が修正された。ただし、Aisleとの約1年間の取り組みで確認された35件と、curl 8.23.0で修正された24件は、対象期間も集計範囲も異なる。前者は特定の取り組みによる累計、後者は当該リリース全体の修正件数であり、同じ数字として比較することはできない。

curl 8.23.0で修正された問題の一つが、HTTP/2のアップロード処理に存在するメモリ解放後使用（Use-After-Free）の脆弱性「CVE-2026-92392」だ。深刻度はHIGHに分類され、Stenberg氏によると、悪意のあるサーバーへデータをアップロードしたクライアント側で、任意のコードを実行される可能性がある。ただし、攻撃が成立するには複数の厳しい条件を満たす必要があり、実際にはプロセスの異常終了にとどまる可能性が高いとみられている。それでもcurlプロジェクトは問題の重大性を認め、通常8週間のリリース周期を6週間に短縮して修正を公開した。

この脆弱性を報告したのは、AnthropicのOSS Scannerを使用した同社のLuna Tong氏である。Stenberg氏はAIモデルが発見に関与した可能性に言及しているが、モデルがどの程度自律的に脆弱性を発見したかを確定する説明ではない。重要なのは、AIツールを活用した調査によって深刻な脆弱性が報告され、curl側が内容を検証したうえで修正を急いだという点だ。

一方、Stenberg氏が10月20日の発表で問題視したのは、実際の利用環境ではほとんど発生しない操作や、特殊な設定の組み合わせによって生じる挙動まで、脆弱性として報告される傾向である。libcurlには多数の設定項目があり、APIも柔軟に設計されているため、膨大な組み合わせを検証すれば、想定外の動作が見つかることはある。しかし、その動作が実際に利用者へ被害を及ぼすのか、あるいは文書で想定されているAPIの利用方法なのかを判断するには、個別の調査が欠かせない。

curlの方針では、軽微なメモリリークや、文書で保証していないAPIの使い方によって生じる問題などは、原則としてセキュリティ上の脆弱性に分類しない。ただし、大規模なメモリリークによってサービス拒否が引き起こされる場合や、APIの仕様の解釈に議論の余地がある場合などは、判断が変わる可能性もある。不具合が再現することと、それがセキュリティ上の脅威に当たることは別であり、実際の利用条件や影響範囲を理解したうえで評価する必要がある。Aisleとの取り組みへの評価と今回の方針変更からは、curlが求めているのは単に脆弱性を数多く発見することではなく、発見した問題を正確に検証し、修正まで完了させるための協力体制であることが分かる。

公開による協力拡大と、攻撃リスクのバランス

脆弱性をGitHubの公開issueで扱う場合、開発者だけでなく攻撃者も、問題の詳細や修正状況を早い段階から確認できるようになる。Stenberg氏も、新方針によって攻撃者が脆弱性を悪用できる期間が多少長くなることを認めており、そのため公開対象をHIGH未満の問題に限定したと説明している。外部の協力者を増やせる一方、修正版が公開される前に脆弱性情報が広まることで、既存の利用者が負うリスクは高まり得る。今回の判断は、そうした危険性と、限られた人員で保守を続けることの難しさを比較した結果といえる。

curlでは、深刻度の低い脆弱性への対応自体をやめる案も検討したという。しかしStenberg氏は、実在する脆弱性にcurlがCVEを割り当てなくても、報告者が異議を申し立て、別の主体によってCVEが付与される可能性を指摘している。つまり、対応を打ち切っても脆弱性の存在がなくなるわけではなく、問題が外部で公表される可能性も残る。今回の方針は、対応を放棄するのではなく、問題の評価と修正に必要な作業を公開の場で進めるという選択だ。

利用者やLinuxディストリビューションなどの配布元にとっては、脆弱性の調査状況や修正の進展を早い段階から把握できる利点がある。一方、公開issueが作成されたという事実だけで重大な危険があると判断するのではなく、自分たちの利用環境で問題が成立する条件や、修正の適用状況を確認することが重要になる。今後は正式なセキュリティ勧告に加え、報告段階から公開される議論も、対応を判断するための情報源となる。

10月26日から始まる新たな運用で問われるのは、外部の参加者が脆弱性の発見だけでなく、報告の評価や修正内容の検証、セキュリティ勧告の作成まで担えるようになるかどうかだ。公開化しても、最終的な判断や修正作業が少数の主要メンテナーに集中するのであれば、負担軽減の効果は限られる。AIによって脆弱性の発見が加速するなか、増え続ける報告を適切な修正につなげ、curlの保守を持続可能なものにできるかが、今回の方針転換の成否を左右する。