Chromeに脆弱性370件、更新1回で解消 CVE-2026-17650ほか151.0.7922.71へ

Googleが2026年7月29日、パソコン向けのChrome 151（151.0.7922.71／.72）を配信し、370件の脆弱性をまとめて修正しました。公式の告知には「This update includes 370 security fixes.」と書かれています。

370件と聞くと身構えますが、いまのところ実際に攻撃に使われたものは1件も報告されていません。やることは、Chromeを開いてメニューから更新し、再起動するだけです。この記事では、更新の手順、370件の中身、そして「Chrome 151で382件が修正された」という数字がネット上に出回っている理由を順番に整理します。

まず何をすればいいか。更新して再起動するだけ

対処は3分で終わります。Googleの公式ヘルプにある手順はこうです。

Chromeを開き、右上の「その他」（点が縦に3つ並んだアイコン）から「ヘルプ」→「Google Chrome について」を選びます。更新があれば自動でダウンロードが始まるので、表示された「再起動」ボタンを押します。ここを押すまで、ダウンロードは終わっていても修正は反映されません。「Chrome は最新の状態です」と出れば完了です。

再起動すると開いていたタブとウィンドウは自動で開き直りますが、公式ヘルプが明記しているとおりシークレットウィンドウだけは復元されません。調べ物の途中でシークレットウィンドウを使っている場合は、URLを控えてから再起動してください。

スマホの場合、AndroidはPlayストアのプロフィールから「アプリとデバイスの管理」、iPhoneはApp Storeのプロフィールから「アップデート」で更新します。Android版のChrome 151はデスクトップ版と同じ修正を含む、とGoogleが明記しています。

Edge、Brave、Vivaldi、OperaもChromeと同じ土台（Chromium）で動いているため、同じ穴を抱えています。各社が追随した版を出すまで数日から2週間ほどかかるので、Chrome以外を使っている人はそちらの更新も忘れずに確認してください。

誰が狙う穴なのか

ブラウザの穴を欲しがるのは、大きく2種類の相手です。ひとつは広告配信の枠を買って不正な広告を紛れ込ませる詐欺グループ。もうひとつは、特定の記者や活動家、企業の役員を狙う監視ツールを政府機関に売っている業者です。どちらも「不特定多数に、気づかれずに、一度に届く」経路としてブラウザを見ています。

やることは共通していて、細工したページを表示させるだけで、ブラウザの内側から外へ抜け出すことです。Chromeは、Webページを描画する部分を「サンドボックス」という檻の中に閉じ込めて、パソコン本体のファイルに触れないようにしています。今回まとめて塞がれた穴の多くは、その檻の壁に開いた小さなヒビにあたります。ヒビを何個か組み合わせると、檻の外に出られてしまいます。

檻の外に出られると、個人の場合はブラウザに保存したパスワードやログイン状態（クッキー）を抜かれ、メールやネットバンキング、SNSのアカウントが乗っ取られます。企業の場合はもっと厄介で、社員が業務中に踏んだ広告1つが社内ネットワークへの入口になります。ランサムウェアの被害調査でも、最初の一歩がブラウザ経由だったという報告は珍しくありません。更新を1週間放置することのコストは、この「入口を開けたまま」の1週間ぶんです。

370件の中身。危険度が最も高いのは7件だけ

Googleは自社の基準で、脆弱性を「Critical（最も危険）／High／Medium／Low」の4段階に分けています。今回の370件を数えると、次のようになります。

数の主役はMediumとLowで、合わせて292件。全体の8割近くを占めます。ここが「370件」という数字の実態です。一方でCriticalの7件は、いずれもGoogle社内で見つかったもので、報告日は5月18日から6月14日に集中しています。7件すべてを挙げておきます。

CVE-2026-17650：画面合成の部品で解放済みメモリを使う不具合

Compositing（複数のレイヤーを重ねて画面を描く部分）で、いったん解放したメモリを再び使ってしまう「Use after free」です。攻撃者が解放後の領域に自分のデータを置ければ、そこを踏ませてプログラムの流れを乗っ取れます。NVDの登録内容でも詳細は非公開のままです。2026年5月18日報告。

CVE-2026-17651：WebGPU基盤Dawnの入力チェック不足

Dawnは、Webページからパソコンのグラフィック機能を直接使う「WebGPU」の土台にあたる部品です。信頼できない入力の検証が足りず、想定外の値を渡されると壊れます。ChromeのWebGPU周りは2026年に実際の攻撃で使われた実績がある領域で、Googleが重く見ているのはそのためです。5月28日報告。

CVE-2026-17652：ウィンドウ描画部品Viewsの解放済みメモリ利用

Viewsは、タブやボタンなどブラウザ本体のUIを描く部品です。ここはWebページを描く部分より外側、つまり檻の外側にあたるため、穴が開くと影響が直接的になります。今回はViewsで2件（Criticalの本件とHighのCVE-2026-17670、CVE-2026-17699など）が修正されました。6月2日報告。

CVE-2026-17653：描画ライブラリSkiaの解放済みメモリ利用

Skiaは、ChromeやAndroidが図形と文字を描くために使っている共通の描画エンジンです。Chrome以外の製品にも組み込まれているため、この種の不具合は影響範囲を追いにくくなります。6月5日報告。

CVE-2026-17654：自動更新の仕組みそのものにある競合状態

Updater、つまりChromeを自動更新している常駐プログラムに、処理の順序が入れ替わると壊れる「競合状態（Race）」があります。更新の仕組みは管理者に近い強い権限で動くことが多く、ここを突かれると権限の格上げにつながります。今回Criticalに分類された7件のうち、唯一Webページを開かなくても関係しうる種類です。6月10日報告。

CVE-2026-17655：グラフィック変換層ANGLEの入力チェック不足

ANGLEは、WebページからのOpenGL命令をWindowsのDirectXなどに翻訳する層です。今回の370件のうち30件がANGLE関連で、部品別では2番目に多くなっています。翻訳という性質上、外から来た値をそのまま扱う場面が多く、検証漏れが起きやすい場所です。6月11日報告。

CVE-2026-17656：Linux向け画面制御層Ozoneの解放済みメモリ利用

Ozoneは、主にLinuxでウィンドウやディスプレイを扱う抽象化層です。Linuxデスクトップや、Chrome OSを含むChromiumベースの環境が対象になります。6月14日報告。

部品別に見ると、最も多かったのは意外にもiPhone／iPad版Chrome（Chrome for iOS）の35件でした。以下、ANGLE 30件、開発者ツール（DevTools）18件、パスワード管理16件、拡張機能14件、JavaScriptエンジンV8 11件と続きます。不具合の種類では「Inappropriate implementation（実装が仕様どおりでない）」が128件で最多、次いで入力検証不足が70件、解放済みメモリの利用が49件です。

なお、370件のうち1件は外部のオープンソース部品に由来します。CVE-2026-17705（libxmlの整数あふれ、Igaliaのebassi氏が報告）がそれです。ブラウザに限らず、自分たちのソフトが外部のどんな部品を抱えているかを把握しておきたい場合は、依存パッケージを貼り付けるだけで確認できるスキャナーも用意しています。

調べても「危険度の点数」が出てこないのはなぜか

CVE-2026-17650を検索して、危険度の数字が出てこないので不安になった人がいるかもしれません。これは正常です。

脆弱性には通常、CVSSという0.0〜10.0の共通スコアが付きます。ところがGoogle Chromeは、自分が発行するCVE番号にCVSSを付けない方針です。付いているのは前述のCritical／High／Medium／Lowという自社基準の4段階だけで、米国政府の脆弱性データベース（NVD）に登録された370件はすべてスコア欄が空のまま公開されています。後日NVD側が独自に採点する場合もありますが、この件数だと現実的ではありません。

つまり「CVSS未付与＝安全」でも「評価が定まっていない」でもなく、単にGoogleがそういう出し方をしているだけです。判断材料はGoogleの4段階で足ります。ちなみに、実際に攻撃に使われていることが確認された脆弱性は米CISAが「KEV」というリストで公開しており、Chromeの過去のゼロデイもそこに載っています。KEVを日本語で全件検索できるダッシュボードで確認できますが、今回の370件はいずれも現時点で掲載されていません。

1回の更新で370件も直る理由。GoogleがAIに探させている

370件のうち349件は「Reported by Google」、つまりGoogle社内で見つかったものです。外部の研究者からの報告は21件しかなく、報奨金が支払われたのは8件、金額の合計は58,500ドル（最高額は3万6000ドル、CVE-2026-17657のナビゲーション処理の不具合）にとどまります。数百件を修正しながら報奨金がこの水準というのは、発見の主体が完全に社内へ移ったことを示しています。

その理由をGoogle自身が説明しています。Chromiumプロジェクトが公開しているChrome Securityの2026年第2四半期レポートに、次の一文があります。

同じレポートには、報奨金制度を見直した理由として「the volume of reports being discovered and fixed using internal AI tooling（社内のAIツールを使って発見・修正されている報告の量）」を挙げた記述もあります。さらに、Project ZeroとDeepMindが共同開発した脆弱性探索AI「Big Sleep」について「the Big Sleep agent now operates as a fully automated pipeline, helping secure V8（Big Sleepエージェントは現在、完全に自動化されたパイプラインとして稼働し、V8の安全確保に貢献している）」と書かれています。

ここで注意したいのは、Googleは「AIのおかげで件数が増えた」とは言っているが、「今回の370件をAIが見つけた」とは一度も言っていないことです。リリースノート上の370件はすべて「Reported by Google」に丸められていて、どれがAI由来かの内訳は出ていません。2024年8月以降のChromeリリース告知377本を通して数えると、「Google Big Sleep」という名前がクレジットされたのは2025年の一時期に集中する数本だけで、2026年のリリースノートには1件もありません。

おかしなことに、Chrome 151の告知で唯一AIツールの名前が出てくるのは他社のものです。CVE-2026-17658（V8の解放済みメモリ利用、報奨金1,000ドル）の報告者欄には「Duc Nguyen of Calif.io in collaboration with OpenAI Codex Security」と書かれています。告知の末尾にある定型の謝辞でも、挙げられているのはAddressSanitizerやlibFuzzerといった従来型の検査ツールだけで、AIへの言及はありません。

もうひとつ、件数の見え方を変えている要因があります。Googleが社内発見バグの書き方を変えたことです。2025年9月30日の告知までは、社内で見つかったバグは「Various fixes from internal audits, fuzzing and other initiatives（社内監査、ファジング、その他の取り組みによる各種修正）」という1行にまとめられ、CVE番号すら振られていませんでした。この行は2025年10月以降の告知から完全に姿を消し、代わりに社内バグにも1件ずつCVE番号が振られるようになっています。同じ量のバグを直していても、書き方を変えるだけで件数は跳ね上がります。

Google自身、四半期レポートで「There is ongoing work to also improve our CVE and release notes issuance processes to scale appropriately with the increased volume（増えた量に見合うよう、CVE発行とリリースノートの手順を改善する作業が進行中）」と書いています。AIによる発見増と、集計方法の変更。この2つがどれくらいの比率で「370件」を作っているのかは、公式説明がないため外からは切り分けられません。

「Chrome 151で382件」という情報が出回っているが、あれは150の話

検索すると「Chrome 151で382件の脆弱性が修正、うちCritical 15件」という記事や投稿が大量に見つかります。これは今回の370件とは別物で、しかも数字もバージョンも間違っています。

発端はGoogle自身のミスでした。2026年6月30日に配信されたのはChrome 150 だったのですが、告知の初出時にバージョンが「151」、件数が「382」と誤って書かれていました。Googleはあとから両方を訂正し、正しくはChrome 150で433件です。SecurityWeekの記事末尾には、その訂正の経緯が注記として残されています。

問題は、訂正前のスナップショットをコピーしたまとめ系サイトが、いまも「Chrome 151＝382件」と書き続けていることです。日本語圏にも伝わっており、6月30日時点でこう投稿されています。

投稿者に責任があるわけではなく、Googleの告知がそう書かれていた以上、当時の情報としては正確でした。ただ、いま「Chrome 151 脆弱性」で検索した人がこれらを踏むと、実際に配信された370件の告知にたどり着けません。

日本語の報道が今回の件数に触れていないのにも理由があります。窓の杜が7月30日9時40分に公開した記事は、XMLパーサーがRust実装に切り替わった点などを紹介したうえで、「本バージョンのリリースノートには、セキュリティ関連の修正に関する記載がない。詳細が公表されるのを待ちたい」と書いています。Googleが告知を出した時点ではセキュリティ欄が存在せず、あとから370件の一覧が追記されたためです。GIGAZINEのリリース記事も同様に件数には触れていません。

もうひとつ紛らわしいのが「Chromeに151件の脆弱性」という見出しです。これはバージョン151ではなく、5月29日にSecurity NEXTが報じたChrome 148の話で、修正件数が151件だったというだけです。バージョン番号と件数が同じ数字になってしまったせいで、「Chrome 151」で検索すると上位に出てきます。記事に書かれたバージョン番号を必ず確認してください。

429→433→370。増え続けているわけではない

「毎回400件級」という印象が広まりつつありますが、実際の推移はこうです。数字はいずれもGoogleの告知本文から数えたものです。

総数は433件から370件へ約15%減り、最も危険なCriticalは22件、20件と来て7件まで落ちています。3か月続けて数百件規模なのは確かですが、右肩上がりではありません。この間には少量の緊急修正も挟まっていて、たとえば7月14日の更新は15件、7月23日は4件です。数百件が出るのはメジャーバージョンが上がるタイミングで、そこに1か月分がまとめて計上されている、という見方が実態に近そうです。

なお、この件数の見え方は9月にまた変わります。Googleは9月8日のChrome 153から、リリース間隔を4週間から2週間に短縮すると発表しています。1回あたりの件数は半分程度に見えるようになるはずです。

会社のパソコンで使っている場合はどうなるか

日本のパソコンでのChromeのシェアは65.4%（StatCounter、2026年6月）。世界全体の72.24%より低く、代わりにEdgeが22.2%と世界平均の倍以上を占めます。企業配布のWindows機が多い日本らしい構成で、Edgeも同じ土台を使っているので、情シス側は両方の更新を見る必要があります。

企業向けには「Extended Stable」という別の配信系統があります。Google Chrome Enterpriseのヘルプによると、通常のStableが2週間ごとに更新されるのに対し、Extended Stableは8週間サイクルで動きます。機能変更の頻度を抑えつつ、セキュリティ修正だけは短い間隔で受け取る仕組みです。

ここで注意点が2つあります。ひとつは、Extended Stableは偶数のバージョンにしか存在しないこと。つまり151は対象外で、7月30日時点の配信は150.0.7871.187と150.0.7871.212の段階展開中です。もうひとつは、9月からStableが2週間サイクルになってもExtended Stableは8週間のまま維持される、とGoogleが明言していることです。両者の差はこれまでより開きます。

情シスの立場では、今回の370件に緊急対応が必要な要素はありません。悪用は確認されておらず、CriticalもGoogle社内発見の7件だけです。通常の更新サイクルに乗せれば足ります。急ぐべきなのは、むしろ6月のV8ゼロデイのように実際の攻撃が確認された場合で、そのときは配信を待たずに強制更新をかける判断になります。

管理者向けのリリースノートは本体の告知とは別に出ています。今回の内容についてはこちらが詳しいです。

月に一度の大量修正が当たり前になると、件数そのものは判断材料として役に立たなくなります。見るべきなのは総数ではなく、Criticalが何件か、実際に攻撃に使われた形跡があるか、この2点です。今回はそれぞれ「7件」「なし」でした。落ち着いて更新して、再起動してください。

参照元

• ▸ Chrome Releases - Stable Channel Update for Desktop（Chrome 151、370件の一覧）（2026年7月29日）
• ▸ Chrome Releases - Chrome for Android Update（2026年7月29日）
• ▸ The Chromium Projects - Chrome Security 2026 Q2 Update
• ▸ SecurityWeek - Google Patches 382 Chrome Vulnerabilities（433件・Chrome 150への訂正注記あり）（2026年7月1日）
• ▸ 窓の杜 - 「Google Chrome 151」がリリース ～XMLパーサーがメモリ安全な「Rust」実装に（2026年7月30日）
• ▸ Chrome for Developers - Chrome moves to a two-week release cycle
• ▸ Google Chrome ヘルプ - Google Chrome を更新する
• ▸ Google Chrome Enterprise ヘルプ - Chrome リリースチャンネル
• ▸ StatCounter - Desktop Browser Market Share Japan（2026年6月）
• ▸ Security NEXT - 「Chrome」に151件の脆弱性 - 22件が「クリティカル」（2026年5月29日）