最初のエクスプロイトからKEV登録まで42日：シグナルはどこにあったのか

最初の公開警告は、XにもCVE IDをキーとするフィードにも現れませんでした。現れたのは、プロジェクト自身のGitHub Issueトラッカーです。2026年9月11日、あるNextcloud管理者が、組み込みのCollaboraドキュメントサーバーアプリ（アプリ名richdocumentscode）への攻撃を示すアクセスログを投稿しました。これはCVE IDが公開される32.5日前、CISAがこの脆弱性をKEVカタログ（Known Exploited Vulnerabilities）に追加する42.2日前のことです。2026年10月26日10:17〜10:56（シンガポール時間、SGT）に、EveryInfraへ60件のリクエストを送信しました（課金対象52件、合計$0.029576）。その結果を、NVDの変更履歴、FIRST EPSSの時系列、最近KEVに登録された別の24件と比較しました。

結果は明確です。CVE IDでXを検索すると106件の投稿が返り、CVE公開前は0件、KEV登録後は80件でした。事前に定めたルールに従い、1人の評価者が各投稿を1回ずつラベル付けしたところ、93.4%がリポスト、ボット、宣伝でした。CVEレコード内の機械可読なSSVCフィールドは9日間「悪用なし」のままで、EPSSは10日間1.2%にとどまりました。

本記事でいう「監査可能なシグナル対応プロセス」は、毎日行う5つの工程で構成されます。プロジェクトのIssueトラッカー、ベンダーフォーラム、いくつかのソーシャルプラットフォームを、CVE IDだけでなく自社で使うコンポーネント名でも検索します。各レスポンスを未加工のまま、取得時刻とともに保存します。結果を資産リストと照合し、ノイズを除去します。そのうえでアップグレード、削除、調査のいずれかを行い、各工程を誰が、いつ、どの根拠に基づいて実施したかを記録します。このプロセスは、運用チームとセキュリティチームにどの項目を優先すべきかとその理由を示しますが、悪用を予測するものでも、ベンダーのアドバイザリに代わるものでもありません。

本記事で扱わないこと

本記事では監視と対応のみを扱います。攻撃手法、悪用の詳細、リクエスト形式は記載しません。侵害に触れる場合も、管理者がどこに、いつ投稿し、何を報告したかだけを記します。個人アカウント名は伏せ、組織アカウント（CISA、CERT.LV、イタリアのCSIRT、Censysなど）とプロジェクトのメンテナーのみ名前を挙げます。ベンダーの開示判断は評価せず、公開記録上の時刻を並べるにとどめます。

米国連邦政府機関の読者にとって、最も重要な点が1つあります。BOD 26-04に基づき、CISAは、KEVへの登録状況、悪用の自動化可能性、技術的影響、インターネットへの露出という4つの要素に基づいて是正期限を設定します。このCVEについて、KEVエントリは各機関に3日間の期限を与え、フォレンジックトリアージを求めました。これは同指令で最も厳しい期限です。期限までのカウントダウンはKEV登録時に始まりますが、攻撃はその42日前に始まっていました。本記事は、そのギャップと、それを確認できた公開の場について扱います。

最初のリクエスト前に定めた基準

10月26日10:16（SGT）、最初のリクエストを送る前に、チェックファイルに5つの基準を書き込みました。10:29（SGT）、横断調査の結果を確認する前に、さらに2つの基準を追加しました。下の表では各基準とその結果を並べて示しています。各数値の出典は後のセクションで示します。

基準2には補足が必要です。Xでは、どちらの検索方法（CVE IDでの検索、製品名と症状の組み合わせでの検索）でも、CVE公開前の関連投稿は1件も見つかりませんでした。そのため、Xだけでは差を示せません。差が生まれるのは、プロジェクトのIssueトラッカーとフォーラムです。どちらもコンポーネント名で監視できる公開の場です。基準6を「形式上の合格」としているのは、1日の先行と30日の先行では価値が大きく異なるためです。この数字の内訳は後のセクションで説明します。

主要事例：最初の攻撃を記録したログ行からKEV登録まで

対象のCVEはCVE-2026-110447です。Collaboraのセキュリティアドバイザリによると、影響を受けるのは、Nextcloudのアプリのうち、任意で導入する「Collabora Online - Built-in CODE Server」だけです。このアプリは、Nextcloudサーバー内でドキュメントサーバーのコピーを動かします。スタンドアロンのCollabora Onlineサーバーは影響を受けません。Nextcloudフォーラムの警告では、DockerやLinuxディストリビューションのパッケージも安全だと補足されています。修正版は26.4.303で、アドバイザリではアプリのアップグレードまたは削除が必要だとしています（無効化だけでは不十分です）。NVDのレコードには、この脆弱性が「2026年9月と10月に実際に悪用された」と記載されています。

公開記録で秒単位まで確認できる時刻をすべて収集し、要約ではなくAPIを直接利用しました。GitHub issues APIからは、Issueと各コメントのcreated_atの時刻が得られます。NextcloudフォーラムはDiscourse（APIドキュメント）で運用されているため、トピックURLに.jsonを付けると各投稿の時刻を取得できます。CVE IDの予約時刻と公開時刻は、CVE.orgのレコードのバックエンドAPIから取得しました。NVDの各フィールド変更の時刻はNVD CVE change history APIから取得しています。KEVの時刻はCISAのKEV JSONのdateReleasedで、表中の時刻はすべてUTCです。

この表にある2つの「70分」と1つの「0.7秒」は、詳しく見る価値があります。バージョン26.4.303は9月11日13:43に公開されました。その70分後、影響を受けた最初の管理者がIssueを作成し、前日からシステムが侵害されていたと報告しました。

この時点では、どちらも相手の状況を知らなかったと考えられます。リリースノートにはセキュリティに関する記述がなく、管理者はIssueで誰かに促されてからアップグレードしました。2つ目の70分は10月14日です。CVE.orgが02:27にIDを公開し、そのIDを含む最初のX投稿は69.8分後に現れました。

0.7秒はCVE.org APIで確認できます。dateReservedの値は02:27:41.637、datePublishedの値は02:27:42.315です。つまり、この脆弱性には33日間、予約済みのIDすら存在しませんでした。CVE IDで照合するプロセスには、この33日間、照合する対象がありませんでした。これが、IDを起点に情報を取り込むすべてのチームにとっての根本的な問題です。

二次情報が元の記録と一致しない箇所も1つ見つかりました。Censysの10月16日付のアドバイザリでは、報告者のログに記録された最初の悪意のあるリクエストは9月16日だとしています。しかし、Issue本文には、9月10日19:51と9月11日09:56（タイムゾーン：+0200）のログ行が記載されています。

Issue自体は9月11日に作成されているため、9月16日のログ行を最初のリクエストとして引用することはできません。33日間という期間では、要約の日付を1つ誤るだけで6日の誤差になるため、本記事ではGitHub APIから取得したIssue本文を使用しています。露出規模を示す数値も同じアドバイザリから引用しています。アプリがインストールされていたのは19,454台のホストと103,350件のWebプロパティです。Censysによると、これらすべてで脆弱性が確認されたわけではなく、どちらの数値にも同じアプリのARM64ビルド（1,001台のホスト）が含まれています。

33日間CVEがなかった理由

KEVには3つの明確な要件があり、CISAが基準ページに掲載しています。脆弱性にCVE IDが付与されている必要があります。実際に悪用されていることを示す信頼できる証拠が必要です。明確な修正方法が示されている必要があります。この脆弱性は、9月11日の時点で2つ目と3つ目の要件を満たしていました。Issueには3人の管理者からの報告があり、修正版も公開されていたためです。1つ目の要件がKEVへの追加を阻んだため、IDのない32.5日間が加わり、合計42日になりました。

Collaboraの10月14日のブログ記事は、2つの事実を並べて示しています。今年、同社はAIを活用したセキュリティ報告を非常に多く受け取りました。また、GitHub経由でCVEを取得するまでの期間が、およそ1日から何週間にも延びました。記事は前者が後者の原因だとは述べていません。待ち時間を短縮するため、CollaboraがCVE採番機関（CNA）となるための申請を進めていると述べています。

CVE.orgのレコードによると、最終的な割り当て元はMITREで、予約と公開は同じ秒に行われています。これは通常のキュー処理というより、MITREが最終手段として割り当てを行う機関（assigner of last resort）の役割を担ったように見えます。このケースに関する声明は見つからなかったため、原因については推測しません。

このケースは珍しいものではありません。10月、セキュリティ企業のSecond SecurityがThe Patchless Windowという調査を公開しました。この調査では、2026年1月から8月までの18,594件のオープンソースCVEについて、それぞれを修正した最初の公開コミットまで遡りました。修正の公開からCVE公開までの期間の中央値は、1月が5.1日、8月が39.2日でした。Collaboraのケースでは、この間隔は32.5日で、8月の中央値より短くなっています。つまり、オープンソースコンポーネントでは、「先に修正、IDは1か月後」が当たり前になりつつあります。

BleepingComputerの10月15日の記事がこの調査を引用しており、本記事では調査元のサイトで数値を確認しました。The Hacker Newsもこの件を報じています。CVE IDベースで脆弱性インテリジェンスを購読しているチームにとって、意味するところは単純です。平均すると、最初のアラートが届くのは修正が公開されてからひと月以上後になります。その間、修正は存在しているのに、それがセキュリティ修正であることを誰も知らせてくれません。

もう1つ背景があります。2026年4月15日以降、NISTは情報を付加するCVEを一部に絞りました。KEVのエントリ、連邦政府が使用するソフトウェア、「重要ソフトウェア（critical software）」を優先しています。NISTはその理由として、2020年から2025年にかけてCVEの登録件数が263%増加したことを挙げています。10月26日時点で、NVD APIではこのレコードはまだDeferred（割り当て元によるCVSS 4.0スコアとCISAのSSVCのみ）と表示されていました。NISTはKEVエントリへの情報付加を1営業日以内に完了することを目標としていますが、KEVへの登録から2日以上が経過していました。

つまり、NVDの多くのフィールドは、KEVへの登録前と登録後しばらくの間、空のままの可能性があります。NVDのスコアをもとに脆弱性をキューの先頭へ移すつもりなら、その計画はまさにこの期間に機能しなくなるおそれがあります。説明文は公開後1時間以内には掲載されていました。構造化されたフィールドが追加されたのはその後で、続くテストでは追加がどの程度遅れたかを測定します。

テスト1：CVE公開前にソーシャルプラットフォームで見られた情報

もし誰かがXでこのコンポーネントを監視していたら、もっと早く気づけたでしょうか。10月26日10:24〜10:26（SGT）に、X（Twitter）検索スクレイピングAPI（twitter/search）で3回の検索を実行しました。いずれの検索も、期間を9月1日〜10月14日に指定しています。1回目はアプリ名richdocumentscodeで検索しました。2回目は製品名と症状を表す語（nextcloud (hacked OR webshell OR compromised OR backdoor)）を使いました。3回目はnextcloud collaboraのみを使いました。

結果は一致していました。最初の2つの検索ではそれぞれ3件と5件の投稿が返されましたが、すべて10月14日以降のもので、CVE公開前の投稿は0件でした。3つ目の検索ではCVE公開前の投稿が16件返されましたが、脆弱性や侵入に言及したものは1件もありませんでした。内容は、スイス連邦職員とオープンソースのオフィスツール、欧州のデジタル主権、マネージドNextcloudホスティングに関するものでした。また、3つのリクエストすべてにuntil:2026-10-14を指定していたにもかかわらず、レスポンスには10月14日以降の投稿がそれぞれ3件、5件、6件含まれていました。日付の上限（Xの高度な検索のヘルプにおける「特定の日付より前」）は厳密ではなかったため、各投稿のposted_atの値で改めてフィルタリングしました。

Redditでは、Reddit検索スクレイピングAPI（reddit/search）は常に直近1か月を対象とします。10月26日の検索は9月26日以降を対象としており、CVE公開前の18日間が含まれます。10:42（SGT）にrichdocumentscodeを新しい順で検索したところ、14件の投稿が返されました。14件すべてがこの脆弱性に関するものでしたが、CVE公開前のものはありませんでした。最初の投稿は10月14日20:04のセキュリティニュースの転載で、CVE公開から17.6時間後でした。

最も有用なRedditの投稿は10月22日に現れました。r/NextCloudで、ある管理者が組み込みのCollaboraアプリを通じてサーバーが侵害された経緯を説明しており、この投稿には52件のコメントが付きました。その13秒後、同じ投稿者がr/Malwareにも同じ内容を投稿しています。Hacker NewsについてはHNのAlgolia検索APIを使用しましたが、richdocumentscodeの結果は0件でした。9月1日以降のnextcloud collaboraでは、最初の関連項目は10月15日のリンク投稿（22:06 UTC、2ポイント、コメント0件）でした。

各プラットフォームで最初に現れた関連項目を、CVE公開を基準に時系列で並べました。GitHubのIssueは32.5日前、Nextcloudフォーラムは10.7日前でした。Xは0.05日後、Redditは0.73日後、Hacker Newsは1.8日後です。YouTube検索スクレイピングAPI（youtube/search）では、10件中10件がIDを含み、最初の関連項目は2.5日後でした。LinkedIn検索スクレイピングAPI（linkedin/search）では、10件中8件がIDを含み、最初の関連項目は4.0日後でした。Weibo検索スクレイピングAPI（weibo/search）では、別の脆弱性（PHP2Shell）に関する投稿9件と、Collaboraに1行だけ触れたダイジェスト1件が返されました。Threads検索スクレイピングAPI（threads/search）は直近19時間分の投稿25件しか返さなかったため、初出を確認できませんでした。

この表が示す内容は、順を追って確認できます。まず、CVE公開前に公に確認できたシグナルはすべて、プロジェクトが管理するIssueトラッカーとベンダーのユーザーフォーラムにありました。次に、そこでの投稿者は影響を受けた管理者とメンテナーで、投稿には確認可能なログとバージョン番号が含まれていました。さらに、最初のソーシャル投稿はCVE公開後に現れ、IssueトラッカーではなくCVEレコードを参照するセキュリティニュースアカウントによるものでした。したがって、主に行うべきなのは「コンポーネント名でプロジェクトのIssueとフォーラムを監視すること」です。ソーシャルプラットフォームでは後から情報が拡散され、被害者からの報告も加わりますが、今回のケースでは早期警戒の役割を果たしていませんでした。

この結論には限界があります。今回の被害者は、自前でシステムをホストする小規模組織で、こうした組織はプロジェクトのIssueトラッカーに助けを求めます。被害者が大企業であれば、最初のシグナルはベンダーの有償サポート窓口に現れる可能性が高くなります。公開データではその窓口を確認できません。そのため、このパターンが最もよく当てはまるのは、小規模チームが自ら運用するオープンソースコンポーネントです。

テスト2：CVE公開後の投稿量はKEVに連動する

10:26（SGT）に、XでCVE-2026-110447をlimitを200に設定し、最新順で1回検索しました。106件の投稿が返されたため、上限には達していません。投稿を3つの期間に分けました。CVE公開前は0件、CVE公開からKEVまでの9.7日間は26件でした。KEV後の2.3日間は80件で、そのうち49件が10月24日に投稿されました。KEV後48時間以内の投稿は全体の71.7%でした。

このグラフの形からはっきりわかるのは、XにおいてKEVはシグナルではなく増幅装置だということです。この脆弱性は9月に悪用されており、10月14日の時点でCVEの説明には「exploited in the wild」と記載されていました。大手セキュリティニュースアカウントは同じ日に投稿しています。しかし、本格的な再投稿の波が来たのはCISAのKEV通知の後でした。多くのセキュリティニュースアカウントやボットは日次のKEV更新を情報源にしており、多くの企業はKEVに登録された項目に対してのみチケットを起票します。

監視の観点では、今回のケースで「特定IDのX投稿量が急増」というアラートを設定していた場合、発火するのはKEVの後だったことになります。投稿量からわかるのは、人々がいま何を話題にしているかです。誰がすでに攻撃を受けたかはわかりません。パイプラインでソーシャル上の投稿量をトリガーにしている場合、測っているのは注目度であり、今回注目が集まったのは最後でした。

言語の内訳も参考になります。106件のうち、英語が68件、日本語が18件、フランス語が5件、スペイン語が4件、韓国語が3件、中国語が1件でした。米国のチームにとって重要なのは日本語の割合です。KEV以前のXで当事者による唯一の侵害報告は、日本語の投稿1件だったからです。英語の投稿だけを残す監視では、これを見逃していたはずです。言語で絞り込む場合は、ユーザーがソフトウェアを運用しているすべての国の言語を残してください。

テスト3：93.4%がノイズ、その中身

106件の投稿を、事前に定めたルールで6つの分類に振り分けました。限界を明確にしておくと、106件のラベル付けはルールに基づいて1回行っただけで、別のラベラーによる独立した確認はしていません。したがって93.4%はルールベースのラベル付けを1回行った結果であり、誤差の範囲はわかっていません。正式なレポートで使う前に、別の人に同じルールで106件を改めてラベル付けしてもらい、2回の結果の一致率を報告してください。「シグナル」は、CVEレコードやベンダーのアドバイザリにない事実を加える投稿です。「ノイズ」は3つの分類からなります。アドバイザリやニュース記事の再投稿、テンプレート型のボットや日次ダイジェスト、宣伝または無関係なコンテンツです。

結果は、再投稿80件、ボットとダイジェスト12件、宣伝または無関係な投稿7件で、計99件（93.4%）でした。シグナル投稿7件のうち4件は、独自のデータを持つ機関によるもので、CERT.LV（ラトビア）、CSIRT（イタリア）、Censys、CISAです。2件は、レコードを確認した人による新しい事実でした。1件はSSVCフィールドが説明と矛盾していることを、もう1件はNVDにCVSS 4.0のスコアはあるものの3.xのスコアがないことを示していました。最後の1件は日本の管理者による投稿（10月23日08:29 UTC）で、前の週にこの脆弱性を突かれてサーバーにマイニングソフトウェアを仕込まれたという内容でした。

この7件のうち、KEV以前の投稿は4件だけです。つまり、KEV以前にIDを含む投稿をすべて読んだチームは、有用な4件を見つけるために26件を読んだことになります。KEV後は比率がさらに悪く、80件のうち有用なのは3件でした。読むコストはKEVとともに増えますが、価値は増えません。

宣伝・無関係の投稿7件のうちいくつかは、ほかの脆弱性でも繰り返し見かけるタイプです。ノイズルールに追加してください。見出しを使って暗号資産トークンを宣伝する投稿や、「AIボットをURLに接続してアラートを受け取る」という製品広告がありました。パッチ未適用のシステムを見つけてテストする方法を教える「バグバウンティのヒント」投稿もありましたが、これらは除外し、内容もここでは繰り返しません。「毎週、世界が終わるような気がする」という一般的なコメントは、IDを含んでいたためにヒットしただけでした。

ノイズはXだけではありません。Nextcloudフォーラムの7件の投稿からなるスレッドでは、投稿3と6が同じ新規アカウントからのものでした。どちらも「30秒でできる無料セルフテスト」がある外部ページにリンクしていました。投稿7はコミュニティリードによるメモで、2つのリンクがほぼ同一であることと、チームがスパムを監視していることを述べていました。Weiboでは、10件の結果のうち8件が、8アカウントから2秒以内に投稿された同一のPHP2Shellテキストで、典型的なアカウントファームのパターンです。Threadsでは、「Nextcloud Collabora」の結果25件のうち6件が、動詞「collabora」（「協力する」）を使ったイタリア語の投稿でした。

テスト4：機械可読なリスクフィールドはテキストより遅かった

多くの脆弱性パイプラインは説明文を読みません。読むのは構造化されたフィールドです。その情報源の1つは、CISAがVulnrichmentプロジェクトを通じてCVEレコードに書き込む3つのSSVC決定ポイントで、exploitation、automatable、technical impactです。もう1つは、FIRSTが毎日公開するEPSSスコアで、今後30日間に悪用活動が観測される確率を推定します。BOD 26-04指令は、KEVのステータス、automatable、technical impact、露出状況を使って連邦機関の期限を設定しており、CISAはこのうち3つをVulnrichmentを通じて提供しています。

NVDの変更履歴APIを使って、このレコードのSSVCデータへのすべての変更を取得しました。時系列データはEPSS APIで取得しました。CVEの説明には10月14日03:17から「exploited in the wild」と記載されていました。SSVCデータは表のとおりに変化しました。

つまり、9.7日間、説明文には「exploited」とあったのに、構造化されたフィールドは最初は空で、その後9日間は「not exploited」でした。「exploited」に変わったのはKEVの47分後です。EPSSはその10日間1.2%（当時の約68パーセンタイル）にとどまり、12.3%に達したのはKEVから2日後でした。「SSVCがactiveまたはEPSSが10%超ならチケットを作成する」というルールは、KEVの1〜2日後に発火していたことになります。説明文から11日遅れです。

あるXユーザーがこの不一致に気づきました。このユーザーは10月23日21:03 UTCに続報を投稿しました。不一致についての最初の投稿から約6分後にKEVがこの脆弱性を追加し、SSVCもactiveになったという内容です。投稿では、パイプラインに古い値が残っている場合はデータを再取得するよう呼びかけ、連邦機関の期限が10月26日であることにも触れていました。106件の投稿のうち、パイプラインに直接役立つ数少ない投稿の1つでした。

これはSSVCやEPSSに価値がないという意味ではありません。EPSSのFAQには、EPSSは完全なリスクスコアではないと書かれており、SSVCは根拠を必要とするアナリストの判断です。私たちの観察はもっと限定的で、根拠がプロジェクトのイシュートラッカーにしかなかった間は、どちらのフィールドもそれを拾わなかったということです。構造化されたフィールドはゲートではなく並べ替えに使ってください。説明文の「exploited in the wild」などのフレーズを対象とする別のテキストルールを追加してください。

テスト5：最近のKEVエントリ24件と、Xがどれだけ早かったか

1件だけでは十分ではありません。KEVが9月26日から10月23日までに追加した30件のエントリをすべて取り上げました。そのうち6件は2015〜2025年の古いIDでした（例：2015年のProFTPDとBIND）。残る24件について、SGTの10:28から10:41に、twitter/searchでIDごとに1回、limit 200でXを検索しました。KEVの時刻には、NVDの変更履歴における最初のKEVアノテーションを使いました。このアノテーションはCISAの公開から数分〜数時間後に付くため上限値となり、Xの先行時間がやや大きく出ます。これは、CISAのKEV JSONのdateReleased（10月23日19:30）を使うメインケースとは異なります。同じCVEのNVDのKEVアノテーションは20:17で、47分後でした。カタログの古いバージョンにはエントリごとの公開時刻がないため、横断分析では24件すべてにNVDのアノテーションを使っており、メインケースも同じ基準で9.7日となっています。

結果として、24件中23件（95.8%）でKEVより前にIDを含むX投稿が少なくとも1件あり、形式上は基準6を満たしました。しかし、丸める前の値で計算した先行時間の中央値は約1.16日（12番目と13番目の値は1.12日と1.19日）で、1日を超えて先行したのは24件中13件だけでした。さらに重要なのは、17件のCVEで最初のX投稿がNVDの公開から0.3日以内だったことです。理由はNVDとKEVの間隔にあります。24件中12件では、KEVがNVDと同じ日か翌日に来ており、その多くはベンダーが確認したゼロデイ（Citrix NetScaler、Fortinet、Ivanti）でした。Xが早く見えるのはこの間隔が長い場合だけで（Atlassianは10日、Ahsayは10日、今回のメインケースは9.7日）、その先行時間のほぼすべては、CVE自体が先に公開されていたことによるものです。

NVDからKEVまでの間隔を暦日で並べると、傾向がはっきりします。間隔は9件のCVEで0日、3件で1日、2件で2日でした。5日、6日、9日がそれぞれ1件、10日が3件、27日が4件です。中央値は1.5日でした。

つまり、今月のKEVエントリは2つのグループに分かれます。1つ目のグループでは、ベンダーがゼロデイを確認し、CVEとKEVがほぼ同時に出ます。2つ目のグループでは、CVEはずっと前に公開されており、悪用の証拠が後から出てきました。

最初のグループでは、ベンダーの緊急アドバイザリーをXでより早く把握でき、その差は数時間です。2番目のグループでは、Xが先行するかどうかは、公開後に誰かがそのCVEに気付くかどうかで決まります。Plexの事例が示すように、3週間誰も言及しないこともあります。また、6件のCVEでは、NVDに追加される前にIDを含むXの投稿がありました。たいていは、ベンダーのアドバイザリーが先にIDを公表していたためです。そのため、タイムラインを作成する際は、NVDの受理時刻をIDが公開された時刻として扱わないでください。

例外はPlex Media Serverの4件のCVEです。NVDは9月23日に公開しましたが、これらのIDを含む最初のXの投稿は10月18日でした。これは24.9日後で、KEVのわずか2.2日前です。この事例は次のセクションで取り上げます。補足が2点あります。CVE-2026-88771とCVE-2026-102764については、検索結果が上限の200件に達したため、初観測時刻は下限値です。また、Xの検索はすべての投稿を返すのではなく、ランク付けされたサンプルを返します。

SSVCの結果はより単純です。30件のいずれも、KEV登録前にexploitation: activeになっていなかったため、このサンプルではSSVCの「active」はKEVをそのまま反映しているにすぎません。KEV登録前日にEPSSデータがあった12件のCVEでは、12件すべてのスコアが10%未満でした。このサンプルでは、どちらのフィールドもカタログより早い警告にはなりませんでした。

3つの比較事例：NetScaler、Plex2Shell、PHP2Shell

パターンがあるかを確かめるため、同時期の3つの事例を比較しました。それぞれについてXを1回ずつ検索し、CVEの公開を0日目として、各事例の一次情報に記録された時刻を並べました。

NetScaler：Xは早かったが、初期の内容はうわさだった。10:54 SGTに、9月26日〜28日の期間でNetScalerを検索したところ、176件の投稿が見つかりました。最初の投稿は9月26日15:07 UTCです。フォロワー数の多いアカウントが、活発に悪用されている未知のNetScalerゼロデイにより、複数の機関がデバイスを停止したと投稿していました。NVDがCVE-2026-88771を受理したのは9月27日17:16で、その時点でXにはすでに77件の投稿がありました。

初期の投稿のいくつかは、このうわさがRedditでのシステム管理者の議論から始まったと述べていました。CISAは同日20:16ごろにこの脆弱性をKEVに追加しました。

CISAは別のアラートで、パッチを適用する前に侵害の有無を確認するよう組織に呼びかけました。Citrixも同日にセキュリティ情報を公開しています。これは、大手ベンダー、ゼロデイ、エッジデバイスがそろったときのパターンです。被害者は大規模な組織で、ニュースはまず実務者の間で「何かがおかしい」という形で広まります。その後、ベンダーの告知、CVE、KEVが1日以内に出そろいます。Xは26時間早かったものの、その内容は未検証のうわさでした。「ログを確認する」プレイブックを始めるには十分ですが、結論を出すには不十分です。

Plex2Shell：ベンダーは早く伝えていたが、誰も気付かなかった。Plexは9月1日18:30 UTCにフォーラムで告知を投稿しました。告知には、バージョン1.43.3で複数のセキュリティ問題を修正したこと、CVEを申請済みであることが書かれていました。この告知の閲覧数は現在86,684回です。しかし、9月1日〜22日の期間でXをplex "security update"で検索しても、見つかった投稿は1件だけでした。

CVE（CVE-2026-96652など）は9月23日に公開されました。ACNのアドバイザリー（ACNはイタリアの国家サイバーセキュリティ機関）では、各CVEのスコアは4.3や6.5（CVSS 3.1）など中程度です。そのため、注目する人はほとんどいませんでした。

転機は10月16日でした。ある研究者が、4件の脆弱性がどのように連鎖するかを詳しく分析して公開したのです。10月17日には、別の研究者のハニーポットが悪用を記録しました（その研究者のブログ）。「Plex2Shell」を含む最初のX投稿は10月18日15:59で、CISAは10月20日にこれらのCVEを追加しました。この事例からわかるパターンは、スコアの低い脆弱性を組み合わせたリスクが、分析の公開後に初めて明らかになったこと、そして最初の公開シグナルがベンダー自身の告知だったことです。監視では「重要なセキュリティアップデート、詳細は後日」のような表現も読み取る必要があります。Reddit（r/unRAID、コメント109件）での被害報告は、KEV登録後の10月21日に投稿されました。

PHP2Shell：Xで最も注目を集めたが、KEVには未登録。10月20日、PHPチームは2件の重大な脆弱性の修正を告知しました。CVE-2026-109618を含む最初のXの投稿は10月20日18:56 UTCで、修正とCVEの公開（CVE.orgによると10月21日13:48 UTC）の約19時間前でした。1回の検索だけでも、10月21日14:00にエンバーゴが解除される前の投稿がすでに68件ありました。AWSの脅威インテリジェンスチームはブログ記事で、同社のハニーポットネットワークが公開の4日前の10月17日に悪用の試みを観測したと報告しています。EUの機関であるCERT-EUも、この事例をアドバイザリーに記録しています。

しかし、10月26日にKEVカタログを確認したところ、バージョンは2026.10.23のままで、これらのIDは含まれていませんでした。10:52 SGTに10月20日〜23日の期間で行った検索では上限の200件が返され、今回も期間の終了日は厳密には適用されませんでした。この事例から、ソーシャルプラットフォーム上での注目度とKEVへの登録は連動しないことがわかります。KEVには実環境での悪用を示す信頼できる証拠が必要で、ハニーポットへの攻撃の試みだけでは足りない場合があります。PHP2Shellのような脆弱性では、KEVを待たずに、自組織での露出状況に基づいて修正の予定を立ててください。

4つの事例を並べてみると、結論は「ソーシャルプラットフォームは役に立たない」ではありません。最初の公開シグナルは、最初の被害者が声を上げる場所に現れます。セルフホストで運用する小規模な組織は、プロジェクトのIssueトラッカーやユーザーフォーラムを使います。大規模な組織の実務者は、ソーシャルプラットフォームで互いに情報を求めます。ベンダーはフォーラムやリリースノートで控えめに警告し、研究者はブログやリポジトリで公開します。CVE IDによる購読でカバーできるのは、これらすべての後に来る情報だけです。

シグナルから対応へ：1日1回実行するプロセス

ステーション1はソースの監視です。リストに載せるのはCVE IDではなく、richdocumentscode、Plex Media Server、NetScalerなど、自組織で運用しているコンポーネント名です。各コンポーネントには3種類のソースがあります。1つ目はプロジェクトのIssueトラッカーとリリースです（GitHubには新しいIssueとリリースを取得できる無料のAPIがあります）。2つ目はベンダーのフォーラムやセキュリティ告知ページ（多くのフォーラムはJSONを返すDiscourseで運用されています）、3つ目はいくつかのソーシャルプラットフォームでのキーワード検索です。KEVのJSONやCVEの説明は確認と期限の把握に使うもので、監視の出発点ではありません。

このケースでは、richdocumentscodeのIssueトラッカーを毎日確認していれば、9月11日にIssueのタイトルに「Hack」とあるのに気づけたはずです。これは、IDベースのどの購読よりも1か月早い時点です。この監視のコストは、コンポーネントごとに1日1回の無料のAPI呼び出しです。得られる価値は、32.5日早く検知できることです。

ステーション2は証拠の保存です。各生レスポンスを編集せず、リクエストパラメータ、UTC時刻、ファイルハッシュとともに保存します。理由は2つあります。第一に、BOD 26-04が求めるフォレンジックトリアージやインシデントレポートで、後から「いつ把握したのか」に答えられる必要があります。第二に、プラットフォーム上のコンテンツは変わります。投稿は削除され、コメントは編集され、要約には誤りが含まれます。Censysの日付の食い違いに気付けたのも、保存しておいたIssueの本文に立ち返ったからです。

ステーション3は資産の照合です。インベントリはCVE IDではなくコンポーネント名で照合してください。8月のPatchless Windowの中央値は39.2日で、その間はIDが存在しないためです。照合にはデプロイ形態も含める必要があります。この脆弱性の影響を受けるのは組み込みのCODEアプリのみで、スタンドアロンのCollaboraは安全です。「Collaboraを使っているか」で照合すると誤検知が多発します。さらに悪いことに、その中に埋もれて、本当に影響を受ける1台のサーバーを見落とすおそれがあります。

ステーション4はノイズの除去です。各項目をテスト3の6分類でラベル付けします。リポスト、ボット、宣伝、攻撃手法を紹介する投稿は対応キューから外しますが、後で確認できるようアーカイブには残します。今回のテストでは、XでIDを検索した結果の93.4%が除外され、CVE公開前の製品名による検索結果は100%が除外されました。ルールでは、言語をまたいだ単語の衝突（イタリア語の「collabora」）、アカウントファーム（8アカウント、2秒）、フォーラム上の「無料セルフテスト」リンクにも対応する必要があります。

ステーション5は対応です。Collaboraのアドバイザリでは、無効化だけでは不十分なため、26.4.303へのアップグレードかアプリの削除を求めています。サポート終了済みのNextcloud 29以前を運用している場合は、Nextcloudをアップグレードするかアプリを削除してください。

Nextcloudフォーラムの4番目の投稿には、実用的な確認方法が書かれていました。アップグレード後、Nextcloudの整合性チェックがアプリフォルダ内の「余分なファイル」を報告したというものです。イタリアのCSIRTは、Webシェルの設置と認証情報の窃取に言及しています。そこで、9月10日以降に公開状態だったインスタンスについては、さらに3つの対応をおすすめします。整合性チェックを実行し、アクセスログを確認し、Webサーバーが読み取れるパスワードをローテーションしてください。

ここで説明するのはこうした防御側の対応のみで、攻撃リクエストの内容には触れません。整合性チェックが重要なのは、攻撃者がすでに設置したファイルはパッチでは削除されないためです。パッチ適用済みのサーバーにも、バックドアが残っている可能性があります。KEVのエントリが修正に加えてフォレンジックトリアージを求めているのはこのためです。

ステーション6はケースのクローズです。各ケースでは、誰が、いつ、どの証拠（アーカイブ内の生レスポンスへの参照）に基づいて、何をしたかという4つの問いに答える必要があります。KEVにこの脆弱性が追加されたら、その期限とクローズ時刻を比較します。以下の表は推奨する最低限の記録フィールドで、今回のテストではそのすべてを使用しました。

コスト：50コンポーネントを1か月監視する場合

10月26日10:13（SGT）に機能カタログを確認しました。料金は料金ページを基準としています。twitter/search、reddit/search、youtube/search、linkedin/search、threads/searchはいずれも1リクエストあたり$0.000556です。weibo/searchは1リクエストあたり$0.000806です。課金は結果件数ではなくリクエストごとです。また、CVE公開前の投稿を探すため、EveryInfraの検索をquickの深さ（1回$0.000694）でWebとフォーラムに対して3回実行しましたが、3回とも結果は0件でした。

インターネットに公開されたコンポーネントが50個ある小規模チームで、コンポーネントごとに1日1回ずつXとRedditを検索する場合を考えます。1日あたり100リクエスト × $0.000556 = $0.0556で、30日では$1.668です。GitHub issues API、Discourseフォーラム、NVD、CVE.org、KEV、EPSSは無料の公開APIなので、このコストには含まれません。

空の結果と失敗したリクエストは課金されません。60件のリクエストのうち、6件がレート制限（ステータス429）に達し、1件はパラメータの誤り（ステータス422）、1件は空の結果でした。これら8件はいずれも課金されていません。課金されたのは52リクエスト（$0.029576）で、ヒーロー画像とイラスト1点に別途$0.06かかりました。

ループは1時間ごとに回すべきでしょうか。同じ50コンポーネントで1時間ごとに実行すると1日2,400リクエストとなり、1日$1.3344、月に約$40.03です。これは日次の24倍のコストで、検知が早まるのは1日未満です。今回のケースでは最初のシグナルがCVEの32.5日前に出ていたため、この規模では日次と毎時の差は問題になりません。毎時の監視が適しているのは、CVEとKEVが1日以内に出るNetScalerのようなエッジデバイスのゼロデイです。その対象リストは通常短いので別に管理し、全体のリストは日次のままにしてください。

コードやAIクライアントで同じデータを取得する

XをIDで検索するcurlリクエストの例（キーはプレースホルダーです）：

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer <API Key>" \
  -H "Content-Type: application/json" \
  -d '{"platform":"twitter","action":"search","params":{"keyword":"CVE-2026-110447","sort":"latest","limit":200}}'

この記事で使用している各レスポンスフィールドは、カタログにあるtwitter/searchのresponse_fieldsと照合済みです。

Redditには、keywordとsortパラメータ（newest、relevanceなど）を指定してreddit/searchを使います。よく使うフィールドはcommunity、comment_count、posted_atです。検索対象期間は常に直近1か月です。30日を超える履歴が必要な場合は、その時点で結果をアーカイブしてください。

Claude Codeから同じ検索を実行するには、クイックスタートでキーを取得し、リモートMCPサーバーを追加します。

claude mcp add --transport http everyinfra https://api.everyinfra.com/mcp \
  --header 'Authorization: Bearer ${EVERYINFRA_API_KEY}'

あとは「everyinfra_call_apiを使って、XでrichdocumentscodeとCVE-2026-110447を検索し、2026-10-14 02:27 UTCを境に投稿を分けて」と1回指示するだけです。続けて、組織アカウントと個人アカウントを分けて一覧にするよう依頼することもできます。回答には、上の表と同じposted_atとauthor_usernameフィールドが使われます。

このテストで確認したエラーと課金結果は次のとおりです。Redditのsortに存在しない値oldestを指定すると、レスポンスは422 invalid_valueでした。エラーには許可されるすべての値が列挙され、「Nothing was charged」と記載されていました。同じテストキーで他のリクエストが1分あたり10回の上限を使い切ったときは、retry_afterの値を含む429 rate_limitedが返されました。こちらも課金されず、retry_afterに10秒を加えた時間が経過してからの再試行はすべて成功しました。

同期リクエストで結果が空の場合は、200とともにcount 0が返され、billing.reasonはempty_result_refundedになり、課金されません。1行ずつ照合する方法は失敗時の返金と照合をご覧ください。X検索で上限件数ちょうどの結果が返った場合、最も古い投稿が切り捨てられている可能性がありますが、レスポンスにはエラーが表示されません。countと上限をご自身で比較してください。

過去60日間の動きと関連研究

2026年10月23日：CISAがCVE-2026-110447を追加。期限は3日後で、フォレンジックトリアージも必要。CISAのアラートをご覧ください。実務上は、KEVエントリのforensicTriage: Yesフィールドに専用のルールを設けるべきです。これは「パッチ適用後に、侵害されていないかを確認すること」を意味します。

2026年10月21日：PHP2Shellが公開され、AWSは悪用がその4日前に始まっていたと発表。上記の比較事例をご覧ください。調査では、既知の最初の悪用時点から過去に遡ってください。アドバイザリの公開日から時系列に沿って追い始めないでください。

2026年10月20日：CISAが6件の脆弱性を一度に追加し、うち4件はPlex2Shell。実務上は、スコアの低い脆弱性でも連鎖するとKEVに載ることがあります。単一のCVSSスコアによるフィルタではこれを見逃します。

2026年10月14日：CollaboraがCVE申請キューに原因があるとし、CNAへの登録を申請。実務上は、オープンソースプロジェクトがCNAになればIDの発行は早まります。それまでは、IDによる購読では1か月遅れることもあります。

2026年10月：Second SecurityがPatchless Window調査を公開。8月には、公開された修正からCVEが公開されるまでの期間の中央値が39.2日でした。実務上は、IDの発行を待たず、コミット、リリース、issueを通じてオープンソースコンポーネントを監視してください。

2026年9月25日：arXivの論文が、GitHub上のエクスプロイトリポジトリのスター数、フォーク数、ユーザー数に基づく優先度指標GPMを提案（arXiv 2609.31004）。論文によると、GPMはEPSSバージョン5に組み込まれています。実務上は、公開リポジトリの活動が正式なスコアリングの一部になったことを意味します。ただし、今回のシグナルはエクスプロイトコードではなくissueトラッカー上の被害報告だったため、この指標ではカバーされません。

2026年8月19日：運用中の脅威ナレッジグラフを、脅威関連のソーシャル投稿10,000件と比較した研究（Information誌）。グラフには投稿に含まれる対応可能な脆弱性の96%がすでに登録されており、報告も同等以上に早いものでした。ソーシャルメディアが先行したのは、実際の悪用に関する早期警告だけでした。実務上、この研究は今回の結果と一致します。ソーシャルデータの価値はCVEの網羅性ではなく、少数の被害報告や噂にあります。

2026年8月：STINER研究がX上のアラートを使って欧州の脅威状況を分析（arXiv 2608.14418）。国によって、攻撃のX上での見えやすさが大きく異なることがわかりました。ソーシャル監視では、言語と地域は常に考慮すべき変数です。今回の事例では、KEV登録前にX上にあった一次報告は日本語の投稿1件だけでした。手法の背景として、2015年のUSENIX Securityの論文では、すでにTwitterの投稿を使った実環境での悪用の予測が試みられています。

本記事の限界

第一に、主な事例は1件だけで、比較事例はそれぞれ1回しか検索していません。悪用されなかった脆弱性の対照群がないため、誤検知率は算出できません。また、「ハッキングされた」というissueがすべて実在の脆弱性を示すとは言えません。今回issueのシグナルが信頼できたのは、ログがあり、複数の人が同じ現象を確認し、メンテナーが3日以内に返信したからです。ほかのissueがこの3点をすべて満たすとは限りません。

第二に、X検索はランク付けされたサンプルを返します。今回のID検索では106件の投稿が返り、上限には達しませんでしたが、X上にそれより古い投稿がないことは証明できません。untilによる日付の制限は、これを使った4回のリクエストのいずれでも厳密には適用されなかったため、posted_atでフィルタしました。Reddit検索の対象は直近1か月のみのため、9月10日から25日までのRedditは確認できませんでした。10月14日より前のreddit.comを対象にした一般的なWeb検索では、古いセットアップに関する質問しか見つからず、侵害の報告はありませんでした。

第三に、ノイズのラベル付けは事前に定めたルールで1回だけ行い、2人目のラベル付け担当者はいませんでした。「シグナル」と「転載」の線引きには、ある程度の判断が入ります。たとえば、アドバイザリをチェックリストに書き直した投稿は転載として数えましたが、別の人ならシグナルとして数えるかもしれません。

第四に、SSVCとEPSSに関する観察は、説明文ですでに脆弱性が悪用されていると記載されている状況にのみ当てはまります。「これらのフィールドは常に遅い」とまで一般化しないでください。EPSSは確率を推定するものであり、KEVの内容を繰り返すことが目的ではありません。

FAQ

CISAが脆弱性をKEVに追加するとは、どういう意味ですか？

その脆弱性にCVE IDが付与され、実環境での悪用を示す信頼できる証拠があり、明確な修正ガイダンスが用意されていることを意味します。BOD 26-04に基づき、連邦機関はエントリに記載された期限までに修正する必要があります。今回の期限は3日後で、フォレンジックトリアージも必要でした。KEVへの追加は必ずCVEの公開後になります。今回はCVEの9.7日後、最初の公開報告の42.2日後でした。（検索候補「cisa kev meaning」より）

EPSSとCISA KEV：優先順位付けにはどちらを使うべきですか？

両者は異なる問いに答えるものです。KEVは悪用が確認されたことを示し、EPSSは今後30日間に悪用が観測される確率を推定します。今回の事例では、KEV登録前の10日間、EPSSは1.2%のままでした。サンプル内でデータのあるKEV登録CVE 12件では、KEV登録前日のEPSSスコアがすべて10%未満でした。並べ替えには両方を使い、「exploited in the wild」に対するテキストルールを追加してください。（検索候補「epss vs cisa kev」より）

NextcloudのCollabora脆弱性はどう修正すればよいですか？

「Collabora Online - Built-in CODE Server」アプリを26.4.303にアップグレードするか、削除してください。無効化だけでは不十分です。Nextcloud 29以前を使っている場合は、Nextcloudをアップグレードするか、アプリを削除してください。スタンドアロンのCollaboraサーバーは影響を受けません。インスタンスが外部に公開されていた場合は、整合性チェックの実行、ログの確認、認証情報のローテーションも行ってください。（検索候補「nextcloud collabora vulnerability fix」より）

関連記事

• プラットフォームページ：X (Twitter)スクレイピングAPI、RedditスクレイピングAPI、WeiboスクレイピングAPI
• 機能ページ：X検索、Reddit検索、YouTube検索、LinkedIn検索、Threads検索、Weibo検索
• 同じシリーズ：プロダクトとしての脆弱性インテリジェンス、パンプ・アンド・ダンプのソーシャルシグナル、研究サンプルとしてのソーシャルデータ

参考文献

1. CollaboraOnline/richdocumentscode、GitHub Issue #354「Security issue - Hack」、2026年9月11日、https://github.com/CollaboraOnline/richdocumentscode/issues/354
2. CollaboraOnline/richdocumentscode、リリース26.4.303、2026年9月11日、https://github.com/CollaboraOnline/richdocumentscode/releases/tag/26.4.303
3. GitHub、Issues用REST APIエンドポイント、2026年10月26日閲覧、https://docs.github.com/en/rest/issues/issues
4. Nextcloudコミュニティフォーラム、「To Collabora Built-in User: Update ASAP」、2026年10月3日、https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516
5. Discourse、APIドキュメント、2026年10月26日閲覧、https://docs.discourse.org/
6. CVE Program、CVE-2026-110447のレコード、2026年10月14日、https://www.cve.org/CVERecord?id=CVE-2026-110447
7. CVE Services API、CVE-2026-110447のレコードメタデータ、2026年10月26日閲覧、https://cveawg.mitre.org/api/cve/CVE-2026-110447
8. NIST NVD、CVE-2026-110447の詳細、2026年10月14日公開、2026年10月24日更新、https://nvd.nist.gov/vuln/detail/CVE-2026-110447
9. NIST NVD、CVE Change History API、2026年10月26日閲覧、https://nvd.nist.gov/developers/vulnerability-change-history
10. Collabora Online、セキュリティアドバイザリGHSA-g3vx-3m76-fghh、2026年10月14日、https://github.com/CollaboraOnline/online/security/advisories/GHSA-g3vx-3m76-fghh
11. Collabora Online、「Stay Safe: Upgrade Everything Regularly」、2026年10月14日、https://www.collaboraonline.com/blog/stay-safe-upgrade-everything-regularly/
12. Censys、「Oct 16 Advisory: Collabora Online Built-in CODE Server OS Command Injection」、2026年10月16日、https://censys.com/advisory/cve-2026-110447/
13. CISA、Known Exploited Vulnerabilities Catalog、2026年10月26日閲覧、https://www.cisa.gov/known-exploited-vulnerabilities-catalog
14. CISA、KEV JSONフィード（バージョン2026.10.23）、2026年10月26日閲覧、https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
15. CISA、「Reducing the Significant Risk of Known Exploited Vulnerabilities」（KEVの基準）、2026年10月26日閲覧、https://www.cisa.gov/known-exploited-vulnerabilities
16. Second Security、「The Patchless Window」、2026年10月、https://thepatchlesswindow.com/
17. BleepingComputer、「Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers」、2026年10月15日、https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/
18. NIST、「NIST Updates NVD Operations to Address Record CVE Growth」、2026年4月15日、https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth
19. Hacker News、Algolia検索API、2026年10月26日閲覧、https://hn.algolia.com/api
20. Hacker News、「Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers」のリンク投稿、2026年10月15日、https://news.ycombinator.com/item?id=50111052
21. Reddit r/NextCloud、管理者による報告「Nextcloud compromised via the built-in Collabora app」、2026年10月22日、https://www.reddit.com/r/NextCloud/comments/1xcsjlx/nextcloud_compromised_via_the_builtin_collabora/
22. cisagov、Vulnrichmentリポジトリ、2026年10月26日閲覧、https://github.com/cisagov/vulnrichment
23. FIRST、EPSSのよくある質問、2026年10月26日閲覧、https://www.first.org/epss/faq
24. CISA、BOD 26-04: Prioritizing Security Updates Based on Risk、2026年6月10日、https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
25. FIRST、EPSS「Get the Data」（APIを含む）、2026年10月26日閲覧、https://www.first.org/epss/data
26. CISA、Stakeholder-Specific Vulnerability Categorization（SSVC）、2026年10月26日閲覧、https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
27. CISA、「Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway」、2026年9月27日（10月9日更新）、https://www.cisa.gov/news-events/alerts/2026/09/27/critical-zero-day-vulnerabilities-exploited-citrix-netscaler-adc-gateway
28. Citrix、セキュリティ情報CTX697096、2026年9月27日、https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX697096
29. NIST NVD、CVE-2026-88771の詳細、2026年9月27日、https://nvd.nist.gov/vuln/detail/CVE-2026-88771
30. Plexフォーラム、「Important Security Update for Plex Media Server v1.43.2 and earlier」、2026年9月1日、https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
31. Agenzia per la Cybersicurezza Nazionale（ACN）、「Plex Media Server: rilevato sfruttamento in rete delle catena di attacco Plex2Shell」、2026年10月、https://www.acn.gov.it/portale/w/plex-media-server-rilevato-sfruttamento-in-rete-delle-catena-di-attacco-plex2shell
32. boredhackerblog、「Plex vulnerabilities being exploited in the wild to drop a cryptominer」、2026年10月17日、https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html
33. CISA、「CISA Adds Six Known Exploited Vulnerabilities to Catalog」、2026年10月20日、https://www.cisa.gov/news-events/alerts/2026/10/20/cisa-adds-six-known-exploited-vulnerabilities-catalog
34. NIST NVD、CVE-2026-96652の詳細、2026年9月23日、https://nvd.nist.gov/vuln/detail/CVE-2026-96652
35. AWS Security Blog、「Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot」、2026年10月21日、https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
36. CERT-EU、セキュリティアドバイザリ2026-018「Critical Vulnerabilities in PHP」、2026年10月20日、https://cert.europa.eu/publications/security-advisories/2026-018
37. NIST NVD、CVE-2026-109618の詳細、2026年10月21日、https://nvd.nist.gov/vuln/detail/CVE-2026-109618
38. CISA、「CISA Adds One Known Exploited Vulnerability to Catalog」（CVE-2026-110447）、2026年10月23日、https://www.cisa.gov/news-events/alerts/2026/10/23/cisa-adds-one-known-exploited-vulnerability-catalog-0
39. Akhoundaliほか「GitHub Engagement Signals for CVE Prioritization: The GitHub Popularity Metric (GPM)」、arXiv 2609.31004、2026年9月25日、https://arxiv.org/abs/2609.31004
40. 「Time-Series and Social-Media Threat Analytics over a Deployed Cyber-Threat Knowledge Graph」、Information 17(8):794、2026年8月19日、https://www.mdpi.com/2078-2489/17/8/794
41. Ech-Chammakhyほか「STINER: Automated Extraction of Strategic Cyber Threat Intelligence from X」、arXiv 2608.14418、2026年8月14日、https://arxiv.org/abs/2608.14418
42. Sabottke、Suciu、Dumitraș「Vulnerability Disclosure in the Age of Social Media: Exploiting Twitter for Predicting Real-World Exploits」、USENIX Security 2015、https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/sabottke
43. Xヘルプセンター「How to use advanced search」、2026年10月26日閲覧、https://help.x.com/en/using-x/x-advanced-search
44. NIST NVD、CVE APIドキュメント、2026年10月26日閲覧、https://nvd.nist.gov/developers/vulnerabilities
45. The Hacker News、「Hackers Backdoor Nextcloud Servers Through Critical Flaw in Collabora’s Built-in CODE App」、2026年10月、https://thehackernews.com/2026/10/hackers-backdoor-nextcloud-servers.html