CVE-2026-102331とは？Chromeの脆弱性対策とAIによる発見・悪用事例を解説

執筆：オレンジソフトウェア 藤田
情報確認日：2026年9月30日（主要な出典を2026年10月2日に再確認）

※本記事は、2026年9月30日時点で筆者が確認できた公開情報をもとにまとめたものです。できる限り正確を期していますが、誤りや、その後の更新で古くなった情報が含まれる可能性があります。対応を判断する際は、本文中のリンク先にある公式情報で最新の内容をご確認ください。

こんにちは、オレンジソフトウェアの藤田です。

最近は、ローカルで動かすLLMを、いろいろな作業をお願いできる「AIエージェント」として使うための研究開発をしています。

オープンソースのNextcloudと、ローカルLLM、画像生成エンジンなどを連携させて、例えば「共有フォルダにある契約書を全部読んで、概要をまとめて」とお願いしたり、「猫の画像を作って、このフォルダに保存して」と頼んだり。契約書の確認から猫の画像づくりまで、なかなか幅広く働いてもらっています（笑）。

こうした仕組みを、詳しい知識がなくても日常の言葉で使えるサービスにしようと、使い勝手を整えているところです。

そんな開発をしていることもあり、最近の情報漏えいや脆弱性のニュースは、やはり気になります。身近なところでは、タイムズカーの情報漏えいがありました。9月29日の公式発表では、運転免許証画像などの本人確認書類が漏えいしたアカウントは約160万件と報告されています。タイムズカー公式発表・第3報

実は、私もタイムズに登録しています。「自分の情報も漏れているかもしれない」と思うと、急にニュースが身近になります。私自身が対象かどうかは確認できていませんが、サービスを利用する立場としても、作る立場としても、他人事ではありません。

なお、参照したタイムズカーの公式発表は、AIの関与を示しているものではありません。この事件をAIによる攻撃と結びつけることはできませんが、情報を扱う仕組みの安全性を改めて考えるきっかけになりました。

私たちが作っているような、AIにファイルを読ませたり、操作を任せたりするサービスでも、「どの情報まで読ませてよいのか」「どの操作まで任せるのか」をきちんと決める必要があります。便利にできることが増えるほど、その設計も大切になると感じています。

一方で、AIには、ソフトウェアの脆弱性を見つけて修正を助ける役割も期待できます。同じ能力が攻撃に利用される可能性もあるからこそ、実際に何が起きているのかを確かめておきたいところです。

今回は、Chromeの脆弱性とAIによる発見・悪用の事例を整理しながら、開発現場での問題意識も交え、オレンジソフトウェアの独自の視点で解説します。

この記事で伝えたいこと

• Android版Chromeの深刻な脆弱性に対する修正版が出ています。まずは更新を確認してください。
• AIはすでに、脆弱性の発見・修正を支援する側でも、攻撃に使う側でも利用されています。
• 見つかった問題を早く確実に直すこと、そしてAIに任せる権限や操作の範囲を決めておくことが大切になります。

まず確認を：Android版Chromeの深刻な脆弱性（CVE-2026-102331）

Googleは2026年9月29日付の安定版アップデート情報で、グラフィックス処理に関わる部品「ANGLE」の脆弱性（CVE-2026-102331）の修正を公表しました。Googleによる深刻度評価は「Critical」です。Google公式の更新情報・同月の公式更新一覧

公式CVE記録の説明によると、対象はAndroid版Chromeの154.0.8037.92より前のバージョンです。細工されたHTMLページを開くと、ブラウザーの処理を隔離する仕組み（サンドボックス）の外で不正なコードを実行されるおそれがあります。CISAが補足したCVSS v3.1のスコアは9.6です。確認した記録では、CISAのSSVC評価の悪用状況は「none」とされています。ただし、これは悪用が一切起きていないことを保証するものではありません。公式CVE記録

GoogleはAndroid向け154.0.8037.92を公開し、Google Playを通じて数日かけて配信すると案内しています。また、特記がない限り、対応するデスクトップ版と同じセキュリティ修正が含まれるとしています。Android版の公式更新情報

154.0.8037.92は、この脆弱性の修正を含むバージョンとして紹介しています。現在の最新版を意味するものではありません。端末に提供される最新の安定版へ更新してください。

やっていただきたいこと： Google PlayでChromeを更新してください。更新後は、Chromeの「設定」→「Chromeについて」で、154.0.8037.92以降のバージョンになっていることを確かめてください。更新がまだ表示されない場合は、時間をおいて再度確認してください。Android版Chromeの更新方法

PC版にも同日付の更新で多数の修正が含まれています。Windows・Mac向けには154.0.8037.92/.93が案内されているため、こちらも更新を確認しましょう。Google公式の更新情報

なお、CVE記録の構造化されたバージョン欄では、versionとlessThanに同じ154.0.8037.92が指定されており、説明文と整合しません。本記事では、説明文とGoogleの更新情報を照合して対象範囲を記載しています。

この脆弱性の報告者は「@mfx」とされており、AIが発見したとの記載はありません。一方、確認できた同日の公式更新一覧には32件のセキュリティ修正が案内され、V8の「High」評価の3件（CVE-2026-102323、CVE-2026-102326、CVE-2026-102328）では、報告者欄に「OpenAI Codex Security」と記載されています。ただし、この表記だけで、AIが単独で発見したことや、具体的な自動化の範囲までは判断できません。Google公式の更新一覧

では、AIの関与が具体的に説明されている発見事例には、どのようなものがあるのでしょうか。

AIが脆弱性の発見に関与した事例

ここでは、「問題を発見したこと」と「攻撃に悪用されたこと」を分けて見ていきます。脆弱性が見つかったという発表だけでは、それが犯罪に使われたとは言えないからです。

件数は調査範囲や評価方法がそれぞれ異なるため、単純な性能比較には使えません。それでも、長年にわたって厳しく検査されてきたソフトウェアから問題を見つけ、修正につなげる事例が出てきていることに、開発する側として注目しています。

実際の攻撃でAIが使われた事例

一方で、AIを悪用した攻撃も報告されています。以下は、各社が自社の観測や調査に基づいて公表した事例です。

Googleが同じ報告で取り上げたPROMPTFLUXやPROMPTLOCKは、実験的なものとして分類されています。「実験で動いた」ことと「実際の攻撃で観測された」ことは、分けて考える必要があります。Google GTIG

これらの事例から私たちが特に注目しているのは、攻撃に必要な調査や作業の負担が下がる点です。まったく新しい攻撃手法が生まれるケースばかりではありません。更新されていないソフトウェアや流出した認証情報のように、以前からある弱点を探して突く作業も効率化されています。小規模なサービスであっても、更新や認証情報の管理を後回しにしないことが大切だと考えています。

見つかる脆弱性が増えることは、安全性の向上にもつながる

脆弱性の公表件数が増えると、「ソフトウェアが以前より危険になった」と感じるかもしれません。しかし、以前から存在していた問題を見つけられるようになった結果である可能性もあります。

Mozillaの事例は、AIの発見能力を製品の修正につなげたものです。同社は、こうした能力が防御側に広がれば、これまで攻撃者が持っていた長期的な優位を縮められると評価しています。Mozillaの見解

ただし、問題を見つけた時点で安全になるわけではありません。指摘が正しいかを確かめ、修正を作り、動作を検証し、利用者の環境に適用するところまで進めて、その脆弱性によるリスクを下げられます。

この過程を考える材料になるのが、Anthropicの脆弱性開示ダッシュボードです。2026年8月26日時点の集計は、次のようになっています。公式ダッシュボード

これらは同じ確度・同じ段階の数字ではありません。「約2.6万件の確定した脆弱性のうち421件しか直っていない」という比較はできません。また、開発元での修正は、修正版の配信や利用者による適用まで完了したことを示しません。集計の定義

VulnCheckも公開台帳を独自に分析し、修正済みの記録として202件を数えています。ただし、これは同社が分析した台帳の範囲における数字です。公式の421件と対象範囲や更新時点をそろえずに比較して、どちらかが誤りだとは判断できません。VulnCheckの分析

累計件数の差だけでは、発見と修正それぞれの速度や、未対応の理由までは分かりません。一方、Anthropic自身は、人による独立した精査・レビューが報告のペースを制約していると説明しています。公式ダッシュボード

オレンジソフトウェアでは、AIが問題を見つける速さに加えて、「見つかった問題を、どれだけ早く確実に直せるか」がますます重要になると考えています。

AIによって指摘が増えても、確認や修正の体制が整っていなければ、対応待ちが増える可能性があります。発見の自動化とあわせて、優先順位の判断、修正、検証、更新という流れを整えておく必要があります。

AIを業務のサービスにする現場で、私たちが考えていること

ここで、冒頭のNextcloudとAIの連携の話に戻ります。サービスとして使いやすくしていくために、私たちが考えているのが、AIに任せる情報や操作の範囲です。

例えば「契約書を全部読んで要点をまとめて」とお願いできる機能は便利です。しかし、その「全部」は、依頼した人が閲覧してよい範囲に限られていなければなりません。本人には見えない契約書が、AIを経由すると読めてしまう設計では困ります。

また、「猫の画像を生成して保存する」操作と、「既存の契約書を上書きする」「共有範囲を変える」操作とでは、間違えたときの影響が違います。どの操作までAIに任せ、どこで人の確認を挟むかを、分けて考える必要があります。

サービスとして整えていくうえで、私たちは次の点を重視しています。

これらは、研究開発中のサービスで検討している設計上の考え方です。

ローカルでAIを動かす構成には、データを処理する場所を自分たちで管理しやすいという利点があります。ただし、実際に情報がどう扱われるかは、連携先や設定によって変わります。LLMをどこで動かすかだけでなく、ファイルへのアクセス、保存先、ログ、外部との通信まで含めて確認することが欠かせません。

契約書を読ませる機能であれば、「うまく要約できたか」だけでなく、「読んでよい文書だけを扱ったか」「要約が原文と合っているか」まで確かめたいところです。ここが、AIを業務で使えるサービスにするうえで大事な部分だと感じています。

企業として、まず見直したいこと

AIによる変化に備えるためにも、まずは日々の運用を具体的にしておくことが大切です。

1. 使っている製品とバージョンを把握する。 脆弱性が公表されたときに、自社に影響があるかどうかを判断できる状態にしておきます。
2. 更新の優先順位と担当者を決める。 深刻度、悪用の有無、外部に公開しているかどうか、業務への影響を確認して判断します。
3. 更新したあとまで確認する。 更新の案内を出して終わりにせず、実際に適用されたかと、主要な機能が正しく動くかを確かめます。
4. 認証情報と権限を管理する。 多要素認証を使い、不要な権限を減らし、流出した認証情報は速やかに無効にします。
5. AIの指摘は検証してから修正につなげる。 指摘の件数だけを成果にせず、再現できるか、影響はどの程度か、修正で直ったかを確認します。

AIに任せられる仕事の範囲が広がっていくのは、開発している立場としても面白いところです。同時に、そのAIが触れる情報や実行できる操作の範囲は、きちんと決めておきたいと考えています。

オレンジソフトウェアは、日常の言葉で使える便利さと、権限や操作の結果を確認できる仕組みを両立できるよう、研究開発を進めていきます。猫の画像づくりも契約書の整理も、業務の中で安心して任せられる形にしていきたいですね。