トップ/記事一覧/Chromeに脆弱性41件、危険度最高が6件 CVE-2026-19137ほか即更新を
unknown-cover-ja-update

Chromeに脆弱性41件、危険度最高が6件 CVE-2026-19137ほか即更新を

Googleが7月29日に配信したChrome 151で、370件の脆弱性がまとめて塞がれました。悪用された形跡はなく、対処は更新して再起動するだけです。370件の内訳と、3か月続く大量修正がなぜ起きているのか、出回っている「382件」という数字がなぜ間違いなのかをまとめます。

ニュース2026年7月30日公開 本日更新
Share X B! Hatena LINE in LinkedIn RSS
目次
この記事のポイント

Googleが7月29日に配信したChrome 151で、370件の脆弱性がまとめて塞がれました。悪用された形跡はなく、対処は更新して再起動するだけです。370件の内訳と、3か月続く大量修正がなぜ起きているのか、出回っている「382件」という数字がなぜ間違いなのかをまとめます。

Googleが2026年8月6日、Chromeの更新版（151.0.7922.108／.109）を配信し、41件の脆弱性を修正しました。1週間前に370件をまとめて直したばかりのタイミングでの追加配信です。

41件のうち、Googleが最も危険と評価した「Critical」が6件あります。前回の370件に含まれていたCriticalは7件でしたから、総数が9分の1に減っても、危険なものの数はほとんど変わっていません。しかも6件のうち4件はAndroid版のChromeだけが対象です。

実際に攻撃へ使われた形跡は、8月7日時点で1件も報告されていません。やることは更新して再起動するだけです。この記事では今回の41件の中身を先に整理し、そのあとで7月29日の370件の話を残しています。

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

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

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

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

今回はAndroid版が主役なので、スマホの更新を後回しにしないでください。AndroidはPlayストアのプロフィールから「アプリとデバイスの管理」、iPhoneはApp Storeのプロフィールから「アップデート」で更新します。Android版のリリース告知には「Android releases contain the same security fixes as their corresponding Desktop releases（Android版はデスクトップ版と同じセキュリティ修正を含む）」と書かれています。

使っている環境これ以上なら対処済み配信日
Windows / Mac151.0.7922.108
または .109		2026年8月6日
Linux151.0.7922.1082026年8月6日
Android
（今回の主対象）		151.0.7922.1082026年8月6日
iPhone / iPad151.0.7922.112
（修正内容の記載なし）		2026年8月6日
会社支給PC
（企業向け設定）		150.0.7871.224
（別系統・後述）		2026年8月6日

バージョン番号の末尾が「.108」なのか「.109」なのかを気にする必要はありません。Googleは同じ内容を複数の番号に分けて順に配りますし、Chromeは放っておいても自動で更新されます。いま自分が151系の最新になっているかどうかだけを「Google Chrome について」の画面で確認してください。

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

誰がこの穴を欲しがるのか

今回のようにスマホのブラウザに偏った穴を真っ先に買いに行くのは、盗んだ端末を転売するような相手ではなく、端末に入り込んで持ち主の行動を丸ごと記録する監視ツールの業者です。スマホには通話履歴、位置情報、写真、認証アプリのコードが揃っていて、パソコンより「その人そのもの」に近い。だから同じ穴でも、Android版に効くものは取引価格が跳ね上がります。

手口は驚くほど地味です。SNSのダイレクトメッセージや広告に混ぜたリンクを1回開かせる。それだけで、ブラウザがWebページを閉じ込めている「サンドボックス」という檻の壁を越えられる、というのが今回のCritical 6件の中身です。怪しいファイルをダウンロードさせる必要も、パスワードを入力させる必要もありません。

檻の外に出られたあと何が起きるかは、使っている人の立場で変わります。個人なら、保存したパスワードとログイン状態（クッキー）が抜かれ、SNSやネットバンキングにそのまま入られます。二段階認証を設定していても、認証アプリが同じ端末に入っていれば守りとしては薄くなります。企業なら、社員が私物のスマホから社内システムに入る運用をしている場合、その1台が社内ネットワークへの入口になります。だから「あとで更新すればいい」の「あと」は、入口を開けたままの時間そのものです。

41件のうち、いちばん危ない6件

Googleは脆弱性を「Critical（最も危険）／High／Medium／Low」の4段階で評価しています。今回の41件はCriticalが6件、Highが35件で、MediumもLowも1件もありません。前回の370件がMedium 170件・Low 122件で膨らんでいたのとは、数字の性質がまったく違います。

Critical 6件のうち、特に注意して読んでほしいのは「前提条件なし」の3件です。Googleの説明文には2つの書き方があり、「a remote attacker who had compromised the renderer process（すでにレンダラーを乗っ取っている攻撃者）」と書かれているものは、別の穴と組み合わせないと成立しません。一方、その但し書きがないものは細工したページを開かせるだけで檻の外まで届く可能性がある、という意味です。6件中3件が後者です。

CVE-2026-19170：Android版のWebGLで、ページを開くだけで檻の外へ

WebGLは、Webページから端末のグラフィック機能を直接使って3D表示などを行う仕組みです。ここで解放済みのメモリを再び使う「Use after free」が見つかりました。NVDの登録内容には前提条件の但し書きがなく、細工したページを開かせるだけでサンドボックスの外に出られる恐れがあります。Android版限定です。

報告したのはシンガポールのセキュリティ研究チームSTAR Labs SGのMuhammad Alifa Ramdhan氏、Pan ZhenPeng氏、Billy Jheng Bing Jhong氏の3人。脆弱性発見の国際大会Pwn2Ownで総合優勝（Master of Pwn）を取った実績を持つチームです。報告は7月22日、修正の配信は8月6日。15日で塞がれています。今回の6件で最も動きが速かったものです。

CVE-2026-19157：Android版のグラフィック変換層ANGLEに書き込みの飛び出し

ANGLEは、Webページから来たグラフィック命令を各OSの描画機能に翻訳する層です。確保した領域の外にデータを書いてしまう「Out of bounds write」で、これも前提条件の記載がありません。ANGLEは前回の370件でも30件が集中した部品で、外から来た値をそのまま扱う場面が多いぶん検証漏れが起きやすい場所です。Google社内で7月14日に発見。Android版限定です。

CVE-2026-19149：Linux版の画面部品Auraで、ページを開くだけで檻の外へ

Auraは、Linux版などでウィンドウやメニューといった画面部品を扱う層です。前提条件なしのサンドボックス脱出にあたり、Linux版のChromeを使っているならこれが今回いちばん重い1件です。Google社内で6月17日に発見。同じAuraでは、Highに分類されたCVE-2026-19147も同時に修正されています。

CVE-2026-19137：Android版のWebGLにもう1件、4か月かかった修正

CVE-2026-19170と同じWebGLの解放済みメモリ利用ですが、こちらは「すでにレンダラーを乗っ取っている攻撃者」が前提です。単体では成立しません。目を引くのは日付で、報告は2026年4月5日、修正は8月6日。4か月かかっています。報告者は匿名で、報奨金の欄は「TBD（未定）」のままです。

CVE-2026-19154：Android版の描画ライブラリSkia

Skiaは、ChromeやAndroid本体が図形と文字を描くために使っている共通の描画エンジンです。Chrome以外の製品にも組み込まれているため、この種の不具合は影響範囲を外から追いにくくなります。レンダラー乗っ取りが前提の1件で、Google社内で7月9日に発見。今回の41件ではSkia関連が5件と、部品別では最多タイです。

CVE-2026-19172：全OS共通、ブラウザ本体の見た目を描くViews

Viewsは、タブやボタンなどブラウザ本体の見た目を描く部品です。Webページを描く部分より外側、つまり最初から檻の外にあたるため、穴が開くと影響が直接的になります。Critical 6件のうち唯一、OSを問わず全員が対象です。レンダラー乗っ取りが前提で、Google社内で7月22日に発見。Viewsでは他にHighのCVE-2026-19142、CVE-2026-19158、CVE-2026-19159も同時に直っています。

「370件から41件に減った」と読むと間違える

1週間前の370件と並べると、41件は9分の1です。落ち着いたように見えます。ただ、比べる対象を揃えると印象が変わります。

Googleの評価7月29日
（370件）		8月6日
（41件）		意味
Critical7件6件檻の外まで
抜けられる恐れ
High71件35件檻の中で
不正なコードが動く
Medium170件0件情報漏れ・
表示の偽装など
Low122件0件単体では
実害になりにくい

CriticalとHighだけを足すと、7月29日が78件、8月6日が41件です。減ったのは約半分にすぎません。総数が9分の1に見えるのは、前回に大量にぶら下がっていたMediumとLowが今回はゼロだからです。

Googleは今回の41件についてMedium以下を一切載せていません。理由は説明されていませんが、月次のメジャー更新（370件）と、その合間に挟む修正（41件）とで載せる範囲を変えている可能性があります。いずれにせよ件数だけを2つ並べて比べるのは意味がない、というのが今回いちばん実務的な教訓です。見るべきなのは「Criticalが何件か」と「実際に攻撃に使われた形跡があるか」の2つで、今回はそれぞれ「6件」「なし」でした。

不具合の種類でも偏りがあります。41件のうち21件が解放済みメモリの利用（Use after free）で、ちょうど半分です。C++でメモリを手動管理している以上つきまとう類のバグで、GoogleがChrome 151でXMLの解析部分をRustに置き換えたのも、この種のバグを根本から減らすためです。

危ない場所が、スマホとパソコンで違う

41件を対象環境で分けると、今回の性格がはっきり出ます。

対象件数うち
Critical		主な部品
Android版だけ7件4件WebGL、Skia、
ANGLE、GPU
Linux版だけ3件1件Aura、GPU
Windows版だけ4件0件Media、Views、
認証情報の連携
全OS共通27件1件V8、Skia、Views、
決済、拡張機能

Critical 6件のうち4件がAndroid版だけ、1件がLinux版だけ。Windows版だけを対象にしたCriticalは1件もありません。全体の件数でもWindows版限定は4件と少なく、パソコンだけを見ていると「今回は大したことがない」と読み違えます。

グラフィック関連（WebGL、Skia、ANGLE、GPU）がAndroid側に集中しているのは偶然ではありません。スマホはGPUのメーカーとドライバの組み合わせが端末ごとにばらばらで、パソコンより検証しにくい。そのぶん穴が残りやすく、攻撃者にとっては実際の攻撃で使われた実績のあるWebGPU周りと同じく、優先的に掘る場所になっています。

なお、Android版のChromeは端末メーカーの都合ではなくGoogle Play経由で配信されるため、OSの更新がもう来ない古い端末でもChrome自体は最新にできます。「うちのスマホは古いから無理」と諦めなくて構いません。

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

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

脆弱性には通常、CVSSという0.0〜10.0の共通スコアが付きます。ところがGoogle Chromeは、自分が発行するCVE番号にCVSSを付けない方針です。付いているのはCritical／High／Medium／Lowという自社基準の4段階だけで、米国政府の脆弱性データベース（NVD）に登録された41件もスコア欄が空のまま公開されています。後日NVD側が独自に採点する場合はあり、前回の370件では8月6日にCVE-2026-17650へ8.3が付きました。つまり数字は数か月遅れで後追いされることがある、というだけの話です。

「CVSS未付与＝安全」でも「評価が定まっていない」でもなく、単にGoogleがそういう出し方をしているだけです。判断材料はGoogleの4段階で足ります。実際に攻撃に使われていることが確認された脆弱性は、米国政府のCISAが「KEV」というリストで公開しており、Chromeの過去のゼロデイもそこに載っています。KEVを日本語で全件検索できるダッシュボードで確認できますが、8月6日版のカタログ（全1,661件）を当サイトで確認したところ今回の41件はいずれも掲載されていません。Chromium系でKEVに入っている最新のものは、6月9日追加のCVE-2026-11645（V8）です。

見つけたのは誰か。AI企業の名前が単独で載った

今回の41件で最も変化が出たのは、報告者の欄です。Google社内での発見が29件、外部からの報告が12件。外部の比率は29%になりました。前回の370件では外部21件（5.7%）でしたから、割合は5倍です。

その外部12件の中に、人間ではない報告者が2つ入っています。

ひとつはCVE-2026-19168（V8の実装不備、High）。報告者欄は「Reported by XBOW and triaged by Andrés Luksenberg」です。XBOWは、人間の指示なしで侵入テストを行うAIを提供している会社で、2025年6月にHackerOneの米国ランキングで人間を抜いて1位になったことで知られています。HackerOneはその後、人間と機械のランキングを分けました。報奨金は500ドルです。

もうひとつがCVE-2026-19162（V8の書き込み飛び出し、High）で、報告者欄は「Reported by OpenAI Codex Security (amyb)」。OpenAIが2026年3月に公開したコード検査エージェントです。ここが前回との違いで、7月29日の370件でも同じ名前は出ていましたが、そのときは「Duc Nguyen of Calif.io in collaboration with OpenAI Codex Security」——人間の研究者との共同名義でした。今回は人間の協力者名が消え、社名と担当者ハンドルだけになっています。

「AIが脆弱性を見つけた」と言うとき、これまでは横に必ず人間が立っていました。Chromeのリリース告知という公式文書で、その人間の名前が外れたのは今回が初めてです。

残る10件は人間です。V8のCVE-2026-19174を報告したSeunghyun Lee氏（@0x10n）は、2024年と2025年のChrome報奨金ランキングで連続1位を取った研究者で、V8だけで20件以上のCVEを持ちます。今回はQED Auditという監査会社の所属として報告しています。最高額の5,000ドルが付いたのはCVE-2026-19169（Contextual Tasksの入力検証不足、High）で、報告者はSven Dysthe氏です。

報奨金の相場が10分の1になった

金額の並びを見ると、はっきり下がっています。今回明示された報奨金は5,000ドルと500ドルの2件だけで、Critical 6件はすべて「N/A（社内発見のため対象外）」か「TBD（未定）」です。

これは偶然ではなく、制度が変わりました。Googleは2026年4月にChromeとAndroidの報奨金制度を改定し、メモリ安全性に関するバグの基本額を500ドルに設定し直しました。そこに「攻撃者が到達できる場所か」「実際に悪用できるか」に応じた倍率を掛ける方式です。SecurityWeekの報道によると、研究者からは「一部のChromeのバグ報奨金は以前の10分の1になった」という声が出ています。同じ改定でAndroid端末側の最高額は100万ドルから150万ドルへ引き上げられており、ブラウザのバグは安く、端末そのものの乗っ取りは高くという重心の移動が起きています。

値下げの理由としてGoogleが挙げているのがAIです。Chromiumプロジェクトの2026年第2四半期レポートには、次の一文があります。

「The Chrome VRP adjusted its reward structure and reward amounts to reflect the volume of reports being discovered and fixed using internal AI tooling.」
（Chrome報奨金制度は、社内のAIツールを使って発見・修正されている報告の量を反映するかたちで、報奨金の構造と金額を調整した）

社内のAIが先に見つけてしまうなら、外部から同じものを持ち込まれても払う理由がない、という理屈です。同時にGoogleは報告の書き方にも注文をつけています。AIによって長く詳細な報告書を作るのは簡単になったが、社内ツールもバグの説明と修正案を自動で出せるようになった、として、再現手順と検証に必要な材料だけを求める方針に変えました。AIが書いた分厚い報告書は、AIに読ませて捨てる——そういう時代の入口です。

7月29日の370件は、どういうものだったか

ここからは1週間前の話です。Googleは2026年7月29日、パソコン向けのChrome 151（151.0.7922.71／.72）を配信し、370件の脆弱性をまとめて修正しました。Windows版とLinux版が .71、Mac版が .72 です。この370件も8月6日の41件も同じ151系の中の話で、いま更新すれば両方まとめて解消します。

370件の内訳はCritical 7件、High 71件、Medium 170件、Low 122件。数の主役はMediumとLowで、合わせて292件と全体の8割近くを占めていました。Criticalの7件はいずれもGoogle社内で見つかったもので、報告日は5月18日から6月14日に集中しています。7件は次のとおりです。

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

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

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

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

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

Viewsは、タブやボタンなどブラウザ本体のUIを描く部品です。ここはWebページを描く部分より外側、つまり檻の外側にあたるため、穴が開くと影響が直接的になります。8月6日の41件でもViewsは4件が修正されており、継続的に手が入っている場所です。6月2日報告。

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

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

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

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

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

ANGLEは、WebページからのOpenGL命令をWindowsのDirectXなどに翻訳する層です。370件のうち30件がANGLE関連で、部品別では2番目に多くなっていました。8月6日のCVE-2026-19157も同じANGLEで、こちらはAndroid版のCriticalです。6月11日報告。

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

Ozoneは、主にLinuxでウィンドウやディスプレイを扱う抽象化層です。Linuxデスクトップや、Chrome OSを含むChromiumベースの環境が対象になります。6月14日報告。8月6日にはLinux向けとしてAuraのCVE-2026-19149がCriticalに入っており、Linux版は2回続けて最上位の指摘を受けたことになります。

370件を部品別に見ると、最も多かったのは意外にも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氏が報告）がそれです。ブラウザに限らず、自分たちのソフトが外部のどんな部品を抱えているかを把握しておきたい場合は、依存パッケージを貼り付けるだけで確認できるスキャナーも用意しています。

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

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

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

「The Product Security team is seeing an increased number of security bugs because AI models are increasingly good at finding security vulnerabilities.」
（製品セキュリティチームは、AIモデルが脆弱性を見つけるのが上手くなり続けているために、セキュリティバグの件数が増えているのを目にしている）

同じレポートには、Project ZeroとDeepMindが共同開発した脆弱性探索AI「Big Sleep」について「the Big Sleep agent now operates as a fully automated pipeline, helping secure V8（Big Sleepエージェントは現在、完全に自動化されたパイプラインとして稼働し、V8の安全確保に貢献している）」と書かれています。ITmediaが8月5日に報じた記事によると、Chrome 149と150の2バージョンだけで1,072件の脆弱性が修正されており、Googleは24時間体制の大規模なコード検査を回しています。

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

もうひとつ、件数の見え方を変えている要因があります。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つがどれくらいの比率で件数を押し上げているのかは、公式説明がないため外からは切り分けられません。

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

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

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

「UPDATE: Google has updated its advisory to say that the Chrome update actually patches 433 vulnerabilities. The company has also updated the Chrome version number to 150; it was initially 151.」
（追記：Googleは勧告を更新し、このChromeアップデートが実際には433件の脆弱性を修正すると訂正した。バージョン番号も150へ修正されている。当初は151と書かれていた）

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

投稿者に責任があるわけではなく、Googleの告知がそう書かれていた以上、当時の情報としては正確でした。

【訂正】日本語の報道について

当記事は7月30日の公開時点で「日本語の報道が370件という件数に触れていない」と書いていましたが、これは誤りでした。窓の杜は7月30日15時29分に「370件に及ぶ脆弱性に対処、深刻度最大のCriticalは7件」とする続報を出しており、Security NEXTも同日に370件として報じていました。当記事が参照していたのは同じ窓の杜の第1報（リリース紹介記事）で、そちらに件数の記載がなかったため、続報の存在を見落としたものです。お詫びして訂正します。

一方、8月6日の41件については、8月7日時点で日本語の報道が見当たりません。海外でもドイツのit-blogger.netがバージョン更新として触れている程度で、SecurityWeekやBleepingComputerは370件の記事のままです。メジャーバージョンの節目に出る大量修正は報じられ、その合間の修正は落ちる、という報道の癖がそのまま出ています。

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

429→433→370→41。件数の推移

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

バージョン配信日修正件数Critical社内発見
Chrome 1492026年6月2日429件22件371件
Chrome 1502026年6月30日433件20件401件
Chrome 151
（.71／.72）		2026年7月29日370件7件349件
Chrome 151
（.108／.109）		2026年8月6日41件6件29件

数百件が出るのはメジャーバージョンが上がるタイミングで、そこに1か月分がまとめて計上される。その合間には少量の更新が挟まる。7月14日の更新は15件、7月23日は4件、そして8月4日の151.0.7922.75／.76にはセキュリティ修正の記載がありません。今回の41件は、その「合間の更新」としては異例に大きい部類です。

この見え方は9月にまた変わります。Googleは9月8日のChrome 153から、リリース間隔を4週間から2週間に短縮すると発表しています。1回あたりの件数は半分程度に見えるようになるはずです。あわせて、更新のたびにブラウザを再起動しなくて済む「無停止アップデート」の仕組みも進んでおり、macOS版のChrome 150では、全ウィンドウがバックグラウンドにある場合に次回起動時へ自動反映される挙動が入りました。

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

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

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

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

情シスの立場では、今回の41件に緊急対応が必要な要素はありません。悪用は確認されておらず、Criticalも社内発見と研究者からの通常報告です。ただ、私物スマホや業務用スマホでAndroid版Chromeを使わせている場合は、パソコンより先に手を打つ価値があります。Critical 6件のうち4件がAndroid版限定で、そのうち2件はページを開くだけで成立しうる種類だからです。端末管理（MDM）でChromeのバージョンを見ているなら、151.0.7922.108未満の端末を洗い出すのが最短です。

管理者向けのリリースノートは本体の告知とは別に出ています。

月に何度も修正が飛んでくるようになると、件数そのものは判断材料として役に立たなくなります。今回のように「370件」と「41件」が1週間差で並ぶと、なおさらです。見るべきなのは総数ではなく、Criticalが何件で、それがどのOSに効くのか、そして実際に攻撃に使われた形跡があるか。今回はそれぞれ「6件」「主にAndroid」「なし」でした。落ち着いてスマホとパソコンの両方を更新して、再起動してください。

よくある質問

7月に更新したばかりですが、また更新が必要ですか

必要です。7月29日の更新（151.0.7922.71／.72）に、8月6日の41件は含まれていません。「Google Chrome について」を開いて、151.0.7922.108以上になっているか確認してください。

スマホのChromeも更新しないといけませんか

今回はむしろスマホが本命です。最も危険と評価された6件のうち4件がAndroid版だけを対象にしており、そのうち2件は細工されたページを開くだけで成立しうる種類です。Playストアから更新してください。

iPhoneのChromeはどうですか

iPhone／iPad版は8月6日に151.0.7922.112が出ていますが、Googleの告知には「stability and performance improvements（安定性と性能の改善）」としか書かれておらず、セキュリティ修正の記載はありません。iOS版のChromeはAppleのWebKitを使う仕組み上、パソコン版とは中身が別物です。とはいえ更新しておくに越したことはありません。

すでに攻撃されている可能性はありますか

8月7日時点で、41件のいずれについても実際の攻撃に使われたという報告はありません。米国政府CISAが公開する「実際に攻撃されている脆弱性リスト（KEV）」の8月6日版にも入っていません。

EdgeやBraveを使っています。関係ありますか

関係あります。いずれもChromeと同じChromiumを土台にしているため、同じ穴を抱えています。各社が追随した版を出すまで数日から2週間ほどかかるので、そちらの更新も確認してください。

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go