Chrome Fixes 21 Flaws. Check the Running Build.
Google’s 29 October Chrome release fixes 21 security flaws, including a critical MediaStream memory-corruption issue. The deployment question is whether the browser people are using has reached the appropriate fixed build for its platform and channel. Google’s desktop announcement covers Stable and Extended Stable and describes a staged rollout. A published release and a completed fleet update are different milestones.
The targets depend on the platform
The following are the targets in the 29 October notices, checked for this report on 31 October. Google lists two builds for Windows and macOS; the notice does not assign one to a particular architecture. Android has its own delivery timetable.
| Platform | Release track | Published build | Delivery stated by Google |
|---|---|---|---|
| Windows and macOS | Stable and Extended Stable | 156.0.8078.79/.80 | Over the coming days or weeks |
| Linux | Stable; Linux build listed in the same notice | 156.0.8078.79 | Over the coming days or weeks |
| Android | Corresponding Chrome 156 release | 156.0.8078.79 | Google Play over the next few days |
The Android announcement says its release carries the corresponding desktop security fixes unless otherwise noted. That establishes the relationship between the releases. It does not establish that every phone has already received the package or that an organisation’s managed app rollout has completed.
Check the channel as well as the major version. Google’s current release feed also has separate Early Stable 157 and Dev 159 entries. Those entries do not make a development-channel version the deployment target for a fleet assigned to Stable or Extended Stable. Use the organisation’s intended, supported channel and the matching release evidence.
What the critical issue actually describes
CVE-2026-76024 concerns memory corruption in MediaStream. Google’s CVE-authority description says a remote attacker could potentially read memory inside the sandbox through a crafted HTML page in Chrome versions before 156.0.8078.79. The critical rating should not be expanded into a claim that this particular flaw provides arbitrary code execution or a sandbox escape.
Two severity systems are visible in the official record. Chrome, the CVE Numbering Authority, calls the issue Critical using Chromium’s security-severity classification. CISA’s separate authorised-publisher enrichment assigns CVSS 3.1 a score of 6.5, Medium. Its vector records a network path, no required privileges, user interaction, unchanged scope and confidentiality impact, with no integrity or availability impact represented. The 6.5 score is not a Google Critical CVSS score, and neither field is an estimate of the probability that a particular organisation will be attacked.
The chronology also matters. Google credits a report dated 21 October and published the release notice on 29 October. The CVE record was published on 30 October at 00:05 UTC. CISA’s exploitation assessment is timestamped 30 October at 13:11 UTC and records “none”. The complete official Known Exploited Vulnerabilities catalogue inspected for this report, version 2026.10.30 released at 17:02 UTC, contains no matching entry for this issue. Google’s release notice makes no exploitation claim. These are dated observations, not proof that exploitation has never occurred.
All 21 fixes in the 29 October notice
Google lists one Critical, 19 High and one Medium issue. The table retains the vendor’s component names and severity labels. The identifier links provide the individual record context; the Google release notice supplies this cohort and its fixed-build targets. A component label alone does not establish that every flaw has the same attack path or impact.
The critical issue’s memory-read boundary must not be generalised to the whole release. The High-rated Skia issue CVE-2026-119261 and GarbageCollection issue CVE-2026-119263 have Chrome-authority descriptions of potential arbitrary code execution outside the sandbox through a crafted page. Their Skia and GarbageCollection records describe different potential outcomes from the MediaStream read. They do not establish an observed exploit chain joining these flaws.
| Identifier | Google severity | Component and defect |
|---|---|---|
| CVE-2026-76024 | Critical | MediaStream: memory corruption |
| CVE-2026-76025 | High | FileSystem: use after free |
| CVE-2026-76026 | High | Autofill: memory corruption |
| CVE-2026-76027 | High | CacheStorage: memory corruption |
| CVE-2026-76028 | High | FileSystem: use after free |
| CVE-2026-76029 | High | Network: memory corruption |
| CVE-2026-76030 | High | FileSystem: memory corruption |
| CVE-2026-76031 | High | Input: use after free |
| CVE-2026-119260 | High | Frames: use after free |
| CVE-2026-119261 | High | Skia: improper input validation |
| CVE-2026-119262 | High | V8: improper input validation |
| CVE-2026-119263 | High | GarbageCollection: memory corruption |
| CVE-2026-119264 | High | Dawn: memory corruption |
| CVE-2026-119265 | High | Quota: memory corruption |
| CVE-2026-119266 | High | Quota: use after free |
| CVE-2026-119267 | High | DOM: memory corruption |
| CVE-2026-119268 | High | Editing: integer overflow |
| CVE-2026-119269 | High | Blink: use after free |
| CVE-2026-119270 | High | CacheStorage: improper input validation |
| CVE-2026-119271 | High | Skia: use after free |
| CVE-2026-119272 | Medium | FileSystem: out of bounds read |
Google cautions that detailed bug information may remain restricted until enough users have updated, or while other projects using an affected library still need a fix. The public component and defect labels are sufficient to identify the release’s scope, but they are not a substitute for unavailable technical detail. No exploit or vulnerability test is needed to establish whether a browser has reached the published release target.
Some linked records still have incomplete structured fix data. The targets here come from Google’s release notices and the CVE-authority descriptions’ explicit before-version wording. An incomplete database fix field does not establish that Google has yet to release an update.
Keep the earlier releases in their own context
The 27 October desktop notice lists 52 fixes and the earlier 156.0.8078.73/.74 Windows and macOS builds, with 156.0.8078.73 for Linux. That is a separate announcement from the 21-row cohort above. Keep each count attached to its release date rather than treating the two announcements as a deduplicated vulnerability total. A machine recorded as “Chrome 156” could still be below the later target.
Our Chrome 155 report concerns the 6 and 13 October releases and a separate extension-policy change. Its historical build numbers and policy discussion do not replace the targets in this report. Neither a familiar major version nor an older successful change record establishes that the current update has reached the active browser.
Verify the version in use and finish pending relaunches
Google’s update instructions direct desktop users to Help, then About Google Chrome, where the version is displayed and an update check runs. Complete a pending Relaunch when offered, then reopen the version information and record the result. For Linux, Google directs users to their package manager. Android delivery follows Google Play and the applicable managed-app route.
For a managed fleet, also check the effective update policy and assigned channel. Google’s Chrome Enterprise Core guidance for Windows and macOS describes staged Stable delivery and controls such as version pinning. A deployment report should distinguish an update that is unavailable through the configured route, one deferred by policy, a failed installation and a browser awaiting relaunch. Those states need different owners and follow-up actions.
Google provides managed relaunch notifications for Windows, macOS and Linux. A recommended notification allows the user to continue with the older browser until they relaunch; required notifications operate with a configured period. Review the actual policy and agreed maintenance window rather than assuming that a background download or a reminder completed the change.
For shared or remotely accessed machines, our proposed handover includes the session owner and the browser instance being checked. Agree when the relaunch can happen, verify the version in the relevant session afterwards and exercise an approved business workflow. Record the remote-access host software and operating-system support separately. A Chrome browser version is not evidence that a separate remoting package has been updated.
The same product boundary applies to distribution-packaged Chromium, embedded browsers and other Chromium-based applications. Check the exact product, supported channel, repository or store candidate, and that product’s authoritative advisory. Google’s Chrome build numbers do not establish a universally available package or a fixed version for every application sharing browser code.
A useful closure record names the product and platform, the channel and effective update policy, the version verified after the change, and any remaining exception with an owner and next review time. Keep the deployment open where the required package or running version has not been verified. This makes a fleet-wide completion claim traceable to the browsers people actually use.
Sources
- Google: 29 October Stable and Extended Stable desktop release
- Google: corresponding Android release
- Official critical-issue record, including Chrome CNA and CISA ADP provenance
- CISA: official catalogue repository
- Google: check and update Chrome
- Google: manage updates through Chrome Enterprise Core
- Google: notify users to relaunch for pending updates
- Google: separate 27 October release
