Google、AIで開発された可能性の高いゼロデイ脆弱性を確認|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年05月13日更新日時: 2026年05月13日

Google Threat Intelligence Groupは2026年5月12日、AI関連の脅威動向をまとめたレポートで、攻撃者がAIを使って開発したと考えられるゼロデイエクスプロイトを初めて確認したと公表しました。対象となったのは、広く使われているオープンソースのWebベース管理ツールで、攻撃者は二要素認証を回避する目的でゼロデイ脆弱性を悪用しようとしていたとされています。Googleは、影響を受けるベンダーと連携して責任ある開示を行い、攻撃活動を阻止したと説明しています

サマリー

Google Threat Intelligence Groupは、攻撃者がAIを使って開発した可能性が高いゼロデイエクスプロイトを確認したと公表しました。
対象は広く利用されているオープンソースのWebベース管理ツールで、攻撃者は有効な認証情報を前提に、2FAを回避する攻撃を試みていました。
Googleは影響を受けるベンダーと連携し、責任ある開示を通じて攻撃活動を阻止したとしています。
確認されたエクスプロイトはPythonで作成されており、コード内の説明文や実在しないCVSSスコアなどから、AIモデルが開発支援に使われた可能性が高いと評価されています。

1 何が起きたか
2 AIが使われたと判断された理由
3 脆弱性の本質はメモリ破壊ではなくロジック不備
4 攻撃者によるAI活用は実験段階から運用段階へ移行
5 情報システム部門が最初に確認すべきこと
6 認証情報の窃取を前提にした設計が必要
7 AIシステム自体も攻撃対象になっている
8 出典

何が起きたか

Googleによると、著名なサイバー犯罪グループが、ゼロデイ脆弱性を利用した大規模な悪用活動を計画していました。確認されたエクスプロイトはPythonスクリプトとして実装されており、有効なユーザー認証情報を持っていることを前提に、対象ツールの2FAを回避できる内容だったとされています。

ここで重要なのは、2FAを完全に無意味化する万能の攻撃ではない点です。Googleは、この脆弱性を2FAバイパスに分類できるとしつつも、攻撃には最初に有効なユーザー認証情報が必要だったと説明しています。つまり、IDとパスワードをフィッシングや情報窃取マルウェアなどで入手した後、追加認証をすり抜けるための攻撃だったと整理できます。

AIが使われたと判断された理由

Googleは、今回のエクスプロイトについて、Geminiが使われたとは考えていないと明記しています。

一方で、スクリプトの構造や内容から、攻撃者が何らかのAIモデルを使って脆弱性の発見と武器化を支援させた可能性が高いと評価しています。

根拠として、教育用の説明文のようなdocstringが多いこと、実在しないCVSSスコアが含まれていたこと、LLMの学習データに見られるような教科書的で整ったPythonコード形式が挙げられています。

この点は、AIが単にコードの整形や補助に使われたというより、脆弱性の理解、攻撃ロジックの整理、実用可能なスクリプト化まで支援した可能性を示しています。ただし、Googleの表現は、AIが使われたと断定するものではなく、構造と内容から高い確度でAIの関与を判断したというものです。

脆弱性の本質はメモリ破壊ではなくロジック不備

今回の脆弱性は、メモリ破壊や入力検証不備のような典型的な実装ミスではなく、開発者がハードコードした信頼前提に起因する高レベルなロジック不備だったとGoogleは説明しています。従来のファジングや静的解析は、クラッシュや危険な関数呼び出しの検出に強みがありますが、認証フロー上の例外処理や信頼条件の矛盾を読み解くことは簡単ではありません。

Googleは、フロンティアLLMには複雑な企業システムの認可ロジックを完全に理解するには限界があるとしつつ、開発者の意図を文脈から読み取り、2FA強制ロジックとハードコードされた例外条件の矛盾を関連付ける能力が高まりつつあると指摘しています。これは、見た目には正常に動作しているが、セキュリティ上は破綻しているロジック不備をAIが見つけやすくなっていることを示しています。

攻撃者によるAI活用は実験段階から運用段階へ移行

Googleは今回のレポートで、攻撃者によるAI利用が、初期の実験的な段階から、生成AIを攻撃ワークフローに組み込む段階へ移行していると述べています。AIは、脆弱性探索、エクスプロイト開発、マルウェア開発、偵察、ソーシャルエンジニアリング、情報操作など、攻撃ライフサイクルの複数段階で使われています。

Googleは、中国や北朝鮮に関連する活動クラスタがAIを使った脆弱性探索に強い関心を示していることも報告しています。たとえば、専門家になりすますプロンプトによってモデルを誘導したり、過去の脆弱性データを大量に取り込ませたり、OpenClawやOneClawのようなエージェント型ツールと脆弱な検証環境を組み合わせ、AI生成ペイロードの信頼性を高めようとする動きが観測されています。

情報システム部門が最初に確認すべきこと

企業の情報システム部門が今回の事案からまず確認すべきなのは、2FAを導入しているかどうかではなく、2FAがどの条件で迂回される設計になっているかです。管理画面、VPN、ID基盤、SaaS、業務アプリケーションでは、特定IP、特定端末、社内ネットワーク、既存セッション、リカバリコード、API経由アクセスなどを理由に追加認証を省略している場合があります。

その例外処理が仕様として存在すること自体は珍しくありません。しかし、例外条件がハードコードされていたり、管理者以外が到達できる導線に残っていたり、認証済みユーザーであれば追加確認なしに重要操作へ進めたりする場合、攻撃者はフィッシングで取得した認証情報と組み合わせて2FA後の壁を突破できる可能性があります。

認証情報の窃取を前提にした設計が必要

今回の脆弱性は、有効な認証情報を前提としていた点が重要です。これは、企業側の対策として、パスワード漏えい後の被害拡大をどこで止めるかが問われることを意味します。

具体的には、重要システムへのアクセスでは、フィッシング耐性のあるMFA、端末証明書、条件付きアクセス、再認証、セッション寿命の短縮、地理的に不自然なログインの検知、重要操作時の追加承認を組み合わせる必要があります。IDとパスワードが漏れた後でも、攻撃者が管理機能や機密情報に到達できない設計にしておくことが重要です。

AIシステム自体も攻撃対象になっている

Googleは、AIを攻撃者が使うだけでなく、AIソフトウェアのエコシステム自体が攻撃対象になっているとも指摘しています。特に、オープンソースのラッパーライブラリ、APIコネクタ、スキル設定ファイル、AIエージェントの拡張機能など、モデル本体の外側にある構成要素が狙われています。

企業が社内AI、チャットボット、AIエージェント、RAG基盤を導入している場合、モデルの安全性だけでなく、接続先のSaaS、認証情報、外部プラグイン、ワークフロー自動化、APIキー管理を含めて保護する必要があります。AIが業務システムに接続されるほど、攻撃者にとっては内部情報の検索、認証情報の探索、横展開の補助に使える入口になります。