A high‑severity use‑after‑free bug in the WebMIDI implementation — tracked as CVE‑2026‑3923 and published in mid‑March 2026 — was fixed upstream in Chromium/Chrome and is now being tracked in Microsoft's Security Update Guide to tell Edge administrators when their downstream browser builds have ingested the Chromium patch and are no longer vulnerable.
Background / Overview
Chromium is an open‑source browser engine and codebase that Google develops; commercial products such as Google Chrome, Microsoft Edge (Chromium‑based), Brave, Opera and others all consume the Chromium codebase. When the Chromium project discovers and assigns a CVE to a security defect, downstream vendors normally pull the upstream fix into their own builds and then publish their own advisories. Microsoft’s Security Update Guide (the MSRC portal) lists Chromium CVEs when they are relevant to Microsoft Edge (Chromium‑based) so organizations can know whether the Edge build they run already contains the upstream fix.
CVE‑2026‑3923 is a
use‑after‑free vulnerability in the WebMIDI subsystem of Chromium. In practical terms this class of bug can allow an attacker to cause heap corruption by getting the browser to use memory that has already been freed; on the web platform a crafted page can trigger the condition that leads to corruption and — depending on surrounding mitigations and the exact bug chain — this sometimes enables code execution inside the renderer process or other escalations. Google released a fix in the Chrome/Chromium stable line; Microsoft recorded the same CVE in its Security Update Guide to indicate when Microsoft Edge builds include the fix.
What the vulnerability is — technical summary
- The problem is a use‑after‑free in WebMIDI, meaning the browser may access memory after that memory has been released. This is a classic memory safety flaw.
- The attack vector is a crafted web page that uses the WebMIDI API to exercise the buggy code path, which can lead to heap corruption.
- The immediate impact classification for this CVE is high, because browser renderer vulnerabilities that allow memory corruption can sometimes be turned into remote exploitation (sandbox bypass or code execution in the renderer sandbox), depending on exploitability and the platform’s mitigations.
Why WebMIDI? The WebMIDI API exposes connected MIDI devices to web pages (subject to permissions). It’s a relatively niche API compared with DOM and media subsystems, but it runs inside the renderer process and therefore shares the same risk profile if there's a memory safety issue in its implementation.
Important caveat: the exact exploitation mechanics (whether this CVE leads to code execution in practice, or requires additional bugs to chain into a full compromise) are dependent on the specific heap layout, the target platform, and mitigations like sandboxing, memory protection, and exploit mitigations. Treat the classification as indicating a serious risk; assume the potential for remote exploitation until vendor advisories say otherwise.
Why Microsoft included this Chromium CVE in the Security Update Guide
- Microsoft Edge (Chromium‑based) is built on the Chromium open‑source components. When Google or the Chromium project assigns a CVE for code inside Chromium, that same code is part of Edge’s engine.
- Microsoft maintains the Security Update Guide to show customers which CVEs are relevant to Microsoft products and whether those CVEs have been addressed in a shipped Microsoft build.
- When the SUG shows a Chromium CVE, it’s Microsoft’s downstream record that:
- acknowledges the vendor‑of‑origin (Chromium/Google) assigned the CVE, and
- indicates whether Microsoft Edge builds have ingested the upstream fix and thus whether Edge installations remain vulnerable.
- In short: the entry is informational and operational — it tells admins “this is a Chromium CVE that affects Edge too, and here’s whether your Edge version is safe.”
Put another way, Microsoft’s Security Update Guide is not reassigning the CVE to Edge; it’s documenting the fact that Edge consumes the patched Chromium code and announcing the Edge build status so IT teams can confidently confirm whether their Edge fleet is patched.
How to check whether your browser is affected — exactly what to look for
There are two separate but related checks you should perform:
- Identify the Chromium/Chrome version that contains the fix (the upstream fixed build).
- Verify whether your installed browser (Edge, Chrome, etc.) is at or above the build that contains the fix, or whether Microsoft’s Security Update Guide marks your Edge build as “no longer vulnerable.”
Practical steps for end users and administrators follow.
For end users — quick checks (Windows desktop)
- Microsoft Edge:
- Click the three‑dot menu (Settings and more) → Help and feedback → About Microsoft Edge.
- The About page fetches update information and shows your current Edge version. If an update is pending it will prompt and usually auto‑install.
- Alternatively, type edge://version in the address bar and press Enter. The edge://version page shows the Edge product version and the underlying Chromium revision and commit hash.
- Google Chrome:
- Click the three‑dot menu → Help → About Google Chrome.
- Or navigate to chrome://version which shows Chrome’s product version and its upstream revision information.
Both About pages will display a version string you can compare against the fixed build to know whether you still need the update.
For administrators — verification and mapping
- Microsoft’s Security Update Guide entry for the CVE will explicitly indicate whether Microsoft Edge has a build that contains the Chromium fix and will usually say something like “The latest Microsoft Edge is no longer vulnerable.” Use that SUG entry as the authoritative downstream status.
- If you manage Edge centrally:
- Check your inventory (SCCM/ConfigMgr, Intune, WSUS, or third‑party patching) to see which Microsoft Edge build is installed on clients.
- Compare that Edge build to the SUG entry and to Edge release notes that say “incorporates the latest Security Updates of the Chromium project.”
- Use edge://version or the About page to see the underlying Chromium revision if you need a one‑to‑one comparison.
- If you run Chrome instead of Edge: compare chrome://version to the upstream fixed Chrome build number.
The important numeric threshold for CVE‑2026‑3923
- The upstream Chromium/Chrome fix is present in Chrome builds starting at the Chromium build identified by Chrome 146.0.7680.71 (i.e., Chrome versions prior to 146.0.7680.71 are affected).
- That means: if your installed Chrome is older than 146.0.7680.71, update immediately.
- For Microsoft Edge, the mapping to Chromium revisions depends on which Edge release includes Chromium 146. Microsoft usually publishes release notes that show which web platform/Chromium features are included; the Security Update Guide entry also communicates whether the current Edge stable channel contains the fix.
Because vendor release numbering can differ, do not assume your Edge product version string is identical to Chrome’s; always verify via the About page or SUG entry.
How to update and remediate — step‑by‑step guidance
Follow these prioritized actions based on your role.
For individual users (fastest route)
- Open your browser (Edge or Chrome).
- Go to About (Edge: Settings and more → Help and feedback → About Microsoft Edge; Chrome: Help → About Google Chrome).
- Allow the browser to check and install updates; restart the browser when the update completes.
- Confirm the version is at or above the fixed build (Chrome >= 146.0.7680.71 or Edge version reported as “no longer vulnerable” in the Security Update Guide).
For organizations / IT administrators (recommended)
- Check Microsoft’s Security Update Guide entry for CVE‑2026‑3923 and confirm the status for Microsoft Edge (Chromium‑based).
- Use your software distribution tooling (SCCM/ConfigMgr, WSUS, Intune, or your patch management system) to deploy the patched Edge build to all endpoints. Prioritize endpoints exposed to the Internet or used for web browsing.
- For mixed‑browser environments, ensure Chrome and other Chromium‑based browsers are also updated to the upstream fixed build.
- If you rely on evergreen runtimes (WebView2, Chromium embedder, etc.), check vendor advisories and update any runtime that embeds Chromium code.
- Verify post‑deployment by sampling endpoints and opening edge://version or chrome://version to confirm the installed revision.
Interim mitigations (only while updating)
- The most reliable mitigation is to update. There is no guaranteed application‑level workaround that fully removes risk short of disabling the API or blocking access to the web entirely.
- You can reduce exposure by:
- Limiting web access to untrusted sites using enterprise web filtering or DNS blocking.
- Restricting site permissions for MIDI at the site level (site settings in Edge/Chrome) so pages can’t access MIDI devices without explicit consent.
- Using a Permissions‑Policy (formerly Feature‑Policy) header on your web properties to disallow midi usage for pages you control. This will not stop third‑party sites from attempting exploitation, but it reduces the attack surface for your own sites.
- Note: Disabling WebMIDI entirely across the browser via a simple Group Policy is not a widely documented or standard option; check vendor guidance for enterprise policies that may gate or restrict the midi permission. If you require a full removal, consider blocking the permission via an extension or using enterprise controls to prevent arbitrary web sites from being accessed.
Why this matters — risk and context
- Browsers are the most exposed client software on most desktops: users open untrusted web pages frequently. A memory corruption vulnerability reachable from a web page is therefore considered high‑risk.
- Even if a particular CVE is not trivially exploited in the wild, timely updating is the only surefire way to remove risk. Vendors fix flaws quickly; attackers weaponize them quickly too. The window between disclosure and widespread exploitation can be short.
- Because multiple vendors ship Chromium code, a vulnerability in the upstream project can affect many browsers simultaneously. That’s why coordinated disclosure and fast uptake of the fix by downstream vendors matters.
Practical examples: interpreting a Security Update Guide entry
When you open a Microsoft Security Update Guide entry for a Chromium CVE you’ll typically see:
- A short description of the issue and the upstream source (Chromium/Google).
- A list of affected products (for Chromium CVEs this will include Microsoft Edge (Chromium‑based) when applicable).
- A status field indicating whether a Microsoft Edge build has been released that includes the upstream fix (phrased as “No longer vulnerable” or with a specific Microsoft Edge build identifier).
- Guidance or references that direct admins to Edge release notes or update channels.
Use the SUG entry and the Edge release notes together to establish a clear update plan: SUG states whether Edge is still vulnerable; Edge release notes or About page give the installed version; your deployment tooling enforces rollout.
Frequently asked operational questions
Q: If the CVE is listed as a “Chromium” CVE, does that mean Microsoft created the vulnerability?
No. It means the bug was found in the Chromium codebase (upstream). Microsoft lists it because Edge consumes that code. The SUG entry documents whether Microsoft has produced an Edge build that contains the upstream fix.
Q: My Edge About page shows a different version than Chrome. Is that a problem?
No — Edge uses its own product versioning. The About page or edge://version will also show the underlying Chromium revision. Use those Chromium numbers or the SUG entry to determine whether the underlying fix is present.
Q: If I update Chrome but not Edge, am I safe?
Only for Chrome. Each product must be updated individually. If you use Edge in your environment, updating Chrome does not change Edge’s code. For organizations, update all deployed browser products.
Q: Can I block the WebMIDI API entirely to mitigate?
You can reduce exposure by using Permissions‑Policy headers on sites you control and by blocking site permissions. There is no universal “kill switch” via Group Policy documented for all customers; check your vendor’s enterprise policy documentation for the most robust options. For most organizations the correct path is to deploy the patched browser build.
Communication guidance for IT teams
- Treat Chromium CVEs as cross‑product risk: they commonly affect all Chromium consumers, not just Google Chrome.
- Use Microsoft’s Security Update Guide and vendor release notes as authoritative downstream guidance: SUG will explicitly say whether the Edge build you run contains the fix.
- When rolling out updates, prioritize:
- Internet‑facing machines,
- Administrative workstations,
- Systems that handle sensitive data,
- General user population.
- After deployment, sample endpoints and confirm via edge://version or chrome://version and via your inventory system that the update landed.
Final analysis and practical takeaways
CVE‑2026‑3923 is a real memory‑safety flaw in the WebMIDI component of Chromium; Google issued the upstream fix and the Chromium build associated with the fix starts at the Chrome revision identified as 146.0.7680.71. Microsoft included the CVE in the Security Update Guide because Microsoft Edge (Chromium‑based) consumes Chromium; the SUG entry exists to tell administrators whether Microsoft Edge builds have ingested the upstream patch and are
no longer vulnerable.
The actionable items are straightforward:
- Update your browser(s) immediately. For Chrome: ensure you are at or above 146.0.7680.71. For Edge: use the Security Update Guide and edge://version/About Microsoft Edge to confirm whether your installed Edge build contains the fix.
- For enterprises, deploy patched Edge builds via your standard update channels and verify post‑deployment with inventory tools and by sampling edge://version across endpoints.
- If you need temporary mitigation while rolling out updates, reduce exposure by restricting site permissions, applying Permissions‑Policy on sites you control, and using web filtering to limit user exposure to untrusted pages.
Finally, remember that Chromium is a shared foundation. When an upstream CVE appears, both vendor coordination and fast downstream uptake are essential to reduce the attack window. Treat SUG entries for Chromium CVEs as the downstream status signal: it’s Microsoft’s way of telling you whether Edge’s ingestion of the Chromium fix is complete and whether your Edge installations are safe.
Source: MSRC
Security Update Guide - Microsoft Security Response Center