先日協調的脆弱性開示プロセスも変革を強いられるのではみたいなことを言ったのですが、さっそく運用を変更する例が現れました。
というか発表されたのが2026/10/20なのでPHPの脆弱性がリークされたのとまさに同日ですよ。
もっというとこの日付近は他にもNodeやGitLabにJavaと大量の脆弱性祭りでしたからね。
どんだけ偶然。
そんなわけで脆弱性祭りの話題に隠れて全然知られていないわけですが、正直今後のインターネット、特に協調的脆弱性開示プロセスの転換点のひとつになる出来事かもしれません。
以下はCurlの生みの親Daniel Stenbergによるブログ記事、Do minor curl vulnerabilities in the openの紹介です。
Do minor curl vulnerabilities in the open
Curlプロジェクトは、脆弱性開示プログラムを一部変更することを決定しました。
2026年10月26日より、深刻度がLOWもしくはMEDIUMと判定された脆弱性レポートは、GitHubリポジトリのIssueとして提出される必要があります。
HackerOneトラッカーにおいてHIGH・CRITICALと判定された脆弱性は非公開に保たれます。
懸念がある場合は疑問をHackerOneに投稿すれば、どの程度の深刻度と判定するかをお伝えします。
過去数年間で投稿された問題のうち90%以上は、即座にHIGH未満であると判定されています。
HackerOneに提出された問題のうち、LOW・MEDIUMと判定されたものについては公開・クローズし、GitHubでの再提出を依頼します。
Avalanche survival tricks
今回の方針変更は、絶え間なく押し寄せられる脆弱性報告がきっかけとなったものです。
報告の数はおさまることがなく、今後も当面減ることはないでしょう。
プロジェクトは苦境に立っています。
メンテナ全員が過度な負担に疲弊し、限界を感じています。
生き残るためには行動を起こさなければなりません。
これは生存をかけた次なるステップです。
これが最後ではないかもしれませんが、我々は圧し潰されるわけにはいきません。
Public vs private
プロセスをオープンにすることで、世界中の人々がIssueに参加できるようになります。
レポートや脆弱性の評価・対応をはじめ、アドバイザリの作成や問題がいつから発生したかの調査にも参加できるようになります。
理想としては、正しい修正が得られ、問題が解決し、類似や関連した問題も解決されること、そして今後同じような問題が発生しないようにするためのより良い方針が得られることが望ましいです。
最近の傾向として、新しいCVEやその修正が公開されるとすぐに、研究者たちがAIを使って類似のバグや修正漏れを探し出すという動きがよく見られます。
このプロセスを事前に公開することで、リリースする前により徹底的な検証を行うことが可能になります。
脆弱性を公開するだけで報告1件あたりの作業量が減るわけではありませんが、より負荷を分散させやすくなると考えています。
またディスカッションから得られたレポートや教訓が、より目に入りやすく、より学びやすくなると期待しています。
オープンプロセスにより、ディストリビュータやそのほかのcurlユーザも、セキュリティ対応版をより早くより容易に手に入れられるようになるでしょう。
The risks
危険性の高いIssueを誤って低重要度と判断し、公開してしまうリスクがあると指摘する人が複数人います。
しかし、研究者から報告されたリスクを最初に過小評価することはほとんどないため、そのリスクは低いと考えます。
脆弱性レポートが公開されると、当然ながら善意のユーザと悪意のあるユーザの両方がすぐ利用できるようになります。
今回のポリシー変更では、悪意のあるユーザが脆弱性を利用する機会が少し長くなります。
残念ながら、これを回避する方法は存在しません。
そこで、公開する脆弱性は悪用される危険性の低いものに限定されます。
Severity LOW
深刻度の低い問題は単純に無視するという案も検討しました。
しかしCVEには異論申し立てを行うことが可能であり、誰かが脆弱性に対してCVEを付与しなければ、他の誰かがCVEを付与することが可能です。
したがって、深刻度が低かったとしても真の脆弱性は無視することはできません。
ただし、私個人としては、実際にユーザやアプリに損害を与えることのできない潜在的な脆弱性については拒否する方針です。
Crazy combos
最近報告される脆弱性のよくある傾向として、ほとんどあえりえない不可解なシーケンスとオプションの組み合わせで予期せぬ動作を引き起こすことをAIモデルが見つけ出してくることがあります。
そのシーケンスは現実的にはほぼ使われないものあり、そして実際に使われていて予期せぬ挙動が発生するのであれば、とっくに誰かが気付いているはずです。
つまり、現実世界で実際に問題が発生するリスクはほぼ存在しない脆弱性です。
そのような問題に対してわざわざCVEを登録したところで、ユーザを誰一人として守ることはできません。
それは単に自分自身と、世界の誰かがそれに対応する負担を増やすだけです。
Flow control it
libcurlの大量のオプション、プロトコル、そして柔軟なAPIを混ぜ合わせれば、明確にドキュメント化されていない動作を無限に作り出すことができます。
AIはそれらの全てを試行し続け、些細な不一致までも脆弱性として取り上げようと躍起になっています。
このような悪循環の中において、我々が正気を保ち続けることは困難です。
このままのペースで続く脆弱性報告に対して、我々にはそれに対抗できる能力も、人員も、そして意欲もありません。
我々だけではなく、ほとんどのソフトウェアプロジェクトは耐えられないでしょう。
なんらかの対策を講じなければなりません。
How to assign severity
curlプロジェクトでは、脆弱性のレベルとしてLOW・MEDIUM・HIGH・CRITICALの4種のみを使用しています。
基本的なガイドラインも用意されています。
もちろん、このガイドラインをより良く明確に改善することも可能です。
どうして他のOSSプロジェクトも同じことをやらないんだい？
OSSとはコミュニティが協力し、負荷を分散することだろう。
バグの隠蔽はこの理念に反している。
どうしても隠蔽したいなら、まず報酬を払って非公開にしてもらうことにしよう。
問題は、この負担を分かち合おうとする企業や人があまりに少なすぎることだ。
みんなそこから利益だけを奪おうとしている。
もし企業が脆弱性に対応するとしても、自分のところにだけ当ててOSSに流すことはしないだろう。
重大な脆弱性が公開されると、攻撃者はシステムにただで侵入する手段を得てしまう。
脆弱性を秘密にすることで、その事態を防ぐことができていた。
AIによって大きく状況が変わった。
AIが発見したバグは、もはや公開情報と変わらないだろう。
curlチームのこの決定によって、現実が変わることは特にないだろう。
感想
先日libxml2が脆弱性は全て公開するわって言った後、かろうじて後継メンテナが現れたので撤回されたことがありました。
libxml2はたった一人で保守していたからそのような方針にも特に驚きはありませんでしたが、curlは開発者が10数名はいるはずなのに、それでも限界というのは驚きですね。
そんなわけで今後危険性の高くないセキュリティバグは普通にIssueでの対応になります。
すなわち修正もされていないのに誰でも見れるので、攻撃者に利用され放題っていうことです。
レベルMEDIUMってどれくらい？
では具体的に開示されるレベルMEDIUMの脆弱性ってどのくらいなのでしょうか。
curlでは、過去修正されたセキュリティバグは公開されています。
適当に幾つか見てみましょう。
CVE-2022-42916 / CVE-2022-43551 CVSS:7.5
ドメインに国際化ドメイン名を使っているとHSTSが無視される。
CVE-2022-27774 CVSS:5.7
認証情報を含んだリクエストが別サーバにリダイレクトされると、通常は認証情報を削除するけど、特定条件下では消さずに転送先にも送ってしまう。
CVE-2025-4947 CVSS:6.5
ライブラリにWolfSSLを使った場合、QUIC証明書の正当性チェックを行わない。
CVE-2023-46218 CVSS:6.5
Cookieドメイン名の大文字小文字を区別してしまう。
つまりPublic Suffix Listに"curl.co.uk"があったとしても、"domain=co.UK"と送られてきたら"co.uk"にCookieを設定できる。
CVE-2026-19931 CVSS:9.8
Negotiate認証において、最初に認証情報を空で送って接続した場合、次のリクエストでその認証を再利用してしまう。
まあ確かに直接RCE！みたいなやばい代物はなさそうではあるのですが、でも即座に大公開していいレベルの脆弱性なのかはよくわかりません。
最後のやつとかCVSSスコアもえらいことになっているし大丈夫なのかという気がする。