Microsoft’s Security Update Guide lists CVE‑2026‑3920 not because Microsoft wrote the bug, but because Microsoft Edge (the Chromium‑based browser) consumes upstream Chromium code — the Security Update Guide entry is Microsoft’s official signal to Edge customers that the upstream Chromium fix has been ingested and shipped in an Edge build, and therefore Edge installs running that build are no longer vulnerable. erview
CVE‑2026‑3920 is described as an
out‑of‑bounds memory access in WebML and was fixed upstream by the Chromium/Chrome team in Chrome 146. The Chrome stable update that includes the fix is identified as Chrome 146.0.7680.71 (Windows/macOS/Linux builds listed in the March 2026 Stable Channel update), which Google published as part of the Chrome 146 promotion.
Because Microsoft Edge is built on the Chromium open‑source project, the practical risk model for Edge users is not the original CVE assignment (which is handled by Chromium/Google) but whether Microsoft has integrated the Chromium patch into an Edge release and pushed that release to customers. Microsoft records that downstream ingestion status in the Microsoft Security Update Guide (SUG), which is the canonical place for Windows/Edge administrators to check whether a given CVE is still present in their proherefore serves as a downstream ‘patched/not patched’ signal for Edge customers.
What CVE‑2026‑3920 is (technical summary)
- Component: WebML (a browser API/implementation for on‑device machine learning capabilities inside the browser).
- Issue: Out‑of‑bounds memory access that can lead to heap corruption when parsing or handling specially crafted content.
- Impact: A remote attacker could trigger heap corruption by convincing a user to load a crafted page, which may lead to memory corruption and potentially further impact such as crashes or code execution depending on surrounding memory layout and exploitability.
- Fixed in upstream Chromium/Chrome: Chrome 146.0.7680.71 and later.
A short caveat: Chromium security advisories frequently withhold detailed exploitability and PoC details until the majority of users receive a fix. That deliberate restriction is common practice but means public writeups can be sparse at first; treat limited details as intentional disclosure hygiene rather than lack of transparency.
Why Microsoft lists Chromium CVEs in the Security Update Guide
When security researchers or the Chromium team assign a CVE to a Chromium component, that CVE applies to the upstream project and to any downstream browsers that include the vulnerable code. Microsoft’s Edge (Chromium‑based) is a downstream consumer of Chromium OSS, so Microsoft needs to:
- Track upstream CVEs that affect components included in Edge.
- Document whether and when Microsoft has merged the upstream fix into Edge and shipped a patched Edge build.
- Give administrators a single place to confirm whether an Edge install is protected.
The SUG entry for a Chromium CVE therefore does not mean Microsoft introduced theans Microsoft is reporting the downstream patch status for Edge so customers can verify protection. This explanation has been the consistent behavior in Microsoft’s SUG entries for Chromium CVEs and is used repeatedly in guidance to Edge users and enterprises.
How to see the version of your browser (step‑by‑step)
If you want to know whether your Edge install is protected against CVE‑2026‑3920 you must read two things from your browser’s About / Version data:
- The Edge application version (the Edge version string shown in About).
- The underlying Chromium / Blink build number that the Edge version maps to (Edge’s version string often includes a Chromium build mapping on internal pages such as edge://version).
Use one of these user‑facing methods to check quickly:
- Open Microsoft Edge.
- Click the three‑dots menu (Settings and more) at the top right.
- Choose Help and feedback → About Microsoft Edge. The page opens and shows the Edge version and update status. Edge will also automatically check for updates.
Alternative quick checks:
- Type edge://settings/help or edge://version (or edge://system) in the address bar and press Enter. The internal pages display the full Edge version, and edge://version shows the underlying Chromium version and command‑line flags. Use the Chromium build number shown there to map to the patched Chrome build.
On macOS, Linux or mobile platforms the same "About" flow applies; on Android and iOS the About section in the app settings shows the version string and channel. Third‑party documentation also lists these standard steps and the edge://version trick as the most reliable method to see both Edge and Chromium engine versions.
How to interpret the version string and determine whether you’re patched
Edge's About page shows a version number like "Microsoft Edge 114.0.xxxx.xx". Internally, edge://version displays the "Chromium" or "User Agent" and/or "Browser version" lines, which include the embedded Chromium build number (for example, Chromium: 146.0.7680.71). The engineering workflow for determining patched state CVE and the Chromium build that fixed it upstream (for CVE‑2026‑3920 this is Chrome 146.0.7680.71).
2. Check the Edge install’s Chromium build in edge://version.
3. If the Edge Chromium build is equal to or newer than the patched Chromium build, your Edge install contains the upstream fix; if older, it does not.
Put simply: you don’t compare “Edge major versions” alone — you compare the
embedded Chromium build that Edge is using. Microsoft documents ingestion mapping in the SUG entry for downstream CVEs to tell you which Edge versions contain the fix; use that mapping as the authoritative downstream source.
Enterprise and automation: ways to check large fleets
For administrators responsible for many endpoints, manually opening About pages is not practical. Use these techniques:
- Use your endpoint management tool (SCCM / Intune / WSUS where applicable) to inventory installed Ese the edge application version strings to derive Chromium builds.
- Query installed programs via PowerShell and inspect version resources of the Edge executable (msedge.exe). Example PowerShell snippet:
- Use Get‑ItemProperty on the Edge executable path to return FileVersion.
- Map that file version to Edge release notes or Microsoft SUG mapping.
- Use the edge://version output through an automated remote instrument (if you can script a headless Edge session to dump version info), or leverage process inventory agents that read version metadata.
Finally, consult Microsoft’s SUG entry for the CVE to find the Edge build mapping — Microsoft will list which Edge releases incorporate the Chromium fix. SUG is the downstream authoritative signal for enterprises.
Practical timeline and patch cadence — why there’s sometimes a lag
There are two independent cadence tracks romium publishes upstream patches (Chrome releases) on its release cadence. For CVE‑2026‑3920 the fix landed in Chrome 146.
- Downstream vendors (Microsoft, Brave, Opera, Vivaldi, etc.) integrate upstream fixes into their own builds, test for product regressions, and then ship updates on their own cadence.
Because vendors must perform platform testing, product QA, corporate release approvals, and sometimes additional mitigation work (e.g., enterprise support features), there is often a gap between the Chrome stable release date and the downstream vendor's patched release. Microsoft records that downstream ingestion and release status in the SUG entry so administrators can see the exact Edge build that includes the fix.
This lag isnly phenomenon nor evidence of negligence; it’s a structural reality of downstream consumption of a widely reused open‑source component. Still, the lag is operationally significant for defenders: during the window between upstream disclosure and downstream ingestion, threat actors may prioritize crafting exploits for widely used components. That’s why enterprises should treat upstream Chrome security advisories as early warning signals even before downstream builds are available.
Risk analysis: what Edge users should care about now
Strengths (what’s working well)
- Centralized signal: Microsoft’s Security Update Guide gives enterprises a single place to check Edge‑specific status for Chromium CVEs instead of hunting upstream bulletins and doing mapping themselves. This reduces ambiguity and supports compliance workflows.
- Upstream transparency: Google’s Chrome Releases and Chromium issue tracker provide the initial technical fix and version mapping; that upstream data facilitates rapid triage by security teams.
Weaknesses and risks
- Patch lag: downstream ingestion and QA mean that Edge users may remain vulnerable within a window after Chrome publishes a fix. Attackers can target the widest common denominator; if many users delay Edge updates, the window grows.
- Version confusion: non‑technical users often compn" major numbers and miss the underlying Chromium build mapping, creating false confidence. The correct check requires looking at edge://version or the SUG mapping.
- Observability gaps: detecting exploitation of such a memory corruption in the wild is nontrivial; heap corruption may leave noisy crash artifacts or subtle post‑exploit persistence. Enterprises without robust telemetry may miss active exploitation. Be skeptical of "no known exploit" — absence of public PoC does not guarantee the vulnerability is not being exploited privately.
Operational advice
- Treat upstream Chrome security posts as an alert to begin prioritization even before a downstream SUG entry appears.
- For high‑value devices, accelerate update cadence or apply compensating controls (control access to risky content, disable features where feasible, strict web filtering).
- Use SUG as the downstream confirmation step: when Microsoft signals the CVE as "not affected" for your Edge version, you’re safe for that product version.
Mitigations, workarounds and detection guidance
Immediate steps for end users:
- Open Edge → About Microsoft Edge → allow it to check for updates and restart. If an update is available that maps to the patched Chromium build, apply it.
- If you use Chrome desktop, update Chrome to the fixed Chrome 146.0.7680.71 (or later) to close the upstream vulnerability. Check chrome://settings/help or chrome://version to confirm.
Enterprise mitigations:
- Block or sandbox risky content types and reduce attack surface by restricting untrusted web content for high‑risk roles.
- Use application control to restrict which Edge/Chrome channels are allowed on sensitive hosts to control upgrade timing centrally.
- Ensure telemetry (browser crash reporting, EDR hooking of process anomalies, network proxy logs) is collecting signals that can detect successful or attempted exploitation (unexpected renderer crashes, suspicious post‑crash child process activity, anomalous network callbacks after renderer failures).
Workarounds to reduce risk temporarily (use with caution):
- Consider disabling the WebML API only if your environment does not require it and you haely. Note: this is a niche mitigation; not all browsers expose a simple enterprise policy to disable WebML, and blanket disabling can break legitimate functionality. Confirm policy availability before implementing. (If you need a staged plan, test in a lab first.)
- Isolate untrusted browsing in a dedicated VM or use "browser isolation" services to reduce endpoint exposure.
Detection playbook (high level):
- Monitor for renderer crashes or repeated crash loops tied to the Edge/Chromium process after browsing events.
- Look for unusual child‑process spawns or post‑crash persistence activity.
- Use network proxy logs to correlate crash events with visits to potentially malicious domains.
- If you suspect compromise, collect forensic memory and full system images for offline analysis and patch immediately.
When in doubt, consult the SUG entry for oidance and the Chrome Releases announcement for upstream details.
How Microsoft’s SUG entry helps administrators — and its limitations
Why it helps
- The SUG provides the downstream mapping: it shows Microsoft’s product(s) and exact version(s) that are patched or vulnerable. That allows security teams to align patch management and reporting processes to a single Microsoft source when Edge is in scope.
Limitations you should understand
- SUG reflects Microsoft’s downstream ingestion schedule, which may lag upstream disclosure. Don’t conflate the SUG entry date with the upstream fix date; treat them as two complementary signals (upstream technical fix vs downstream product ingestion).
- The SUG page itself may be dynamically rendered and requires JavaScript in browsers for the best experience; some automated scrapers must use the API endpoints or an approved integration to pull the status reliably for automation. (If you’re automating SUG checks, use available APIs or tooling that respect SUG’s format.)
Example FAQ: Quick answers
- Q: "Does the SUG entry mean E the bug?"
A: No. It records the downstream ingestion state for Edge after an upstream Chromium CVE was assigned.
- Q: "Which Chrome version fixed CVE‑2026‑3920?"
A: Chrome 146.0.7680.71 is reported as the patched build for CVE‑2026‑3920. Confirm via Chrome Releases and Cross‑reference SUG for Edge mapping.
- Q: "How do I know my Edge is patched?"
A: Open edge://version or About Microsoft Edge and compare the embedded Chromium build to the patched Chromium build listed by Chrome Releases or the Microsoft SUG ingestion mapping.
Final recommendations and checklist
- Check your browser now:
- Edge: edge://settings/help or edge://version → confirm Chromium build.
- Chrome: chrome://settings/help or chrome://vd is 146.0.7680.71 or later.
- Apply updates promptly:
- For individual users: allow the browser to update and restart.
- For enterprises: schedule emergency or expedited updates for high‑risk collections of devices and verify via inventory.
- Use SUG for downstream confirmation:
- Use Microsoft’s Security Update Guide to check which Edge builds include the Chromium fix before declaring your Edge fleet protected.
- Strengthen detection:
- Tune EDR and browser crash telemetry to detect anomalies that may indicate attempted exploitation.
- Reduce attack surface while waiting:
- Where feasible, apply temporary compensating controls (isolation, web content filtering, blocking untrusted sites).
Conclusion
CVE‑2026‑3920 is an upstream Chromium security bug fixed in Chrome 146. Microsoft documents the CVE in the Security Update Guide to tell Edge customers whether the downstream Edge build they run contains the upstream fix. The simplest way for individual users to verify protection is to open About Microsoft Edge or edge://version and compare the embedded Chromium build to the patched Chromium build (Chrome 146.0.7680.71 or later for this CVE). Enterprises should treat upstream Chrome advisories as early warning signals, use Microsoft’s SUG for downstream confirmation, and deploy a short, aggressive patch‑and‑detect program to minimize exposure during the ingestion lag.
Source: MSRC
Security Update Guide - Microsoft Security Response Center