The Chromium project assigned CVE‑2026‑3931 to a heap buffer overflow in the Skia 2D graphics library; Google fixed it in the Chrome 146 stable updates (the patch appears as part of Chrome 146.0.7680.71), and Microsoft has recorded the issue in its Security Update Guide so Microsoft Edge customers can see whether the downstream Edge builds have ingested the upstream Chromium fix. (
chromereleases.googleblog.com)
Background / Overview
Skia is the open‑source 2D graphics engine used by Chromium and therefore by every Chromium‑based browser (Google Chrome, Microsoft Edge, Brave, Opera, and others). Vulnerabilities in Skia repeatedly show up as heap or stack buffer overflows when malformed drawing data or crafted web content causes out‑of‑bounds memory access. CVE‑2026‑3931 is described as a
heap buffer overflow in Skia that allowed out‑of‑bounds memory access via a crafted HTML page, and the Chrome team lists it in the March 2026 Chrome 146 stable release notes. (
chromereleases.googleblog.com)
Microsoft’s Security Update Guide (SUG) includes CVEs that originate from upstream projects (like Chromium) for one practical reason: Microsoft Edge is built on Chromium. By documentCcommunicates to Edge users and enterprise customers whether the current Edge builds contain the Chromium upstream fix and are thus no longer vulnerable. This is primarily a
status/ingestion and
customer communication function, not an indication that Microsoft produced the original fix.
In short:
- Google/Chromium finds and fixes a vulnerability and publishese release that contains the patch. (chromereleases.googleblog.com)
- Microsoft monitors Chromium changes, ingests fixes into Edge on Microsoft’s release cadence, and records both the upstream CVE and Microsoft’s ingestion status in SUG so Edge administrators can verify protection.
Why this Chromium CVE is documented in Microsoft’s Security Update Guide
The upstream / downstream relationship explained
Chromium is an open‑source engine. Google publishes fixes to Chromium and Chrome; other vendors (Microsoft, Brave, Opera, Samsung, etc.) take Chromium snapshots and incorporate them into their own products. That creates a two‑step timeline for fixes:
- Upstream fix appears in the Chromium/Chrome codebase and is shipped by Google in a Chrome releathat release is Chrome 146.0.7680.71 or later). (chromereleases.googleblog.com)
- Downstream vendors validate, test, and roll the upstream change into their own product builds and release it to customers. Microsoft records this downstream ingestion status in SUG so customers know the Edge build that contains the fix—or, conversely, which buildsThis model explains why the same CVE can appear in:
- Google’s Chrome release notes (the vendor that assigned the CVE and shipped the fix upstream). (chromereleases.googleblog.com)
- Public CVE repositories and NVD (standardized metadata about the vulnerability, affected versions, severity). (nvd.nist.gov)
- Microsoft’s Security Update Guide when Microsoft consumes the upstream fix into Edge and needs to communicate its status to custooft does this—practical benefits for enterprises
Listing upstream CVEs in SUG serves several enterprise needs:
- Single pane of glass: Security teams use SUG as a canonical Microsoft‑product tracking to are listed there with ingestion status, Edge administrators can reconcile their inventories and compliance reports without having to cross‑reference Google’s release notes for every single CVE.
- Patch‑validation: SUG entries tell you whether an Edge build includes the patch—so you can validate that your device fleet is protected.
- Audit & compliance: Many organizations must document when a vendor acknowledged a vulnerability and when it was remediated in the vendor’s supported product; SUG entries provide that record for Edge.
Bottom line: inclusion in SUG is a communication and verification mechanism to help Edge users map upstream fixes to their downstream Edge builds. It is not an accusation that Microsoft created the issue.
CVE‑2026‑3931 — the technical facts (verified)
- What it is: Heap buffer overflow in Skia that may be triggered by a crafted HTML page causing out‑of‑bounds memory access. This is a memory‑corruption class of bug (CWE‑122).
- Where it was fixed upstream: Chrome 146 stable release; Chrome’s Stable Channel update lists CVE‑2026‑3931 among the security fixes addressed in Chrome 146. (chromereleases.googleblog.com)
- Severity: Chromium’s metadata lists this as a Medium severity issue for this entry; upstream advisories and the CVE record summarize the attack vector as a crafted HTML page. (Always check the original vendor advisory for exploitation details and CVSS if you need precise risk scoring.)
Caveat: public CVE summaries often omit exploitation specifics for restricted bugs, and vendors sometimes withhold exploit details until a majority of users are patched. If you require a proof‑of‑concept or exploitability analysis, expect that information to be gated or delayed until the majority of users receive the patch. Chrome’s release notes occasionally flag such restrictions. (
chromereleases.googleblog.com)
How to check whether your browser is vulnerable — step‑by‑step
The practical question is: “Is my browser build older than the fixed build?” The following steps tell you exactly how to check both Chrome and Microsoft Edge and how to interpret what you see.
1) Identify the fixed upstream version (example: CVE‑2026‑3931)
- For CVE‑2026‑3931 the Chromium/Chrome record lists the fixed Chrome stable build: Chrome 146.0.7680.71 (Windows/Mac/Linux variants appear in the Chrome 146 promotion). Use the Chrome release notes or NVD/CVE records to obtain this canonical fixed version. (chromereleases.googleblog.com)
2) Check Google Chrome (desktop)
- Open Chr bar type chrome://version and press Enter. The page shows the browser’s full version string (for example: 146.0.7680.71). This is the fastest, most precise way to get the exact build.
- Alternatively, open the menu (three dots) → Help → About Google Chrome. That page also reports the version and triggers an update check; relaunch if an update is applied. ([webnots.com](https://www.webnots.com/5-ways-to-check-google-chrome-version/?utm_source=opena If your Chrome version is less than 146.0.7680.71, your Chrome installation is in the vulnerable range and you should update. If it is equal to or greater than 146.0.7680.71, Chrome itself contains the upstream fix. (chromereleases.googleblog.com)
3) Check Microsoft Edge (desktop, Chromium‑based)
- Open Edge.
- In the address bar type edge://version and press Enter, or open the menu (three dots) → Help and feedback → About Microsoft Edge. Both pages display:
- The full Edge version string.
- The underlying Chromium version that Edge is currently using (the “Chromium” or “based on” line).
- If About Edge triggers an update and applies one, relaunch the browser to complete the update.
Interpretation:
- Edge has its own version string and a separate mapping to an underlying Chromium revisiothe underlying Chromium revision shown by edge://version to the fixed Chromium version (e.g., 146.0.7680.71). If the Chromium version shown is the same or newer, Edge has upstream Chromium 146 and therefore has the upstream fix—assuming Microsoft documented that ingestion in SUG or Edge release notes.
d environments
- Mobile apps (Android/iOS): check the app’s About/Settings screen for the app version. Mobile builds often don’t show the precise Chromium revision; consult vendor release notes or SUG for mapping.
- Kiosk builds, Electron apps, or embedded Chromium: many packaged apps embed a specific Chromium binary and will not update automatically with your system browser. Inventory thesrequires rebuilding the app with a newer Chromium.
Verifying Microsoft’s ingestion status (how to be certain Edge is no longer vulnerable)
- Open the Microsoft Security Update Guide entry for the CVE (SUG entries show when Microsoft recorded the CVE and often include a statement that Edge “is no longer vulnerable” once the ingestion has occurred). If SUG marks the CVE as “Not Affected” or notes the fixed Edge build, that is Microsoft’s official signal that CVE. (SUG is the authoritative Microsoft communication for this purpose.)
- Cross‑check Edge release notes: Microsoft publishes Edge release notes that describe which Chromium updates were consumed for a given Edge release. If SUG shows the ingestion and the Edge release notes list the corresponding Chromium change, you can match that Edge build to devices in your inventory.
- Compare the underlying Chromium version reported by edge://version to the Chromium fixed version. If the Chromium revision reported by Edge is the same or newer, and SUG/Edge release notes confirm ingestion, your Edge build is patched.
Important caution: do not assume Chrome being patched automatically means Edge is patched. Microsoft and other downstream vendors adopt changes on their own release cadence and sometimes perform additional validation; always confirm ingestion status via SUG or Edge release notes.
Practical examples and walk‑throughs
Example: verifying protection from CVE‑2026‑3931
- Confirm upstream fixed Chrome version: 146.0.7680.71 (Chrome stable channel). (chromereleases.googleblog.com)
- On a Windows workstation running Edgesion and note the “Chromium” field. If it reads 146.0.7680.71 or newer, the underlying Chromium revision contains the upstream fix.
- Then open Microsoft’s Security Update Guide entry for CVE‑2026‑3931 and confirm Microsoft has recorded the ingestion (SUG will indicate if Edge builds are no longer vulnerable). If SUG shows ingestion, you’re good.
- If Edge reports an older Chromium revision or SUG does not show ingestion, update Edge (Menu → Help and feedback → About Microsoft Edge) or coordinate with your enterprise update process.
If you run Chrome instead of Edge, the check is simpler: chrome://version shows the version. If it is 146.0.7680.71 or newer, Chrome is patched. ([webnots.cs.com/5-ways-to-check-google-chrome-version/)
Recommended actions (consumer and enterprise)
- Consumers / individual users:
- Update your browser now (About page triggers an update and shows status).
- Restart the browser after updates are applied.
- If you use multiple Chromium‑based browsers, update each one separately; their release cadences differ.
- IT administrators and security teams:
- Infor installed Edge/Chrome versions (use MDM, SCCM, Intune, JAMF, or other inventories).
- Query edge://version / chrome://version programmatically where possible; many enterprise tools can extract installed package version strings from endpoints for reporting.
- Verify SUG ingestion: map enterprise builds to the Edge build that Microsoft lists as containing the upstream Chromium fix; deploy updates to devices still on older builds.
- For embedded Chromium (Electron apps, kiosks): identify which apps include a bundled Chromium binary; these do not auto‑update with the system browser and must be rebuiendor.
- Prioritize internet‑facing and high‑risk hosts for immediate updates.
- For security monitoring:
- Watch SUG entries and Chrome/Chromium release announcements for critical and actively‑exploited vulnerabilities; integrate that timeline iicies. (chromereleases.googleblog.com)
Risk analysis: strengths, liml pitfalls
Strengths of Microsoft’s SUG approach
- Centralized visibility for organizations that rely on Microsoft’s security lifecycle and reporting.
- Clear ingestion signals reduce ambiguity about whether Microsoft Edge is protected against an upstream Chromium issue.
- Helps compliance and auditing processes that require vendor confirmation of remediation.
Limitations and potential risks
- Timing mismatch: Chromium may ship a fix quickly, but downstream vendors take time to ingest and ship it. Attackers can exploit that gap, so enterprises must act to minimize exposure during the window. (chromereleases.googleblog.com)
- Mapping complexity: Edge has its own versioning and a separate Chromium mapping; naive comparisons of otring (without checking the underlying Chromium revision or SUG ingestion notes) can lead to false confidence.
- Embedded Chromium risk: many third‑party apps bundle Chromium. Those bundled binaries remain vulnerable until the packager updates — these are often invisible to standard browser patching controls and require separate inventory and patching workflows.
Operational pitfalls to avoid
- Don’t assume all Chromium‑based browsers are patched when Chrome updates — each vendor has its own release schedule.
- Don’t rely solely on automated update checks if enterprise policies block immediate updates; maintain an offline inventory and a remediation schedule.
- Avoid treating SUG entries as optional: if Microsoft lists a CVE and indicates ingestion, use that as an authoritative signal for remediation status for Edge in your environment.
What to do if you cannot get a definitive answer from SUG or Edge release notes
- If the SUG entry is ambiguous or SUG’s web UI is slow/blocked in your environment (the SUG web UI may r and scripts), you can:
- Use your endpoint inventory to capture the Chromium revision reported by edge://version across your fleet and compare it to the Chrome fixed revision.
- Contact Microsoft support or your vendor representative for an official statement about ingestion if the timeline is critical to compliance or incident response.
- If you manage headless or embedded Chromium binaries:
- Contact the application vendor for a rebuild or patch plan.
- If the vendor is slow, consider compensating controls (network restrictions, content filters, EDR rules) to reduce exposure until the application is updated.
Final checklist — confirm you’re protected against CVE‑2026‑3931
- Find the upstream fixed Chromium/Chrome version for CVE‑2026‑3931 (Chrome 146.0.7680.71). (chromereleases.googleblog.com)
- On each endpoint, open edge://version (Edge) or chrome://version (Chrome) and note the full version strings and the underlying Chromium revision.
- Confirm Microsoft’s SUG entry for CVE‑2026‑3931 indicates that Edge builds you use have ingested the patch; if SUG shows ingestion, match that Edge build to your fleet.
- Update and restart browsers where needed; for embedded Chromium in third‑party apps, coordinate vendor patches or apply compensating controls.
- Document the remediation date and version in your change/asset management records for auditing.
Closing assessment
CVE‑2026‑3931 is a classic example of an
upstream open‑source vulnerability that ripples through an ecosystem of downstream products. Google fixed the issue in Chrome 146; Microsoft documented the Chromium CVE in its Security Update Guide to transparently tell Edge customers when Edge builds have absorbed the fix. The operational responsibility now sits with users and IT teams: verify versions (edge://version or chrome://version), confirm SUG/Edge release notes ingestion, and update any third‑party or embedded Chromium instances that don’t auto‑update.
If you follow the step‑by‑step checks above—identify the upstream fixed revision, read edge://version / chrome://version on your endpoints, and cross‑reference Microsoft’s SUG ingestion signal—you will have the verification you need to show whether your environment is protected from CVE‑2026‑3931. (
chromereleases.googleblog.com)
Source: MSRC
Security Update Guide - Microsoft Security Response Center