CVE-2025-14174とは？Chrome・Edgeの修正版と2026年11月の更新先（Chrome 157対応）

CVE-2025-14174は、ChromiumとAppleのWebKitが共通して使う描画部品ANGLEに見つかった、境界外のメモリアクセスの脆弱性です。修正前から攻撃に使われていたゼロデイで、Googleは2025年12月10日にChromeを、Microsoftは翌11日にEdgeを更新しました。この記事では、脆弱性の中身、Chrome・Edge・Apple製品の修正版、Windows版も対象に入るのか、その後2026年に続いたChromeのゼロデイ7件、10月29日の更新で直ったCriticalのCVE-2026-76024、11月3日に安定版になったChrome 157の213件の修正、端末の版の確かめ方と更新運用を、Google・Microsoft・Appleの告知とNVD・CISAの登録情報に沿って整理します。

まとめ：CVE-2025-14174の修正版と2026年11月4日時点の更新先

CVE-2025-14174は、細工したWebページを開かせるだけでブラウザのメモリ範囲外を読み書きさせられる脆弱性です。CVSS 3.1は8.8（High）で、米CISAは2025年12月12日に悪用確認済みの一覧（KEV）へ追加しました。修正版は次のとおりです。

• Chrome：143.0.7499.109/.110（Windows・Mac）、143.0.7499.109（Linux）
• Microsoft Edge：143.0.3650.80
• Apple：iOS・iPadOS 26.2（旧系統は18.7.3）、macOS Tahoe 26.2、Safari 26.2

NVDの説明文は「Mac版のChrome」と書いていますが、同じNVDの製品指定（CPE）はWindows版とLinux版のChromeも対象に入れています。修正済みと判定する下限は、Windows・Linuxが143.0.7499.109、Macが143.0.7499.110です。

この1件は143系の修正版で解消しています。ただしChromeの部品を狙うゼロデイは2026年に入っても7件がKEVに追加されており、守るべきは「最新の安定版を数日以内に全台へ行き渡らせる運用」です。2026年11月4日（日本時間）に確かめた更新先は次のとおりです。

• Chrome：11月3日（米国時間）に安定版へ上がった157.0.8103.38/.39（Windows・Mac）、157.0.8103.38（Linux）。213件のセキュリティ修正を含み、そのうち7件がCritical
• Edge：10月30日公開の156.0.4314.58が最新の安定版。Microsoftは11月3日に「Chromiumの修正への対応を進めている」と告知しており、157の安定版は予定表で11月5日の週

Chrome 157の213件について、告知に悪用の記載はなく、11月3日版のKEVにも追加はありません。急ぎの度合いは通常の自動更新の範囲ですが、Criticalの7件にはCVE-2025-14174と同じANGLEのメモリ破損（CVE-2026-121229）が入っています。その前の10月29日の更新（156.0.8078.79/.80、21件）で直ったCriticalのCVE-2026-76024（MediaStreamのメモリ破損）も、悪用の記載はありません。157へ上げれば両方とも直り、Edgeは156.0.4314.58でCVE-2026-76024まで直っています。Chromeのメジャー版は2週間ごとに上がり、Chromium Dashの予定表どおり157は11月3日に安定版になりました。その後の最新版はChromeの最新バージョンと確認・更新方法とMicrosoft Edgeの最新バージョンと更新履歴で確かめてください。

CVE-2025-14174の中身：ANGLEの境界外メモリアクセスとCVSS 8.8

ANGLEは、WebGLなどの描画命令を各OSのグラフィックスAPIに変換する部品です。ChromeとEdgeのほか、AppleのWebKitにも組み込まれています。部品が共通だったため、1つのCVEがブラウザ2系統とApple製品のOSにまたがりました。

Metal向けのバッファの大きさの計算ミスとCWE-787の評価

NVDの登録は、「Mac版Google Chrome 143.0.7499.110より前のANGLEに境界外のメモリアクセスがあり、遠隔の攻撃者が細工したHTMLページで悪用できる」と説明しています。弱点の分類はNVDがCWE-787（範囲外への書き込み）、CISA-ADPがCWE-119です。CISA-ADPのCVSS 3.1は8.8（AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H）で、ネットワーク越しに認証なしで成立する一方、利用者にページを開かせる操作（UI:R）が要ります。Chromium自身の深刻度はHighです。

説明文がMac版に寄っているのは、問題がANGLEのMetal（AppleのグラフィックスAPI）向けの実装にあったためです。バグ466192044に対応するANGLEの修正（2025年12月5日のコミット95a32cb、題名「Metal: Don’t use pixelsDepthPitch to size buffers.」）は、Metal向けのバッファの大きさの計算を直しています。

12月5日の報告から12月12日のKEV追加までの修正公開の経緯

Chromeの2025年12月10日の告知は、報告者を「Apple Security Engineering and Architecture（SEAR）とGoogle Threat Analysis Group」、報告日を12月5日としています。告知には「CVE-2025-14174のエクスプロイトが実在することを把握している」と明記されました。公開当初はバグ番号466192044だけを示し、12月12日に告知を更新してCVE番号と内容を加えています。

表の12月5日の報告者はApple SEARとGoogle TAGで、ANGLEには修正コミットが入りました。12月10日に公開されたChromeの修正版は143.0.7499.109/.110で、この時点の告知はバグ番号のみです。12月12日には告知にCVE番号が追記され、NVD登録とKEV追加に加え、iOS 26.2も公開されました。

報告から修正版まで5日、修正版の公開からKEV追加まで2日でした。KEVの対応期限の決め方は2026年6月にBOD 26-04で改められており、仕組みはBOD 26-04によるKEVの是正期限の決め方で解説しています。

同じ更新で直ったCVE-2025-14372とCVE-2025-14373

12月10日のChromeの更新には、CVE-2025-14174のほかに2件のセキュリティ修正が入っています。パスワードマネージャのuse-after-free（CVE-2025-14372、Medium）と、ツールバーの実装の不備（CVE-2025-14373、Medium）です。告知が悪用に触れているのはCVE-2025-14174だけで、残る2件は外部研究者からの通常の報告でした。修正済みと判定する下限は、NVDのCPEに合わせるとWindows・Linuxが143.0.7499.109、Macが143.0.7499.110です。この版以上なら3件とも直っています。

影響を受けた製品と修正版：Chrome・Edge・Apple製品

NVDのCPE（製品と版の機械可読な指定）と各社の告知を突き合わせると、修正版は次のとおりです。

Edgeのセキュリティ更新履歴は、12月11日の143.0.3650.80について「ChromiumチームはCVE-2025-14174のエクスプロイトが実在すると報告しており、この更新はその修正を含む」と記しています。

Windows版・Linux版のChromeもNVDのCPEでは対象

NVDの説明文だけを読むとMac版の問題に見えますが、同じ登録のCPEは3つの条件で対象を定めています。Mac上のChromeは143.0.7499.41以上.110未満、WindowsとLinux上のChromeは143.0.7499.40以上.109未満、OSを問わず143.0.7499.40以下です。CPEの上では、Windows版も修正前の版は「脆弱」と判定される扱いです。ただし、これは対象の指定であって、攻撃がWindows上で成立したことを示すものではありません。Googleは悪用が確認された環境を明らかにしておらず、Debianのセキュリティトラッカーのように、Linux向けのChromiumを「Mac版だけに影響する」として対象外と評価している配布元もあります。

Microsoftも、OSを分けずに全プラットフォームのEdge向け更新として修正を配りました。KEVの説明も、Chrome・Edge・OperaなどChromiumを使う複数のブラウザに影響しうると書いています。NVDのCPEを判定に使う脆弱性スキャナーでは、Windows端末の143.0.7499.109未満のChromeも検出に上がりえます。自社のツールがどのデータで判定しているかを確かめたうえで、Windows端末も更新の対象として管理してください。

iOS・macOSのWebKit側の修正とCVE-2025-43529

AppleのiOS 26.2・iPadOS 26.2のセキュリティ情報（2025年12月12日公開）は、WebKitの項目でCVE-2025-14174を「メモリ破損の問題を検証の改善で修正した」とし、報告者を「AppleとGoogle Threat Analysis Group」としています。同じWebKitの欄にあるuse-after-freeのCVE-2025-43529と2件そろって、「iOS 26より前の版で、特定の個人を狙った極めて高度な攻撃に悪用された可能性がある」との報告を受けたものと説明しています。

NVDのCPEでは、Safari・macOS・tvOS・visionOS・watchOSの26.2未満と、iOS・iPadOSの18.7.3未満および26.0以上26.2未満が対象です。iPhoneやMacを業務で使う組織は、ブラウザだけでなくOSの版も確かめてください。同じWebKitのゼロデイの過去例はCVE-2023-41993（Apple WebKitのゼロデイ）で扱っています。

Brave・Opera・VivaldiなどChromium派生ブラウザ

Chromiumを土台にするブラウザは同じANGLEを使っています。修正の取り込み時期はブラウザごとに異なるため、各社のリリースノートで143系の修正を含む版を確かめる必要があります。社内でChrome・Edge以外のChromium系ブラウザを許可しているなら、その版も棚卸しに入れてください。許可していないなら、利用者が個人で入れていないかを資産管理で確かめるのが先です。

2026年に続いたChromeのゼロデイ7件と更新対象の修正版

CVE-2025-14174は、2025年にKEVへ追加された製品名がChromiumの脆弱性7件の最後でした（3月のCVE-2025-2783、6月のCVE-2025-5419、7月のCVE-2025-6554とCVE-2025-6558、9月のCVE-2025-10585、11月のCVE-2025-13223に続く）。2026年も同じペースで続いています。CISAのKEV（2026年10月30日版）で2026年に追加されたものと、それを直したChromeの版を並べます。

2026年のゼロデイ7件のKEV追加日・部品・Chromeの修正版一覧

修正版はWindows・Macの番号で、Linuxは各行の小さい方の番号です。告知日はChrome Releasesの日付（米国時間）で、どの告知にも「エクスプロイトが実在することを把握している」の一文があります。CVE-2026-2441はExtended Stableの144.0.7559.177でも同じ日に直っています。部品名は告知とKEVの登録名を訳したもので、2D描画のSkiaとWebGPU実装のDawnはKEV上の製品名がChromiumではありません。KEVを「Chromium」で絞り込むとこの2件が漏れるので、自社の点検表を作るときは注意してください。点検表をスクリプトで作る場合の照合の組み方は、VPN機器の版確認コマンドとKEV照合スクリプトの例がブラウザにもそのまま使えます。

2026年3月12日・13日の2件連続と、その後のゼロデイ発生間隔

7件のうち4件はJavaScriptエンジンのV8でした。最も詰まっていたのは3月で、Google Threat Analysis Groupが3月10日に報告した2件が、12日（CVE-2026-3910）と13日（CVE-2026-3909）の2日続けて別々の版で直りました。12日の版に上げた端末も、翌日にもう一度上げないと3909が残る並びです。月次のパッチ適用だけでは、定例適用日の直後に修正版が出た場合、次回まで約1か月未適用になるおそれがあります。

9月9日の追加以降、11月3日版までのKEVにChromiumを製品名とする追加はありません。10月20日（156への昇格・353件）、27日（52件）、29日（21件）、11月3日（157への昇格・213件）の安定版告知にも、悪用が確認されたという記載はありません。版ごとの修正件数の追い方はChrome 148の脆弱性79件の例が参考になります。

10月29日Chrome 156.0.8078.79の修正：CVE-2026-76024

Chromeの2026年10月29日の告知は、安定版とExtended Stableをそろって156.0.8078.79/.80（Windows・Mac）、156.0.8078.79（Linux）に上げ、21件のセキュリティ修正を含むとしています。内訳はCriticalが1件、Highが19件、Mediumが1件です。Criticalの1件がCVE-2026-76024で、告知は「MediaStreamのメモリ破損」、報告者をXinyang Ge氏、報告日を10月21日としています。MediaStreamは、カメラ・マイクの入力や画面共有の映像を扱うブラウザの仕組みで、ビデオ会議などのWebRTCアプリが使う部分です（WebRTCの全体像はWebRTCとは（P2Pの仕組みと実装）で解説しています）。

NVDの登録（2026年10月30日公開）は、「156.0.8078.79より前のGoogle ChromeのMediaStreamのメモリ破損により、遠隔の攻撃者が細工したHTMLページでサンドボックス内のメモリを読める可能性がある」と説明しています。注目したいのは評価の食い違いです。

CVSSが6.5にとどまるのは、NVDの説明が「サンドボックス内のメモリを読む」範囲に限っており、改ざんと停止の影響を「なし」と評価しているためです。CISAのSSVCの判定も、悪用はnone、自動化はnoでした。一方で深刻度のCriticalはChromium自身の評価で、詳細はバグ576215540の公開が制限されているあいだ分かりません。CVSSの数字だけで「中程度だから後回し」とは判断できない例です。逆にCVE-2025-14174は深刻度がHighでも実際に悪用されていました。更新の急ぎ方はCVSSや深刻度の名前でなく、悪用の確認とKEVへの掲載で決め、悪用の記載がない更新も通常の自動更新の流れで1〜2週間以内に行き渡らせるのが妥当です。

Edgeについては、Edge Updates APIが10月30日公開の156.0.4314.58に20件のCVEをひも付けており、その中にCVE-2026-76024があります（2026年11月1日に取得）。セキュリティ更新履歴の同じ日の項目は「CVEは判明しだい追加する」としているので、Edgeの判定は156.0.4314.58以上を下限にしてください。前日29日の156.0.4314.56には、このCVEは入っていません。

11月3日Chrome 157.0.8103.38昇格：213件中Critical 7件

Chromeの2026年11月3日の告知は、Chrome 157をWindows・Mac・Linuxの安定版へ上げ、版を157.0.8103.38/.39（Windows・Mac）、157.0.8103.38（Linux）としています。配信は「今後数日から数週間で行き渡る」と書かれています。セキュリティ修正は213件で、告知に並んだ深刻度を数えるとCriticalが7件、Highが77件、Mediumが75件、Lowが54件でした。156の昇格時の353件に続く大きな更新です。告知には「エクスプロイトが実在することを把握している」の一文がなく、2026年のゼロデイ7件とは扱いが違います。

セキュリティ修正213件のうち、Criticalの7件の内訳は次のとおりです。部品の名前は告知の英語表記を訳したものです。

7件のうち4件（ANGLE・WebGL・Dawn 2件）は、WebGLやWebGPUの描画命令をGPUへ渡す経路にあります。CVE-2025-14174が見つかったANGLEと、2026年4月にゼロデイとしてKEVへ載ったCVE-2026-5281のDawnも、この経路の部品です。描画の経路はWebページから細工した命令を送り込みやすく、攻撃者が繰り返し狙っている場所だと分かります。ただし今回の7件はどれも悪用の記載がなく、詳細は多くのバグの公開が制限されているあいだ分かりません。現時点で言えるのは「同じ部品で深刻な不具合がまだ見つかり続けている」ところまでです。

報告者の欄には、AIを使った脆弱性探索の名前が目立ちます。「assisted by Claude」や「OpenAI Codex Security」と書かれた報告がCritical・Highの中に複数並んでおり、見つかる件数そのものが増えている背景の一つと考えられます。1回の更新で200件を超える修正が出る状態は今後も続くと見て、件数の多さを理由に更新を遅らせない運用にしておくのが安全です。

Edge 157の公開予定と、それまでのEdgeの更新先の判断

Edgeについては、Edgeのセキュリティ更新履歴が11月3日付で「Chromiumの最近のセキュリティ修正を把握しており、修正版の公開に取り組んでいる」と記しています。11月4日にEdge Updates APIを取得した時点で、安定版の最新は10月30日の156.0.4314.58のままでした。Edgeのリリース予定表では、157の安定版の公開目標は「2026年11月5日の週」です。

したがって11月4日時点のEdgeの判断は、156.0.4314.58以上なら現時点の更新先に届いている、になります。Chrome 157の213件に相当する修正は、Edge 157の公開を待って取り込まれます。悪用の記載がない更新なので、Edge 157が出たら通常の自動更新で配り、更新履歴とEdge Updates APIでCVEの一覧が付いたことを確かめてから下限の版を157系へ書き換えてください。

業務端末のChrome・Edgeが修正版以上かを確かめる確認手順

CVE-2025-14174の修正済み判定は、ChromeならWindows・Linuxで143.0.7499.109以上、Macで143.0.7499.110以上、Edgeなら143.0.3650.80以上かどうかを端末の版と比べれば済みます。実務で難しいのは、比べる側の「今配られている版」が数日おきに変わる点です。配信状況と端末の版を、それぞれ機械的に取ります。

VersionHistory APIによるChromeの配信中バージョンの取得

Googleのversionhistory APIは、プラットフォームとチャネルごとの配信履歴をJSONで返します。認証は要りません。filter=endtime=none を付けると配信が終わっていない版だけに絞れます。

# 配信中の Chrome 安定版（Windows）を取得する（PowerShell 7 / Windows PowerShell 5.1）
$u = "https://versionhistory.googleapis.com/v1/chrome/platforms/win/channels/stable/versions/all/releases?filter=endtime=none"
(Invoke-RestMethod -Uri $u).releases |
  Select-Object version, fraction, fractionGroup, @{ n = "start"; e = { $_.serving.startTime } }

2026年11月4日（日本時間）にこのAPIが返した内容を、同じ列で並べると次のとおりです。fractionは、その版が配信で振り分けられている割合です。

割合を足し合わせてよいのは、fractionGroupが同じ行どうしだけです。この例ではグループ156の割合の合計が1になり、11月3日に告知された157.0.8103.38の振り分けはまだ0.1でした。同じAPIの rolloutData を見ると、156.0.8078.81は「157.0.8103.38 Rollout」の比較用（control）の枠で、157.0.8103.38が本番の枠（rollout）です。残りの0.8は156.0.8078.80に向いています。156.0.8078.80は10月29日の修正版そのものなので、Windowsのグループ156では、11月4日時点で配信設定の9割がCVE-2026-76024の修正済みの156系、1割が157系という並びです。告知の翌日の時点では、自動更新に任せた端末の多くにまだ157が届いていない前提で考えてください。

11月1日に同じAPIを取得したときは、グループ156の約4分の3が156.0.8078.74と.76（どちらも「156.0.8078.79より前」）に向いていました。3日のあいだに修正版の156.0.8078.80が配信の大半を占めるところまで進んだことになります。Macのグループ200も同じ割合（156.0.8078.80が0.8、.81が0.1、157.0.8103.38が0.1）で、Linuxは157.0.8103.38だけが割合1で返りました。Linuxの端末は、ディストリビューションのパッケージ更新を回した時点で157に上がると見てよい状態です。

これは配信の設定であって、自社の端末の更新が済んだ割合ではありません。全台に行き渡ったかどうかは、次の手順で読む端末ごとの版を資産管理の一覧に集めて確かめます。一番上の行や割合の大きい行が最新版とは限らないので、判定の基準は安定版の告知に載った版に置き、APIは配信の進み具合を見る用途に使ってください。APIはプラットフォームを細かく分けており、URLの win のほかに64ビット版Windowsの win64、Arm版Windowsの win_arm64 があります。Macは mac（Apple Siliconは mac_arm64）、Linuxは linux に置き換えれば、取得方法は同じです。Edgeは、Microsoftが公開するEdge Updates APIで、チャネルごとの版と公開日時、含まれるCVEの一覧を取れます。ただし配信の割合は返さないため、Chromeと同じ見方はできません。基準はセキュリティ更新履歴に載った最新の版に置きます。

PowerShellによるEdge・Chromeのインストール済みバージョンの確認

Windowsでは、実行ファイルの版情報を読めば、画面を開かずにインストール済みの版を確かめられます。次の例が見るのは標準のインストール先だけなので、別の場所に入れている端末は対象のパスを足してください。

# Edge と Chrome の実行ファイルから版を読む（Windows PowerShell）
$targets = @(
  "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe",
  "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
  "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
  "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
)
foreach ($p in $targets) {
  if (Test-Path $p) { "{0}  {1}" -f (Get-Item $p).VersionInfo.ProductVersion, $p }
}

出力は1行に版と実行ファイルの場所が並ぶ形式です（版の数値は例）。

156.0.4314.58  C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
156.0.8078.74  C:\Program Files\Google\Chrome\Application\chrome.exe

読んでいるのはディスク上の実行ファイルの版なので、更新後に再起動していないブラウザは、これより古い版のまま動いていることがあります。上の例のChrome 156.0.8078.74は10月27日の告知に含まれる版で、29日の.79/.80がまだ届いていない状態です。数日たっても変わらない場合は、自動更新を止めるポリシーが入っていないかを確かめます。画面から確かめる場合は、Edgeは edge://settings/help、Chromeは「設定」→「Chromeについて」を開くと、配信の順番を待たずに最新版を取りにいけます。

資産管理の一覧に載せるときは、版を目で読むより、下限の版と比べた判定まで端末側で出すほうが集計しやすくなります。PowerShellの [version] 型は「156.0.8078.74」のような4つの数を桁ごとに比べるので、文字列の比較で起きる「.9」と「.10」の取り違えが起きません。次の例は、2026年11月4日時点で「これ未満は要更新」とする下限（Edge 156.0.4314.58、Chrome 156.0.8078.79）と比べます。Chromeの下限を157.0.8103.38にしていないのは、157が配信の1割にしか振り分けられていない段階で下限を上げると、自動更新の順番を待っているだけの端末まで「要更新」に数えてしまうためです。下限の値は新しい告知が出るたびに書き換えてください。

# 下限の版と比べて OK か要更新かを出す（Windows PowerShell）
$min = @{
  "msedge.exe" = [version]"156.0.4314.58"
  "chrome.exe" = [version]"156.0.8078.79"
}
foreach ($p in $targets) {
  if (Test-Path $p) {
    $name = Split-Path $p -Leaf
    $ver  = [version](Get-Item $p).VersionInfo.ProductVersion
    $res  = if ($ver -ge $min[$name]) { "OK" } else { "要更新" }
    "{0}  {1}  {2}" -f $name, $ver, $res
  }
}

上の出力例の端末なら、Edgeは「OK」、Chromeの156.0.8078.74は「要更新」になります。CVE-2025-14174だけを判定したい場合は、下限をEdge 143.0.3650.80、Chrome 143.0.7499.109（Macは.110）に置き換えます。157への移行がどこまで進んだかを別に数えたい場合は、同じ要領で目標の版（Chrome 157.0.8103.38）と比べる列を足し、「下限は満たすが157未満」の端末を週ごとに減らしていく見方にすると、要更新の件数と混ざりません。Edgeの目標の版は、157の安定版が公開されてから書き足します。

業務PCでブラウザのゼロデイに備える更新運用と適用期限の判断基準

ブラウザのゼロデイは、月次のパッチ適用の周期に乗せると悪用されている期間をそのまま放置することになります。CVE-2025-14174は報告から修正まで5日、2026年3月は2日続けて別の修正版が出ました。Windowsの月例更新との順番の付け方はPatch Tuesdayの日程とゼロデイへの対応順で扱っています。

業務PCで修正版の公開から3日以内に全台を切り替える運用上の目安

業務PCのブラウザは、ゼロデイの修正版が出たら3日以内に全台で切り替えを終える運用を目標にしてください。この3日には配信だけでなく、再起動と未適用端末の確認までを含めます。そのために効くのは、グループポリシーやIntuneでEdge・Chromeの自動更新を止めないことと、再起動の猶予を短くすることです。

業務アプリの互換性を理由にブラウザの版を固定している端末は、ゼロデイの対象になり続けます。固定が必要な業務は専用の仮想環境に分け、一般の閲覧用ブラウザは常に最新にする切り分けにしてください。例外にしてよいのは、インターネットに出ない閉じたネットワークで社内の固定コンテンツだけを表示し、外部のファイルやURLを持ち込めないキオスク端末だけです。外部のコンテンツを開ける端末は、検証が済んでいないことを理由に更新を待たせないでください。メジャー版の互換性の検証は、Chromeの先行配信（Early Stable）が始まった時点で検証用の端末に入れて始めれば、全体への配信の前に済ませられます。ゼロデイの修正は先行配信を経ずに出ることがあるため、こちらは検証を待たずに配り、問題が出た業務だけを切り戻す手順を用意しておきます。

CVE-2026-76024のように悪用の記載がない更新は、3日以内の対象から外し、通常の自動更新と再起動の猶予の範囲で行き渡らせれば足ります。ただしKEVへの追加や告知の更新で悪用が後から判明することもあるので、その時点で3日以内の扱いに切り替えられるよう、未適用の端末を一覧で追える状態にしておいてください。

Edgeの再起動を必須にするRelaunchNotificationの設定

更新が配られても、利用者がブラウザを閉じなければ新しい版は動きません。Edgeには、再起動を促す通知を出すポリシー RelaunchNotification と、その猶予期間を決める RelaunchNotificationPeriod があります。前者を「Required（2）」にすると再起動が必須になり、後者を設定しない場合の猶予は7日（604800000ミリ秒）です。この猶予は、更新が端末に届いて再起動待ちになってから通知を出し続ける期間なので、猶予を3日にしても「修正版の公開から3日以内」の目標が満たせるとは限りません。配信の遅れも含めて、未適用の端末を一覧で追ってください。

# 再起動を必須にし、猶予を3日（259200000 ミリ秒）にする例（管理者の PowerShell）
$k = "HKLM:\SOFTWARE\Policies\Microsoft\Edge"
if (-not (Test-Path $k)) { New-Item -Path $k | Out-Null }
Set-ItemProperty -Path $k -Name RelaunchNotification -Type DWord -Value 2
Set-ItemProperty -Path $k -Name RelaunchNotificationPeriod -Type DWord -Value 259200000

これは端末のレジストリに直接ポリシーを書く例です。グループポリシーやIntuneで管理している端末では、管理の経路をそろえないと設定が競合するため、そちらで同じ値を配ってください。グループポリシーなら「管理用テンプレート／Microsoft Edge／Relaunch」の下にあります。適用後は edge://policy を開き、値が反映され競合が出ていないかを確かめてください。入れる前に検証用の端末で、作業中のタブが再起動後に復元されることも確かめておくと、利用者からの苦情を減らせます。

ブラウザ以外にも古いソフトが残っていないか、外から見える弱点まで含めて確かめたい場合は、一創の脆弱性診断・セキュリティ診断を利用できます。悪用コードの仕組みはexploitの仕組みと防御、CVEとCVSSの読み方は脆弱性とは（CVE・CVSSの仕組み）で解説しています。

よくある質問

CVE-2025-14174について寄せられやすい質問に答えます。

Edge 143.0.3650.80以上なら安全ですか？

CVE-2025-14174については解消しています。ただしその後、2026年にChromeの部品を狙うゼロデイが7件KEVに追加されており、その修正は143系には入っていません。2026年11月4日時点のEdgeの更新先は156.0.4314.58で、10月29日のChromeの更新で直ったCriticalのCVE-2026-76024もこの版で直っています。11月3日のChrome 157に相当するEdge 157は、予定表では11月5日の週に公開される見込みです。最新の状況は冒頭のまとめと、Edgeのセキュリティ更新履歴で確かめてください。自動更新が有効でも、ブラウザを再起動するまでは古い版のまま動いています。

Windows版のChromeやEdgeも影響を受けたのですか？

更新の対象として扱ってください。NVDの説明文は「Mac版のGoogle Chrome」と書いていますが、同じ登録のCPEはWindowsとLinux上のChrome 143.0.7499.40以上.109未満も対象に入れています。MicrosoftもOSを分けずに全プラットフォームのEdge向けに修正を配りました。一方で、修正はANGLEのMetal（Apple向け）の実装に対するもので、Windows上で攻撃が成立したかどうかは公表されていません。

iPhoneやMacのSafariも対象ですか？

対象です。AppleのWebKitもANGLEを使っており、AppleはiOS・iPadOS 26.2（旧系統は18.7.3）、macOS Tahoe 26.2、Safari 26.2などで修正しました。iOS 26.2のセキュリティ情報は、この脆弱性とCVE-2025-43529について「特定の個人を狙った極めて高度な攻撃に悪用された可能性」を記しています。

CVE-2025-14174のCVSSスコアはいくつですか？

CISA-ADPが付けたCVSS 3.1の基本値は8.8（High）で、ベクトルは AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H です。最高の10.0に届かないのは、利用者の操作が必要（UI:R）なことと、影響が脆弱な部品の権限の範囲を超えない（S:U）評価になっていることの組み合わせによります。Chromium自身の深刻度もHighで、Criticalではありません。それでも悪用が確認されたKEV掲載の脆弱性なので、スコアの大小にかかわらず優先して対応する対象です。反対に、2026年10月のCVE-2026-76024は深刻度がCriticalでもCVSSは6.5で、悪用の記載はありません。11月3日のChrome 157で直ったCritical 7件も同じく悪用の記載はありません。急ぐかどうかは悪用の確認で決めてください。

すでに攻撃を受けたか確かめる方法はありますか？

細工したWebページを開くだけで悪用されうるため、閲覧時に異常を感じなかったことは、侵害がなかった証拠になりません。EDRを入れている環境なら、修正前の期間について、ブラウザのプロセスから想定外の子プロセスの起動やファイルの書き込みが起きていないかを確かめます。痕跡が見つからなくても、ログの保存期間や監視の範囲が足りなければ、侵害がなかったとは言い切れません。

関連記事

• Chromeの最新バージョンの確認・更新方法とバージョン履歴一覧
• Microsoft Edgeの最新バージョンとリリースノート要点・更新履歴・確認方法
• Chrome 148の脆弱性79件とビルド別の修正内容
• Patch Tuesdayの日程とMicrosoftゼロデイへの対応順
• BOD 26-04とは？KEVの是正期限を4変数で決める仕組みと自社運用への移し方
• CVE-2023-41993とは？Apple WebKitのゼロデイの影響範囲・修正版と対策
• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説
• WebRTCとは？P2Pの仕組み・ICE/STUN/TURNからSFU選定・実装・運用判断まで実装者向けに解説