公表される脆弱性の数が増え続けると、保守の担当者は「全部すぐに当てる」ことも「月に1回まとめて当てる」ことも続けられなくなります。どれを今日当て、どれを次の定期の更新に回すか、その判断の根拠が必要です。
Google Threat Intelligence Group（GTIG）は2026年9月30日、2025年1月から2026年8月までに公表された脆弱性と、実際の悪用を分析した報告を公開しました。公表の数は半年余りで約2倍になった一方、悪用が確認された割合はごくわずかで、境界に置く機器が侵入の主な入り口になっていることを示しています。
この記事では、報告の数字を確認したうえで、保守の現場でパッチの順番を決める考え方を整理します。数字はすべてGTIGの報告によるもので、リスクの評価はCVSSではなく、GTIG独自の評価です。
公表は2倍、悪用は約0.23%
報告の主な数字は次のとおりです。
- 公表の数: 2026年1月の5,045件から、7月に10,477件、8月に10,740件へ増えた
- 悪用の数: 悪用が確認された脆弱性は、2025年の月平均10.5件から、2026年1〜8月は月平均18件。1〜8月の合計141件は、2025年の通年（127件）を上回った
- 悪用の割合: 2026年に公表された脆弱性のうち、悪用が確認されたのは0.23%（約431件に1件）
- ゼロデイ: 2025年の月平均8件から、2026年は月平均11件。8月は22件だった。悪用された脆弱性のうち62%はゼロデイ
報告は、数の増え方そのものも注意して読むよう求めています。たとえば、説明に「Linux Kernel」を含む脆弱性は2026年1〜8月だけで約5,000件ありましたが、悪用が確認されたゼロデイは0件でした。採番の仕組みの都合で数が膨らむ分野もある、ということです。
公表の数だけを見て「全部を急ぐ」と、本当に急ぐべきものが埋もれます。報告も、優先順位をつけずに一律で当てるやり方から、脅威の情報にもとづく選別へ移るよう求めています。
侵入の入り口になる境界の機器
報告によると、2026年1〜8月に悪用された脆弱性のうち、14%が境界に置く機器やセキュリティ機器（報告の分類では「Edge and Security Appliances」）、11%がディレクトリや共同作業の基盤（同「Enterprise Directory & Collaboration hubs」）に関するものでした。境界の機器で悪用された脆弱性の65%超は、GTIGの評価でHigh以上で、認証なしで届く管理画面が狙われていると報告は説明しています。
ゼロデイの増え方は小さく、報告は、悪用の増加の主な源は、公表済みの脆弱性（Nデイ）を素早く攻撃に使う動きだとみています。公表から悪用までが短かった例に、BeyondTrustのPrivileged Remote AccessとRemote Supportの脆弱性CVE-2026-1731があります。報告はこれを、AIのエージェントが見つけた脆弱性が実際に悪用された例として挙げており、公表から4日以内に1つの攻撃者のグループが、7日以内にさらに5つのグループが悪用していました。同じ会社の製品で10月に公表された別の脆弱性の対応は、BeyondTrust Remote Supportのゼロデイ 修正の後に確かめることで扱っています。
AIで見つかる脆弱性と、AIの基盤の脆弱性
報告は、AIが関わる2つの変化も取り上げています。
1つは、AIの支援で見つかった脆弱性の性質です。GTIGがAIの発見と判断できたものでは、半数（50%）が遠隔からのコード実行につながるもので、脆弱性全体での割合（26%）を大きく上回りました。報告は、公開データではAIによる発見が少なく数えられている可能性があるとも述べています。
もう1つは、AIを動かす基盤そのものの脆弱性です。2025年1月から2026年8月までにGTIGが追跡したAI関連の脆弱性は2,076件で、そのうち1,500件超が2026年1〜8月の公表でした。半数はDifyやLangflow、LangChainなどのエージェントやワークフローを組む部品で、2026年に347%増えています。vLLM・Ollama・LiteLLMなどのモデルを動かす基盤では2026年に212件あり、その約4分の1（24%）は認証のないAPIや、サーバーに別の宛先へ通信させる脆弱性（SSRF）によるものでした。
AIの基盤のゼロデイの悪用はまだ確認されていないものの、公表後の悪用は始まっていて、報告はLiteLLM（CVE-2026-42271）やLangflow（CVE-2026-5027、CVE-2025-3248）の例を挙げています。社内向けに立てたAIのワークフローやゲートウェイを外から届く場所に置いている場合、それは境界の機器と同じ扱いが必要だということです。モデルのAPIキーを1か所に集めるゲートウェイの設計と注意点は、社内AIにゲートウェイを1枚挟むかで整理しています。
保守の現場での順番の決め方
ここからは編集部の提案です。報告の数字をもとに、中小企業のシステムやWebサイトの保守で使える順番の決め方を、上の図のように3段に分けました。
- 外から届くもの: VPN・ファイアウォール・リモートサポートなどの機器、管理画面、外に公開したAIのワークフローやゲートウェイ。悪用が確認された脆弱性は、定期の更新を待たずに当てる。報告は、境界の機器を侵入の主な入り口とみています
- 中にある重要なもの: 社内のサーバー、業務システム、ディレクトリ。定期の更新を基本にしつつ、悪用の確認が出たものは前倒しする
- それ以外: 端末の多くの部品や、外から届かない仕組み。定期の更新でまとめて当てる
段を決めるには、まず「外から届くもの」の一覧が要ります。どの機器やサービスがインターネットから届くか、その管理画面がどこに開いているかが分からなければ、1段目に何を置くかも決められません。悪用の確認の情報源としては、米国のCISAが公開している「悪用が確認された脆弱性」のカタログ（KEV）など、公開された一覧を使う方法があります。GTIGと同じGoogleのMandiantも、開発の基盤を守る指針の中で、検出結果の優先づけに実際の悪用の情報としてKEVを使うよう挙げています。
この順番を保守の契約や運用の手順に落とす場合、「1段目は何時間以内に当てるか」「誰が判断して、誰が当てるか」を決めておく必要があります。保守の契約で見直す点は、月次のパッチ適用が通らなくなった — 保守契約の書き直し4点で整理しました。
報告はもう1つ、ソフトウェアやサービスを提供する側に、出荷の前にAIを使ったコードの検査を社内で行い、脆弱性になる前に直すよう勧めています。自社でシステムやWebサイトを作って外部に提供している会社や、開発を委託している会社にとっては、受け入れの基準に組み込む材料になります。
確認した範囲
2026年10月28日に、Google Cloud Blogに掲載されたGTIGの報告「Vulnerability Discovery and Exploitation Trends in the AI Era」（2026年9月30日）と、KEVへの言及のためにMandiantの指針「Proactive Defense: Hardening Code Pipelines and CI/CD Infrastructure」（2026年9月24日）を確認しました（資料調査）。2026年10月29日に、報告の数字を原文と照合し直し、CISAのKEVの公開データ（JSON、10月28日版）も確認しました。数字はすべてGTIGの報告の記載で、編集部は元のデータを確認していません。報告のリスクの評価はGTIG独自のもので、CVSSの深刻度とは異なります。3段の分け方は、報告の数字をもとにした編集部の提案で、報告が示した手順ではありません。
システムやWebサイトの保守の体制、パッチの運用の見直しは、開発・AI・自動化のご相談からお問い合わせください。
