CVE-2026-12011 is a critical use-after-free flaw in Chrome’s WebMIDI implementation on Windows, disclosed on June 11, 2026, and fixed for desktop users in Chrome 149.0.7827.115 after Google said crafted HTML could help a compromised renderer attempt a sandbox escape. The interesting part is not merely that Chrome had another memory-safety bug. It is that this one sits at the boundary where a web page, a browser sandbox, and a Windows-only attack path meet. For defenders, the lesson is blunt: browser patching is no longer just application hygiene; it is part of endpoint containment.
The phrase use after free has become so common in Chrome advisories that it risks sounding routine. It should not. A use-after-free vulnerability means software continues to reference memory after it has been released, creating a path for attackers to manipulate what the program thinks it is handling.
In many browser bugs, that primitive is useful for code execution inside the renderer process. CVE-2026-12011 is more specific and more worrying: Google’s description says the attacker first needed to compromise the renderer, then could potentially use the WebMIDI flaw to escape the sandbox on Windows. That makes the bug less like a one-click universal takeover and more like a second-stage escape hatch.
That distinction matters. Chrome’s security model assumes that hostile web content may eventually break into a renderer, so the sandbox is supposed to limit the blast radius. A vulnerability that helps cross that boundary is therefore an attack on the browser’s damage-control architecture.
The CVSS vector published through CISA-ADP reflects that shape. It rates the bug high rather than maximal, with network attack vector, high complexity, no privileges required, user interaction required, changed scope, and high impact to confidentiality, integrity, and availability. In plain English: the attack is not trivial, but if an attacker can line up the prerequisites, the consequences are serious.
Security teams tend to see something else: a specialized hardware-facing API exposed through a general-purpose browser. That does not make WebMIDI inherently reckless, but it does mean implementation details matter enormously. Any code path that translates web-facing requests into lower-level device or system interactions deserves special scrutiny.
The modern browser is full of these interfaces. WebUSB, WebBluetooth, WebHID, WebGPU, WebRTC, WebMIDI, and credential-related APIs all serve legitimate use cases. They also stretch the browser’s job description, creating places where memory safety, permission prompts, device state, and operating-system integration collide.
CVE-2026-12011 is a reminder that “obscure” is not the same thing as “low risk.” A rarely used API can still be an attractive exploit component if it provides the right shape of bug at the right privilege boundary. Attackers do not care whether most users own MIDI controllers; they care whether vulnerable code exists and can be reached.
That detail aligns with Google’s own vulnerability description, which identifies Google Chrome on Windows prior to 149.0.7827.115. The stable desktop update also shipped slightly different version endings across platforms, with Windows and macOS listed as 149.0.7827.114/.115 and Linux as 149.0.7827.114. For this CVE, the Windows-specific fixed threshold is the important part.
So, are we missing a CPE? Probably not for the CVE as currently described. The relevant product is Google Chrome, and the relevant operating-system condition is Windows. If later analysis shows the vulnerable WebMIDI code path affects Chromium broadly, Chromium-based downstream browsers, or non-Windows platforms, then additional CPEs or advisories would be appropriate.
That is the catch with CPE data: it encodes what is known and asserted, not every plausible downstream risk. Microsoft Edge, Brave, Vivaldi, Opera, Electron apps, and other Chromium-derived software often share upstream code, but they do not automatically belong in a Google Chrome CVE entry unless the affected vendor, CNA, NVD, or another authority maps them there. Administrators should therefore treat the CPE as a starting point, not the end of the investigation.
A renderer compromise can come from a separate bug in JavaScript, WebAssembly, graphics parsing, font handling, media decoding, or another content-exposed component. Once the attacker has code execution inside that sandboxed renderer, the next prize is a way out. CVE-2026-12011 appears to sit in that second-stage category.
That is why sandbox escapes receive so much attention from exploit developers and defenders alike. The sandbox is the difference between “the browser tab is in trouble” and “the endpoint may be in trouble.” A reliable escape turns a contained compromise into something that can reach more sensitive system resources.
High attack complexity should be read in that context. It means exploitation likely requires careful setup, memory manipulation, and a working chain. It does not mean defenders can ignore it, especially in enterprise environments where browser processes handle SSO sessions, intranet portals, cloud consoles, privileged admin panels, and sensitive documents all day long.
That cadence is now familiar, but it creates real operational pressure. Consumer Chrome updates often happen quietly. Enterprise Chrome updates move through rings, compatibility testing, policy controls, browser management tools, and sometimes change-control boards that were designed for operating-system patches rather than weekly browser churn.
The result is a widening gap between vendor release and actual protection. A Chrome update may be available on Thursday, but many managed endpoints will not be uniformly remediated until days later. In the meantime, exploit developers can read the advisory, compare patches, watch bug restrictions, and begin the familiar race from disclosure to weaponization.
For WindowsForum readers, this is where the story becomes practical. The browser is not “just another app” on Windows fleets anymore. It is the default workbench for identity, SaaS, remote administration, documentation, ticketing, monitoring, finance, and development. A browser sandbox escape is therefore a workstation security event.
That is normal. NVD enrichment often trails publication, especially for fast-moving vendor advisories. The absence of a NIST score should not be mistaken for uncertainty about whether the bug matters. Google’s Chromium security severity is critical, and the published description points directly at sandbox escape potential.
The CPE configuration is also easy to misread. The AND structure means both conditions must be present: the vulnerable Chrome version and the Windows operating system. That is exactly what asset scanners should want if the flaw is truly Windows-specific. A Linux workstation running the same Chrome major line should not be flagged for this CVE solely because the application CPE matches, unless new evidence expands the affected set.
Still, scanners vary in how well they interpret complex CPE logic. Some tools flatten CPEs into overly broad matches. Others miss application-plus-OS combinations when inventory data is incomplete. The practical answer is to verify actual Chrome versions on Windows endpoints rather than relying only on vulnerability dashboards.
Microsoft Edge is the obvious Windows example, though it ships under Microsoft’s own update and advisory pipeline. Electron-based applications are the messier category. Collaboration tools, code editors, desktop clients, internal apps, launchers, admin consoles, and niche enterprise software may carry Chromium components without being managed like browsers.
CVE-2026-12011 should not be blindly applied to every Chromium-based product, especially when the current description is Chrome on Windows. But the existence of a sandbox-escape-class bug in a Chromium component should prompt the broader question: which applications in the fleet depend on Chromium, and how quickly do their vendors absorb upstream fixes?
This is where vulnerability management often becomes uncomfortable. Asset owners can usually answer “which machines have Chrome?” They are less likely to answer “which applications embed Chromium, which Chromium version do they ship, and is the affected WebMIDI code reachable?” That gap is where theoretical exposure turns into operational ambiguity.
Memory-corruption bugs operate below the level where permission dialogs provide much comfort. A prompt may restrict normal API use, but it does not necessarily prevent a crafted page from reaching vulnerable parsing, object-lifecycle, or state-management code. Security boundaries depend on implementation correctness as much as user consent.
This is one of the browser platform’s central tensions. The web keeps absorbing capabilities once reserved for native applications, while users and administrators still expect browser-grade containment. Every new API expands what web apps can do, but also expands the amount of privileged or semi-privileged code exposed to untrusted input.
The solution is not to freeze the web in 2008. It is to acknowledge that powerful APIs need aggressive hardening, memory-safe rewrites where feasible, fuzzing, isolation, permission discipline, and enterprise controls. CVE-2026-12011 is a small case study in why that work never ends.
Chrome’s update model helps by downloading updates in the background, but many fixes do not fully take effect until the browser restarts. In user environments where Chrome stays open for days or weeks, the “update available” state can linger. Attackers do not need every endpoint to be vulnerable; they need one useful endpoint to remain behind.
Administrators should also examine extension policy and site isolation posture. Extensions can change the browser’s risk profile, and enterprise web apps sometimes lead organizations to weaken defaults for compatibility. A sandbox escape bug is precisely the kind of vulnerability that punishes accumulated exceptions.
The best-run environments treat browser security updates more like emergency endpoint patches than optional app refreshes. They use staged rollout, but they compress the stage gates when a critical or exploit-adjacent browser issue appears. They measure restart compliance. They know which business units resist forced browser relaunches, and they plan around that friction before the next advisory lands.
Chromium’s severity classification is informed by the project’s security model. A potential sandbox escape is critical because it compromises one of Chrome’s most important internal boundaries. CVSS, meanwhile, encodes factors such as attack complexity and user interaction, which can pull the numerical score below the highest band.
Defenders should resist the urge to average those signals into complacency. In practice, a high-complexity sandbox escape may be less likely to affect random users at scale, but more valuable in targeted exploitation. The same characteristics that reduce opportunistic mass exploitation may make the bug attractive to sophisticated operators chaining multiple vulnerabilities.
That is why Chrome’s own severity should carry weight. Google knows where the sandbox boundaries are, how reachable the component is, and how the bug fits into the architecture. When the vendor calls a browser sandbox issue critical, administrators should not wait for a perfect 9.8 score before acting.
For managed environments, remediation is a verification exercise. Confirm the installed version, confirm the running version, confirm update policy state, and confirm that users have restarted into the patched build. Browser version drift is common in environments with long-lived sessions, virtual desktops, nonpersistent images, or tightly controlled update rings.
Security teams should also remember that Chrome’s stable channel update included more than this one CVE. Focusing only on CVE-2026-12011 risks missing the broader patch value. A single update can close multiple independent paths an attacker might combine.
The operational goal is not to panic over WebMIDI. It is to prevent the browser from becoming the soft underbelly of an otherwise well-managed Windows estate. In 2026, the endpoint browser is too privileged, too central, and too frequently targeted to sit outside urgent patch workflows.
The broader answer is less satisfying. NVD CPE data is not a complete map of the Chromium ecosystem. It will not automatically tell you whether a downstream browser, embedded runtime, or Electron application inherited related code. It will not prove whether WebMIDI is reachable in a given application. It will not replace vendor advisories from other Chromium consumers.
That means defenders should separate compliance from risk hunting. For compliance, match the published CPE and patch Chrome on Windows. For risk hunting, identify Chromium-derived software, monitor vendor updates, and watch for follow-on advisories that reference the same upstream issue or component.
This is the right balance. Overbroad vulnerability matching creates alert fatigue and false positives. Overnarrow thinking creates blind spots. CVE-2026-12011 sits exactly where both failure modes are possible.
This Is a Sandbox Story, Not Just a Browser Bug
The phrase use after free has become so common in Chrome advisories that it risks sounding routine. It should not. A use-after-free vulnerability means software continues to reference memory after it has been released, creating a path for attackers to manipulate what the program thinks it is handling.In many browser bugs, that primitive is useful for code execution inside the renderer process. CVE-2026-12011 is more specific and more worrying: Google’s description says the attacker first needed to compromise the renderer, then could potentially use the WebMIDI flaw to escape the sandbox on Windows. That makes the bug less like a one-click universal takeover and more like a second-stage escape hatch.
That distinction matters. Chrome’s security model assumes that hostile web content may eventually break into a renderer, so the sandbox is supposed to limit the blast radius. A vulnerability that helps cross that boundary is therefore an attack on the browser’s damage-control architecture.
The CVSS vector published through CISA-ADP reflects that shape. It rates the bug high rather than maximal, with network attack vector, high complexity, no privileges required, user interaction required, changed scope, and high impact to confidentiality, integrity, and availability. In plain English: the attack is not trivial, but if an attacker can line up the prerequisites, the consequences are serious.
WebMIDI Is a Small Surface With Outsized Consequences
WebMIDI is one of those browser features most users never knowingly touch. It exists to let web applications communicate with MIDI devices — keyboards, controllers, synthesizers, and other music or production hardware. For musicians and web audio developers, it is part of the browser becoming a real application platform rather than a document viewer.Security teams tend to see something else: a specialized hardware-facing API exposed through a general-purpose browser. That does not make WebMIDI inherently reckless, but it does mean implementation details matter enormously. Any code path that translates web-facing requests into lower-level device or system interactions deserves special scrutiny.
The modern browser is full of these interfaces. WebUSB, WebBluetooth, WebHID, WebGPU, WebRTC, WebMIDI, and credential-related APIs all serve legitimate use cases. They also stretch the browser’s job description, creating places where memory safety, permission prompts, device state, and operating-system integration collide.
CVE-2026-12011 is a reminder that “obscure” is not the same thing as “low risk.” A rarely used API can still be an attractive exploit component if it provides the right shape of bug at the right privilege boundary. Attackers do not care whether most users own MIDI controllers; they care whether vulnerable code exists and can be reached.
The Windows-Only Label Is the Detail Administrators Should Not Skip
The NVD configuration added for CVE-2026-12011 pairs the Google Chrome application CPE with Microsoft Windows in an AND relationship. That is not a missing-product error on its face. It is the machine-readable way of saying the vulnerable condition is Chrome running on Windows, not every Chrome build on every operating system.That detail aligns with Google’s own vulnerability description, which identifies Google Chrome on Windows prior to 149.0.7827.115. The stable desktop update also shipped slightly different version endings across platforms, with Windows and macOS listed as 149.0.7827.114/.115 and Linux as 149.0.7827.114. For this CVE, the Windows-specific fixed threshold is the important part.
So, are we missing a CPE? Probably not for the CVE as currently described. The relevant product is Google Chrome, and the relevant operating-system condition is Windows. If later analysis shows the vulnerable WebMIDI code path affects Chromium broadly, Chromium-based downstream browsers, or non-Windows platforms, then additional CPEs or advisories would be appropriate.
That is the catch with CPE data: it encodes what is known and asserted, not every plausible downstream risk. Microsoft Edge, Brave, Vivaldi, Opera, Electron apps, and other Chromium-derived software often share upstream code, but they do not automatically belong in a Google Chrome CVE entry unless the affected vendor, CNA, NVD, or another authority maps them there. Administrators should therefore treat the CPE as a starting point, not the end of the investigation.
The Renderer Prerequisite Does Not Make This Comfortable
Some readers will see “attacker who had compromised the renderer process” and mentally downgrade the vulnerability. That is understandable, but dangerous. In browser exploitation, chains are the norm, not the exception.A renderer compromise can come from a separate bug in JavaScript, WebAssembly, graphics parsing, font handling, media decoding, or another content-exposed component. Once the attacker has code execution inside that sandboxed renderer, the next prize is a way out. CVE-2026-12011 appears to sit in that second-stage category.
That is why sandbox escapes receive so much attention from exploit developers and defenders alike. The sandbox is the difference between “the browser tab is in trouble” and “the endpoint may be in trouble.” A reliable escape turns a contained compromise into something that can reach more sensitive system resources.
High attack complexity should be read in that context. It means exploitation likely requires careful setup, memory manipulation, and a working chain. It does not mean defenders can ignore it, especially in enterprise environments where browser processes handle SSO sessions, intranet portals, cloud consoles, privileged admin panels, and sensitive documents all day long.
Chrome 149 Has Become a Patch-Management Stress Test
CVE-2026-12011 did not arrive in isolation. Chrome 149 has already been a busy release line, with multiple security updates landing in quick succession. Earlier in June, Google addressed a separate V8 issue that was reportedly exploited in the wild, and then followed with another stable channel update containing dozens of additional fixes.That cadence is now familiar, but it creates real operational pressure. Consumer Chrome updates often happen quietly. Enterprise Chrome updates move through rings, compatibility testing, policy controls, browser management tools, and sometimes change-control boards that were designed for operating-system patches rather than weekly browser churn.
The result is a widening gap between vendor release and actual protection. A Chrome update may be available on Thursday, but many managed endpoints will not be uniformly remediated until days later. In the meantime, exploit developers can read the advisory, compare patches, watch bug restrictions, and begin the familiar race from disclosure to weaponization.
For WindowsForum readers, this is where the story becomes practical. The browser is not “just another app” on Windows fleets anymore. It is the default workbench for identity, SaaS, remote administration, documentation, ticketing, monitoring, finance, and development. A browser sandbox escape is therefore a workstation security event.
The NVD Entry Is Useful, but It Is Not the Whole Risk Model
NVD’s entry for CVE-2026-12011 is still thin in the way many new CVE records are thin. It has the description, the CWE, the CISA-ADP CVSS vector, the Chrome advisory reference, and the initial affected configuration. It does not yet provide a full NVD CVSS assessment.That is normal. NVD enrichment often trails publication, especially for fast-moving vendor advisories. The absence of a NIST score should not be mistaken for uncertainty about whether the bug matters. Google’s Chromium security severity is critical, and the published description points directly at sandbox escape potential.
The CPE configuration is also easy to misread. The AND structure means both conditions must be present: the vulnerable Chrome version and the Windows operating system. That is exactly what asset scanners should want if the flaw is truly Windows-specific. A Linux workstation running the same Chrome major line should not be flagged for this CVE solely because the application CPE matches, unless new evidence expands the affected set.
Still, scanners vary in how well they interpret complex CPE logic. Some tools flatten CPEs into overly broad matches. Others miss application-plus-OS combinations when inventory data is incomplete. The practical answer is to verify actual Chrome versions on Windows endpoints rather than relying only on vulnerability dashboards.
The Real Inventory Problem Is Not Chrome, It Is Chromium
Google Chrome is usually the easiest part of this problem. It has recognizable version numbers, enterprise policies, auto-update infrastructure, and broad vulnerability-scanner coverage. The harder question is what else in the environment embeds Chromium code or exposes browser-like attack surface.Microsoft Edge is the obvious Windows example, though it ships under Microsoft’s own update and advisory pipeline. Electron-based applications are the messier category. Collaboration tools, code editors, desktop clients, internal apps, launchers, admin consoles, and niche enterprise software may carry Chromium components without being managed like browsers.
CVE-2026-12011 should not be blindly applied to every Chromium-based product, especially when the current description is Chrome on Windows. But the existence of a sandbox-escape-class bug in a Chromium component should prompt the broader question: which applications in the fleet depend on Chromium, and how quickly do their vendors absorb upstream fixes?
This is where vulnerability management often becomes uncomfortable. Asset owners can usually answer “which machines have Chrome?” They are less likely to answer “which applications embed Chromium, which Chromium version do they ship, and is the affected WebMIDI code reachable?” That gap is where theoretical exposure turns into operational ambiguity.
Web Permissions Are Not a Substitute for Memory Safety
It is tempting to think permission prompts solve WebMIDI risk. After all, hardware APIs generally involve some kind of user mediation or browser permission model. But CVE-2026-12011 is not primarily a story about an unwanted MIDI keyboard connection.Memory-corruption bugs operate below the level where permission dialogs provide much comfort. A prompt may restrict normal API use, but it does not necessarily prevent a crafted page from reaching vulnerable parsing, object-lifecycle, or state-management code. Security boundaries depend on implementation correctness as much as user consent.
This is one of the browser platform’s central tensions. The web keeps absorbing capabilities once reserved for native applications, while users and administrators still expect browser-grade containment. Every new API expands what web apps can do, but also expands the amount of privileged or semi-privileged code exposed to untrusted input.
The solution is not to freeze the web in 2008. It is to acknowledge that powerful APIs need aggressive hardening, memory-safe rewrites where feasible, fuzzing, isolation, permission discipline, and enterprise controls. CVE-2026-12011 is a small case study in why that work never ends.
Enterprise Chrome Controls Need to Move Faster Than Advisory Culture
The default advice — update Chrome — is correct but incomplete. Enterprises need to know whether Chrome has updated, whether users have restarted, whether stale browser processes remain alive, and whether policy deferrals are holding back high-risk fixes. A version number in a software inventory tool is only useful if it reflects the running browser.Chrome’s update model helps by downloading updates in the background, but many fixes do not fully take effect until the browser restarts. In user environments where Chrome stays open for days or weeks, the “update available” state can linger. Attackers do not need every endpoint to be vulnerable; they need one useful endpoint to remain behind.
Administrators should also examine extension policy and site isolation posture. Extensions can change the browser’s risk profile, and enterprise web apps sometimes lead organizations to weaken defaults for compatibility. A sandbox escape bug is precisely the kind of vulnerability that punishes accumulated exceptions.
The best-run environments treat browser security updates more like emergency endpoint patches than optional app refreshes. They use staged rollout, but they compress the stage gates when a critical or exploit-adjacent browser issue appears. They measure restart compliance. They know which business units resist forced browser relaunches, and they plan around that friction before the next advisory lands.
Security Severity and CVSS Are Telling Different Stories
One subtle point in CVE-2026-12011 is the gap between Chromium’s “Critical” label and the CISA-ADP CVSS 8.3 “High” score. That is not necessarily a contradiction. Vendor severity and CVSS measure overlapping but different things.Chromium’s severity classification is informed by the project’s security model. A potential sandbox escape is critical because it compromises one of Chrome’s most important internal boundaries. CVSS, meanwhile, encodes factors such as attack complexity and user interaction, which can pull the numerical score below the highest band.
Defenders should resist the urge to average those signals into complacency. In practice, a high-complexity sandbox escape may be less likely to affect random users at scale, but more valuable in targeted exploitation. The same characteristics that reduce opportunistic mass exploitation may make the bug attractive to sophisticated operators chaining multiple vulnerabilities.
That is why Chrome’s own severity should carry weight. Google knows where the sandbox boundaries are, how reachable the component is, and how the bug fits into the architecture. When the vendor calls a browser sandbox issue critical, administrators should not wait for a perfect 9.8 score before acting.
The Patch Is Straightforward; The Assurance Is Not
For unmanaged users, the remediation path is simple: update Chrome and restart the browser. On Windows, anything prior to 149.0.7827.115 should be treated as exposed to CVE-2026-12011 based on the published description. The usual Chrome help page version check is enough for individual machines.For managed environments, remediation is a verification exercise. Confirm the installed version, confirm the running version, confirm update policy state, and confirm that users have restarted into the patched build. Browser version drift is common in environments with long-lived sessions, virtual desktops, nonpersistent images, or tightly controlled update rings.
Security teams should also remember that Chrome’s stable channel update included more than this one CVE. Focusing only on CVE-2026-12011 risks missing the broader patch value. A single update can close multiple independent paths an attacker might combine.
The operational goal is not to panic over WebMIDI. It is to prevent the browser from becoming the soft underbelly of an otherwise well-managed Windows estate. In 2026, the endpoint browser is too privileged, too central, and too frequently targeted to sit outside urgent patch workflows.
The CPE Looks Right, but the Inventory Question Remains Open
The narrow answer to the CPE question is that the current NVD configuration appears sensible: vulnerable Google Chrome versions up to but excluding 149.0.7827.115, combined with Microsoft Windows. That reflects the CVE wording and avoids overflagging platforms not named in the description.The broader answer is less satisfying. NVD CPE data is not a complete map of the Chromium ecosystem. It will not automatically tell you whether a downstream browser, embedded runtime, or Electron application inherited related code. It will not prove whether WebMIDI is reachable in a given application. It will not replace vendor advisories from other Chromium consumers.
That means defenders should separate compliance from risk hunting. For compliance, match the published CPE and patch Chrome on Windows. For risk hunting, identify Chromium-derived software, monitor vendor updates, and watch for follow-on advisories that reference the same upstream issue or component.
This is the right balance. Overbroad vulnerability matching creates alert fatigue and false positives. Overnarrow thinking creates blind spots. CVE-2026-12011 sits exactly where both failure modes are possible.
The WebMIDI Bug Leaves a Short Checklist for Windows Shops
The practical response to CVE-2026-12011 is not complicated, but it does require discipline. Treat this as a browser containment issue first and an obscure API issue second. The systems most worth checking are Windows endpoints where Chrome is heavily used for privileged business workflows.- Windows machines running Google Chrome earlier than 149.0.7827.115 should be updated and restarted as soon as possible.
- Vulnerability scanners should interpret the affected configuration as Chrome plus Windows, rather than applying the CVE indiscriminately to every operating system.
- Security teams should verify the running Chrome process version, not only the installed package version reported by inventory.
- Managed environments should review update deferrals, forced-restart policies, and exception groups that may leave browsers open on vulnerable builds.
- Chromium-based applications should be tracked separately, because the Google Chrome CPE does not automatically describe every downstream Chromium consumer.
- The absence of an NVD-assigned CVSS score should not delay remediation, because Google’s advisory already classifies the issue as critical in Chromium terms.
References
- Primary source: NVD / Chromium
Published: 2026-06-15T07:00:30-07:00
NVD - CVE-2026-12011
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-06-15T07:00:30-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2026-12011 - Google Chrome Use-After-Free
Use after free in WebMIDI in Google Chrome on Windows prior to 149.0.7827.115 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)cvefeed.io - Related coverage: vuldb.com
CVE-2026-12011 Google Chrome WebMIDI use after free (ID 518108 / Nessus ID 320973)
A vulnerability was identified in Google Chrome on Windows. This vulnerability is listed as CVE-2026-12011. The affected component should be upgraded.vuldb.com
