The Chromium-assigned vulnerability CVE‑2025‑11206 — a heap buffer overflow in the Video component — was patched upstream by Google in the Chrome 141 Stable update, and Microsoft has listed the CVE in its Security Update Guide to communicate when the Chromium fix has been ingested into Microsoft Edge (Chromium‑based) and when Edge customers are therefore no longer vulnerable.
Chromium is an open‑source browser engine used by Google Chrome and many downstream browsers, including Microsoft Edge (Chromium‑based), Brave, Opera and Vivaldi. When a security problem is found in Chromium, Google typically fixes the issue in Chromium and publishes a Chrome Stable update that contains the remediation. Downstream vendors then “ingest” the upstream fix, perform their own testing and ship a browser build that includes that Chromium revision. Microsoft records the upstream CVE and the Edge ingestion/mitigation status in its Security Update Guide (SUG) so administrators can tell whether their Edge build contains the Chromium patch.
In late‑September 2025 Google promoted Chrome 141 to the Stable channel and that release included fixes for multiple high‑severity memory‑safety issues — notably CVE‑2025‑11205 (WebGPU) and CVE‑2025‑11206 (heap buffer overflow in Video). Chrome Releases and multiple security vendors list Chrome 141.0.7390.54/.55 as the first stable builds that remediate these issues.
This article explains why Microsoft documents Chromium CVEs in the Security Update Guide, how to verify whether your browser is patched, the practical and enterprise implications of the ingestion lag between Chrome and Edge, and recommended mitigation and detection steps.
Treat the ingestion lag and embedded Chromium instances as the main operational risks, and prioritize detection, compensating controls and rapid deployment where necessary. The SUG entry exists to help you do exactly that — to know when Microsoft has finished the work of integrating the upstream Chromium patch into Edge.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Chromium is an open‑source browser engine used by Google Chrome and many downstream browsers, including Microsoft Edge (Chromium‑based), Brave, Opera and Vivaldi. When a security problem is found in Chromium, Google typically fixes the issue in Chromium and publishes a Chrome Stable update that contains the remediation. Downstream vendors then “ingest” the upstream fix, perform their own testing and ship a browser build that includes that Chromium revision. Microsoft records the upstream CVE and the Edge ingestion/mitigation status in its Security Update Guide (SUG) so administrators can tell whether their Edge build contains the Chromium patch.In late‑September 2025 Google promoted Chrome 141 to the Stable channel and that release included fixes for multiple high‑severity memory‑safety issues — notably CVE‑2025‑11205 (WebGPU) and CVE‑2025‑11206 (heap buffer overflow in Video). Chrome Releases and multiple security vendors list Chrome 141.0.7390.54/.55 as the first stable builds that remediate these issues.
This article explains why Microsoft documents Chromium CVEs in the Security Update Guide, how to verify whether your browser is patched, the practical and enterprise implications of the ingestion lag between Chrome and Edge, and recommended mitigation and detection steps.
Why Chromium CVEs appear in Microsoft’s Security Update Guide
The upstream/downstream relationship — simple and operational
- Chromium (upstream) is the open‑source project where the bug was found and fixed.
- Google Chrome packages those upstream changes and releases official Chrome builds (the public remediation).
- Microsoft Edge consumes Chromium source; Microsoft ingests upstream fixes, integrates them into Edge, runs compatibility and security testing, then ships Edge builds that include the Chromium patch.
Why the SUG entry matters operationally
- It prevents administrators from assuming instant parity with Chrome. A Chrome Stable release does not automatically mean Edge is patched the same day; Microsoft’s ingestion and test cycle introduces a controlled lag.
- The SUG entry becomes the authoritative downstream statement for Edge: it tells you if Microsoft has integrated the upstream fix and shipped it in Edge. Use the SUG entry to validate Edge's status for that CVE.
The technical snapshot: CVE‑2025‑11206 (heap buffer overflow in Video)
What the CVE summary says (concise)
- Fault type: heap buffer overflow (out‑of‑bounds write) in the Video (media) processing code.
- Impact: Memory corruption in renderer/media processes; in favorable conditions an attacker could convert that into code‑execution or sandbox escape, though exploitation requires a chain and platform‑specific conditions.
- Trigger: Processing of crafted or malformed video/media content delivered via a web page or embedded media stream.
Why video/media bugs are dangerous
Video and media pipelines frequently interact with native codecs, hardware acceleration (GPU drivers) and privileged helper processes. Memory‑safety defects in these code paths can be easier to turn into reliable primitives for exploitation because:- They touch lower‑level, native code and often have larger attack surface than pure DOM/JavaScript logic.
- Some media parsing or decoding happens automatically (thumbnailing, autoplay, preview) which increases exposure.
- A successful memory corruption in a privileged process can be combined with other bugs for sandbox escape. Security practitioners therefore treat heap overflows in media subsystems with high priority.
How to see the version of the browser — step‑by‑step (exact, actionable)
Below are the most reliable methods to confirm the exact browser version you’re running and whether it corresponds to the patched build for CVE‑2025‑11206.Microsoft Edge (desktop) — quick check
- Open Microsoft Edge.
- Click the three‑dot menu (Settings and more) in the top‑right.
- Choose Help and feedback → About Microsoft Edge (or navigate to edge://settings/help).
- The About page displays the full Edge version and immediately triggers an update check; if an update is available the browser will download it and display a Relaunch/Update button.
- For more detail, visit edge://version or edge://system to see the underlying Chromium revision and additional build metadata. The Chromium revision line is the piece you compare to Chromium/Chrome remediation boundaries.
Google Chrome (desktop) — quick check
- Open Chrome.
- Click the three‑dot menu → Help → About Google Chrome (or go to chrome://settings/help).
- Chrome displays the full version and triggers an update check; relaunch if an update is installed.
- For extra detail use chrome://version to see the full build string and the underlying Chromium revision.
Mobile versions (Android / iOS)
- Open the app’s Settings → About section (Android and iOS Chrome/Edge expose a version string there).
- Mobile browsers do not always report the underlying Chromium revision in the same detail as desktop; use the app store listing or vendor release notes for mapping if needed.
Enterprise / managed devices
- If updates are managed centrally (SCCM/MECM, Intune, WSUS, or other MDM), the browser may not update automatically. Contact your IT or patching team to confirm which Edge/Chrome build will be deployed or has been deployed.
- Use your endpoint management inventory to query installed versions at scale and compare against the patched build boundary published by the vendor and in the Security Update Guide.
How to interpret the version — what number indicates “safe”?
- For Chrome: the Chrome Releases announcement for the September 2025 Stable promotion names Chrome 141 and the fixed micro builds as 141.0.7390.54/.55 for desktop platforms. If Chrome reports a local version equal to or greater than that micro build, Chrome has the upstream fix for CVE‑2025‑11206.
- For Edge: Microsoft’s Security Update Guide entry for the CVE is the authoritative downstream statement. The SUG entry will indicate which Edge build (and channel) includes the Chromium ingestion — confirm your Edge version is equal to or greater than that build to know Edge is no longer vulnerable. Do not assume parity simply because Chrome is patched upstream; verify ingestion in the SUG or Edge release notes.
Mapping Chromium/Chrome builds to Edge builds — the ingestion lag problem
The reality of the lag
- Google publishes the Chrome fix as soon as Google judges it ready for stable release.
- Microsoft must ingest that Chromium change, rebuild Edge, run regression, compatibility and security tests, and then publish the Edge build.
- That ingestion/test cycle creates a window in which Chrome users may already be patched while Edge users remain vulnerable until Microsoft ships the corresponding Edge build. The Security Update Guide documents exactly when Microsoft has completed ingestion and shipped the Edge remediation.
Practical guidance for administrators
- Use the Security Update Guide entry for CVE‑2025‑11206 to determine the Edge build number that contains the fix. Confirm the build across your fleet.
- If Edge has not been patched yet in your organization and immediate parity with Chrome is required, consider temporary compensating controls (see mitigations section below).
Mitigation, compensating controls, and detection
Immediate actions for home users
- Update Chrome or Edge now: open About (chrome://settings/help or edge://settings/help) and install any available update; relaunch to complete installation. Chrome 141.0.7390.54/.55 is the patched Chrome build for this set of fixes.
- If you use Edge and the SUG entry shows Edge ingestion is not yet published for your channel, treat the browser as potentially vulnerable until you confirm the Edge build in SUG or through edge://version.
Practical compensating controls (when Edge is not yet ingested)
- Disable or limit WebGL and hardware acceleration on high‑risk endpoints (reduces the attack surface for GPU/ANGLE/video bugs).
- Restrict browsing to allowlisted sites on sensitive machines.
- Use web‑filtering or proxy controls to block or isolate untrusted sites.
- Ensure EDR and logging agents are up to date and configured to capture process crashes and post‑exploit behaviors.
For enterprises and embedded systems
- Inventory all Chromium binaries: desktop Chrome and Edge, but also embedded Chromium bundles (Electron apps, kiosk devices, point‑of‑sale systems, packaged apps). These embedded instances often do not auto‑update and represent a high operational risk if they remain pinned to a vulnerable Chromium revision.
- Use vulnerability scanners and patch management tools to locate pre‑patch versions; Tenable/Nessus published detection rules that map to “Chrome < 141.0.7390.54” for these issues — use those rules to find remaining vulnerable hosts.
- Stage, pilot and expedite rollout to the highest‑exposure cohorts (remote admins, privileged users, devices exposed to public browsing).
Detection and monitoring
- Watch for sudden spikes in renderer or media process crashes — a common indicator of exploit attempts against memory‑safety bugs.
- Monitor your EDR telemetry for signs of memory corruption exploit chains and unusual child process creation from browsers.
- Ensure your threat intel and IDS/IPS signatures are up to date; multiple security vendors add signatures for in‑the‑wild exploitation patterns after upstream patches appear.
Cross‑checked verification of the fix (technical verification)
To satisfy verification requirements:- Google’s Chrome Releases page documents the Chrome 141 Stable promotion and lists the desktop fixed builds that correspond to the remediation. Use the Chrome Releases entry for September 2025 to confirm Chrome 141 and the micro build numbers.
- Independent security vendors and scanners (Tenable/Nessus, Snyk and others) published advisory/detection guidance mapping the CVE to Chrome 141.0.7390.54 as the update boundary; scanning rules and vendor advisories recommend upgrading to Chrome 141.0.7390.54 or later. This cross‑check corroborates the Chrome Releases posting.
- Microsoft’s Security Update Guide is the downstream authoritative record for Edge ingestion; the SUG entry clarifies when Microsoft has shipped the ingestion for Edge builds and hence when Edge customers are not vulnerable. Use the SUG entry together with edge://version to confirm your Edge build’s status.
Critical analysis: strengths, caveats and residual risks
Strengths of the vendor response and ecosystem
- Rapid upstream remediation: Google issued Chrome 141 to address multiple high‑severity memory issues in the same release window, showing fast triage and coordinated remediation. Chrome’s stable‑channel notifications and micro build numbers are clear and machine‑readable, helping administrators map remediation status.
- Cross‑vendor tracking: Microsoft’s practice of recording Chromium CVEs in the Security Update Guide provides operational clarity for Edge customers about ingestion status. That improves transparency and helps admins validate protection across the ecosystem.
- Multiple vendor corroboration: Security vendors and scanners published detection and remedial guidance mapping to Chrome 141, enabling automated discovery and verification at scale.
Caveats and residual risks
- Downstream ingestion lag: The time between Google’s Chrome release and Microsoft’s Edge ingestion is the highest‑value operational risk window. Organizations that assume immediate parity will be exposed until Edge ships the ingest build. The SUG entry is essential to closing this knowledge gap.
- Embedded and pinned Chromium: Electron‑based applications and other embedded Chromium shells do not necessarily receive the Chrome Stable update and may remain vulnerable long after desktop browsers are patched. These instances require explicit vendor updates or app repackaging.
- No public exploit ≠ no risk: Even where no confirmed public proof‑of‑concept exists for this specific CVE, media and ANGLE bugs have historically been weaponized within exploit chains. Treat unpatched systems as high priority regardless of public exploit status.
- Managed update controls: In enterprise environments that freeze images or strictly control update windows, endpoints can remain vulnerable until the organization approves and deploys the update; that requires governance and an inventory‑driven patch plan.
Practical checklist — what to do now (concise)
- For home users:
- Open the browser (Chrome or Edge) → About → install updates and Relaunch. Confirm the build is at/above the patched micro build (Chrome 141.0.7390.54/.55 for desktop).
- For Edge users unsure of ingestion:
- Check Microsoft’s Security Update Guide entry for CVE‑2025‑11206 and compare your edge://version output to the Edge build listed in SUG. Do not assume parity until SUG confirms ingestion.
- For IT administrators:
- Inventory all Chrome/Edge/Electron instances, map versions to the remediation boundary, and patch via your MDM/patch pipeline.
- If Edge ingestion hasn’t landed yet, apply compensating controls for high‑risk endpoints (disable WebGL/hardware acceleration, restrict browsing, update EDR rules).
- For teams managing embedded apps:
- Contact vendors for patched app bundles or plan to repack/redeploy updated runtime that includes the patched Chromium revision.
- For detection and monitoring:
- Update scanner signatures and EDR detection rules; monitor for increased browser crashes and unusual process behavior.
Conclusion
CVE‑2025‑11206 is an upstream Chromium heap buffer overflow in the Video component that Google remediated in Chrome 141 (desktop micro builds 141.0.7390.54/.55). Microsoft records Chromium CVEs in the Security Update Guide to declare the downstream ingestion and remediation status for Microsoft Edge (Chromium‑based); this informs administrators whether their Edge builds contain the upstream fix or remain vulnerable. The single best actions are (1) confirm your browser version using the About pages (chrome://settings/help or edge://settings/help and the version pages), (2) update to the patched builds as soon as they’re available for your browser, and (3) for organizations, inventory all Chromium binaries (including embedded/pinned instances) and use the SUG entry to verify Edge’s ingestion status before assuming protection.Treat the ingestion lag and embedded Chromium instances as the main operational risks, and prioritize detection, compensating controls and rapid deployment where necessary. The SUG entry exists to help you do exactly that — to know when Microsoft has finished the work of integrating the upstream Chromium patch into Edge.
Source: MSRC Security Update Guide - Microsoft Security Response Center