Patching

Chrome 154 and Firefox 157 fix 108 flaws: patch and relaunch

By Yaali. October 1, 2026, 6 min read, Patching, Vulnerabilities.

Chrome 154 fixes a critical ANGLE overflow and 25 high-severity bugs; Firefox 157 fixes 76. Fixed builds, and how to prove every browser restarted.

Google and Mozilla both shipped security releases on September 29. Chrome 154.0.8037.92/.93 for Windows and macOS, and 154.0.8037.92 for Linux, fixes 32 vulnerabilities: one critical, 25 high. Firefox 157 fixes 76, of which Mozilla rates 38 high, and the same day brought Firefox ESR 153.4, 140.17 and 115.42 for organisations on the Extended Support Release track.

Neither vendor reports any of these bugs being exploited in the wild. That leaves a short window to roll out before the bug details are opened up, which Google does once most users have updated. The catch is the relaunch: both browsers download the fix in the background, but a window that has been open for a week keeps running the old code.

How the critical Chrome bug works

CVE-2026-102331 is a buffer overflow in ANGLE, reported by a researcher using the handle @mfx on August 24. ANGLE (Almost Native Graphics Layer Engine) is the layer that takes the WebGL and OpenGL ES calls a web page makes and translates them into the graphics API the operating system actually provides, such as Direct3D on Windows or Metal on macOS. Any page can draw with WebGL, so ANGLE parses data that comes straight from untrusted sites.

A buffer overflow means the code writes past the end of a memory buffer it allocated, corrupting whatever sits next to it. The CVE record says a crafted HTML page could use this to "potentially execute arbitrary code outside the sandbox". Most Chrome bugs give code execution inside the renderer sandbox, and an attacker then needs a second bug to escape it. The CVE description puts this one past that boundary on its own.

The CVE record scores it CVSS 9.6 (vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H): network reachable, low complexity, no privileges, one user action such as opening a page. The sources label the platform differently. Google's desktop release notes list the bug as critical in the desktop build, while the CVE description names "Google Chrome on Android prior to 154.0.8037.92". Chrome for Android received the same 154.0.8037.92 build. We would treat desktop and Android as affected and update both.

The other 25 high-severity Chrome fixes

Six of the high-severity bugs are in V8, Chrome's JavaScript engine: five type confusions and one buffer overflow. Type confusion is when the engine treats an object as one type while it is really another, so its memory is read with the wrong layout. Three of the five were reported by OpenAI Codex Security. The rest are spread across the graphics stack (GPU, WebGPU, Dawn, WebGL, Skia and a second ANGLE issue, mostly uninitialised resources), use-after-free bugs in Views, Passwords, Bluetooth, FullScreen and Picture-in-Picture, a privilege management flaw in Mojo (Chrome's inter-process messaging system), an Omnibox spoofing bug and cross-site scripting in WebUI.

What Firefox 157 fixes

Mozilla's count is high partly because of a change in how it publishes. It no longer groups internally found memory safety bugs under one catch-all CVE; each bug now gets its own entry. Of the 38 high-severity fixes, most are use-after-free bugs (memory used again after it was freed, which an attacker can refill with their own data) across WebAssembly, WebGPU, the DOM, Canvas2D and XSLT.

Nine of the high-rated entries are sandbox escapes. Firefox runs web content in sandboxed content processes, and a sandbox escape lets code already running in one of those processes break out into the more privileged parent process. On its own it needs another bug to get started, which is why these matter most in combination with the many content-process memory bugs fixed in the same release. Amy Burnett of OpenAI reported two JIT miscompilation bugs, where the just-in-time compiler produces machine code that does not do what the JavaScript or WebAssembly asked.

What to do

1. Get Chrome to 154.0.8037.92 or later on Linux and Android, and 154.0.8037.92 or .93 on Windows and macOS. Get Firefox to 157, or to ESR 153.4, 140.17 or 115.42 if you run an ESR branch.
2. Force the relaunch. In Chrome, set the RelaunchNotification policy to 2 (required) and RelaunchNotificationPeriod to the grace period you want, in milliseconds. Microsoft Edge supports the same two policy names. Firefox shows a restart prompt after it downloads an update; a user who never closes the browser stays on the old version, so schedule a restart through your endpoint management tool for machines that report 156 or older.
3. Look for pins. A Chrome TargetVersionPrefix policy, or Firefox's AppUpdatePin, holds a machine on an older version on purpose. Check that no group policy object, Intune profile or policies.json is still pinning to 153 or 156 from an earlier rollout. Firefox lists active policies at about:policies.
4. Do not stop at Chrome and Firefox. Edge, Brave and other Chromium-based browsers take these fixes in their own builds, on their own schedule. Edge numbers its builds differently (Edge 154 is 154.0.4258.x), so match an Edge build to the fixes using Microsoft's Edge security release notes, not by comparing numbers with Chrome.
5. Electron apps such as Slack, Visual Studio Code and Discord bundle their own copy of Chromium, ANGLE included, and only pick up fixes when their vendor ships a new release. Visual Studio Code shows its Chromium version under Help, About. Keep these apps on auto-update and put them on your patch report.

Checking versions across a fleet

On a single machine, chrome://version, edge://version and brave://version show the version of the browser that is actually running. Brave's page also shows the Chromium version it is built on. For Firefox, open Help, About Firefox.

Across a fleet, the installed version and the running version can differ. On Windows, Chrome writes the new version folder next to the old one under C:\Program Files\Google\Chrome\Application\ and leaves the update staged as new_chrome.exe until the browser relaunches. A script that finds both a 153 folder and a 154 folder, or a new_chrome.exe, has found a machine that downloaded the fix but is not running it. Firefox records its installed version in the registry at HKLM\SOFTWARE\Mozilla\Mozilla Firefox, value CurrentVersion. On macOS, defaults read "/Applications/Google Chrome.app/Contents/Info" CFBundleShortVersionString gives the installed Chrome version.

If you manage Chrome through Chrome Browser Cloud Management, the Google Admin console lists managed browsers and their versions under Devices, Chrome, Managed browsers. Filter for anything below 154.0.8037.92.

No exploitation has been reported and Google has not published technical details, so there are no indicators of compromise to search for yet. The version report is the evidence that you are covered.

Browsers need their own patch cycle

Browsers release faster than the monthly operating system cycle. Chrome and Firefox both shipped a full major version in September with over 100 fixes between them. A browser that follows the Patch Tuesday ring schedule can sit three or four weeks behind. Give browsers an automatic update policy with a forced relaunch inside a few days, and a weekly report of running versions, so a release like this one closes in days.

If you want help building that report or tuning update and relaunch policies, our safeguarding and hardening team does this work, and on-demand risk reduction can help clear a backlog. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: Chrome Releases: Stable Channel Update for Desktop, Mozilla MFSA 2026-97 (Firefox 157), Mozilla MFSA 2026-98 (ESR 115.42), Mozilla MFSA 2026-99 (ESR 140.17), Mozilla MFSA 2026-100 (ESR 153.4), SecurityWeek, GBHackers, Cyberpress, CVE-2026-102331 record summary, Microsoft Edge security release notes.