Google has pushed another security update to Chrome 156. It is the second for this browser version in roughly a week, and it fixes 21 vulnerabilities. One is rated critical: CVE-2026-76024, a memory-corruption bug in the MediaStream component. Nineteen more are rated high severity and one is medium.
The Chrome Releases post dated October 29 moves both the Stable and Extended Stable channels to version 156.0.8078.79/.80 on Windows and macOS and 156.0.8078.79 on Linux. No source reports that any of the 21 bugs is being exploited. That makes this a routine but important patch, not an emergency. Still, a critical rating in the most widely used browser means it belongs near the top of this week's patch list.
Back-to-back releases
This update follows closely behind the previous Chrome 156 security release, versions 156.0.8078.73/.74. According to PiunikaWeb, that release fixed 52 issues. If your organization approved and rolled out that build last week, you are not finished. The October 29 build is a separate set of fixes, and machines still on .73/.74 remain exposed to all 21 of the newly patched bugs.
Fast follow-ups like this are normal for Chrome. Google publishes security fixes as soon as they are ready and does not hold them for a monthly cycle. For admins, that means a "patch Chrome" ticket is never really closed. The job is to keep the fleet close behind the current Stable build.
The critical bug: CVE-2026-76024
MediaStream is the part of the browser that handles live audio and video, such as a webcam feed in a video call or a screen-share capture. Google's advisory lists CVE-2026-76024 as a memory-corruption issue in that component. It was reported by researcher Xinyang Ge on October 21, 2026, and fixed eight days later.
The National Vulnerability Database entry, published October 30, describes the flaw this way: in Chrome before 156.0.8078.79, a remote attacker could "potentially read memory inside the sandbox via a crafted HTML page." Put simply, the victim only has to load a malicious or compromised web page. The attacker does not need an account or any prior access.
Two parts of that description explain why the severity labels disagree. First, the impact is memory disclosure, meaning the attacker can read data they should not see. It is not described as running code. Second, the leak stays "inside the sandbox." Chrome runs web content in locked-down processes called sandboxes, so a bug in one of those processes does not hand over the rest of the machine. Because of this, NVD's secondary CVSS 3.1 score is 6.5, which is Medium (network attack vector, low complexity, no privileges required, user interaction required, high confidentiality impact). Chromium's own rating is still Critical.
The gap is not a contradiction. CVSS scores what one bug can do by itself. Browser vendors also weigh how useful a bug would be to an attacker. Memory-disclosure bugs are often combined with other flaws: leaked memory can help an attacker get around protections such as address randomization, which makes a second, code-execution bug easier to use. Treat the Critical label as Google's judgment of that risk.
The other 20 fixes
The high-severity bugs cover a wide range of Chrome's code. Google's advisory lists, among others:
- CVE-2026-76025: a use-after-free in FileSystem. A use-after-free happens when a program keeps using memory after it has been released, which attackers can sometimes exploit to take control of the program.
- CVE-2026-76026: a flaw in Autofill, the feature that fills in saved addresses, cards and form data.
- CVE-2026-76029: a flaw in the Network component.
- CVE-2026-119262: improper input validation in V8, Chrome's JavaScript engine.
- CVE-2026-119264: a flaw in Dawn, Chrome's implementation of the WebGPU graphics interface.
- CVE-2026-119271: a flaw in Skia, the graphics library that draws most of what appears on screen.
The single medium-severity issue is CVE-2026-119272.
SecurityOnline reports that 16 of the 21 fixes are memory-corruption or use-after-free bugs. That class of bug has been behind most serious browser exploits for years. The outlet also says Google's internal security teams found 12 of the 21 issues and that Xinyang Ge reported four. It found no confirmation of exploitation or of a public proof-of-concept for any of them.
As usual, Google's advisory gives only short descriptions. The company typically withholds full bug details until most users have updated, because attackers study fixed builds to work out the underlying flaws. Defenders should expect that window between the patch and working exploits to keep shrinking.
What It Means for Defenders
Who is affected: anyone running desktop Chrome on Windows, macOS or Linux older than 156.0.8078.79. This includes organizations on the Extended Stable channel, which received the same update. Machines that installed last week's 156.0.8078.73/.74 release are still vulnerable.
What to do:
- Update to the fixed build. The target is 156.0.8078.79 or .80 on Windows and macOS and 156.0.8078.79 on Linux. Individual users can open Help > About Google Chrome to start the update, as SecurityOnline notes.
- Make sure the browser relaunches. Chrome downloads updates in the background, but the fix does not take effect until the browser restarts. Many users leave Chrome open for weeks. If your management tooling can enforce a relaunch deadline, use it.
- Check your inventory, not your policy. Pull the installed Chrome versions from your endpoint management or vulnerability scanner and look for anything below .79. Pay attention to machines that rarely reboot, such as shared kiosks, jump boxes and remote desktop hosts.
- Remember other Chromium-based browsers. The sources cover Google Chrome only. If your fleet runs other browsers built on Chromium, watch for those vendors' own updates that include these fixes.
For CMMC and compliance teams: browser patching falls under flaw-remediation requirements. A critical-rated browser update with a dated vendor advisory is easy to document. Record when the update was released, when it was deployed and when you verified the installed versions.
Priority: high, not emergency. No exploitation has been reported. But the critical bug is reachable by simply visiting a web page, and most of the other fixes address the kind of memory-safety bug attackers favor. Aim to have the fleet updated within your normal critical-patch window.
