CVE-2026-12008 is a critical Google Chrome vulnerability disclosed on June 11, 2026, fixed in Chrome 149.0.7827.114/.115 for desktop, and described as a DigitalCredentials use-after-free bug that could let an attacker escape the browser sandbox after compromising the renderer. That phrasing is easy to skim past, but it is the important part: this is not merely another “open a bad web page” browser crash. It is the sort of bug that matters because Chrome’s security model assumes the renderer will eventually be hostile, and the sandbox is supposed to be the wall that keeps that hostility contained. When that wall becomes the target, administrators should treat the update as operationally urgent, even if public exploit details remain sparse.
The vulnerability sits in DigitalCredentials, a browser capability tied to the larger effort to make identity, credentials, and verification flows work more natively on the web. That makes it a modern Chrome bug in the most literal sense: not an old plug-in relic, not a forgotten compatibility corner, but a flaw in the machinery being added as browsers absorb more of the identity layer.
The reported weakness is CWE-416, use after free, one of the classic memory-safety failure modes. In simple terms, software frees a chunk of memory and later keeps using it as though it were still valid. Attackers prize this class of bug because, under the right circumstances, stale memory references can be massaged into type confusion, object corruption, control-flow manipulation, or access to data and capabilities the attacker should not have.
The key phrase in the CVE description is that the attacker must have already compromised the renderer process. That narrows the initial entry path but increases the significance of the bug. Chrome’s renderer is intentionally exposed to hostile content because it parses HTML, CSS, JavaScript, images, fonts, video, and an ever-expanding set of web APIs; the browser’s answer to that exposure is process isolation and sandboxing.
CVE-2026-12008 is therefore best read as a second-stage vulnerability. It is not necessarily the first domino in an attack chain. It is the kind of bug that can turn “code running inside the browser’s cage” into “code with a path out of the cage,” which is the difference between a contained browser exploit and a much more serious endpoint compromise.
The CVSS vector says the attack is network-accessible, requires no privileges, and does require user interaction. It also assigns high impact to confidentiality, integrity, and availability, with scope changed. The attack complexity is marked high, which makes sense for a sandbox escape dependent on a prior renderer compromise.
For defenders, the practical reading is blunt: this is not a wormable LAN bug, but it is serious in browser-exploit terms. The user interaction requirement may be no more exotic than visiting a malicious or compromised page. The prior renderer compromise requirement means the vulnerability is likely most useful when chained with another bug, a malicious extension path, a renderer exploit, or some other method of gaining execution inside Chrome’s content process.
That is why a simple “8.3 High” can undersell the operational urgency. Browser sandbox escapes are leverage. They are not always loud on their own, but they are exactly what sophisticated exploit chains need when the goal is to move from web content into the local machine.
That matters because CVE-2026-12008 did not arrive as a lonely emergency patch with a flashing red banner. It arrived amid a dense release full of memory-corruption bugs, validation problems, GPU issues, media bugs, and browser-component hardening. In Chrome land, a serious bug can hide in plain sight because the cadence of security fixes is relentless.
The DigitalCredentials issue was reported by Google on May 27, 2026, and the public CVE followed on June 11. The Chromium issue tracker entry is permission-restricted, which is normal for newly patched browser vulnerabilities. Google routinely keeps details private until enough users have updated, both to avoid handing attackers a blueprint and to give downstream Chromium-based browsers time to catch up.
That disclosure posture creates an awkward gap for IT teams. The public has enough information to know the class of bug, affected component, fixed version, and broad exploitation conditions. It does not have the exploit primitive, proof-of-concept details, or complete root-cause analysis. In practice, that means defenders should patch first and ask finer-grained questions later.
This is the kind of discrepancy that drives asset managers mad. It is also common when vendor release numbering, platform-specific builds, and NVD enrichment processes collide. Chrome often ships slightly different build numbers across platforms, and Windows/Mac advisories may show paired version numbers when staged builds or platform differences exist.
The safest operational line is not to overfit on the last digit. On Windows and macOS, administrators should verify that machines are on the current 149.0.7827.114/.115 stable build as offered by Google’s updater, with special attention to any clients still below that release family. On Linux, package versions should be checked through the distribution or Google repository channel providing Chrome.
The NVD page is also marked as undergoing reanalysis. That means metadata such as CVSS, CPE applicability, and affected configurations may continue to move. For vulnerability management teams, the correct response is to treat NVD as an important feed but not the only source of truth; the vendor advisory should drive the immediate patch decision.
That distinction matters for Windows administrators because vulnerability scanners can turn CPE logic into noisy dashboards. A Windows CPE associated with a Chrome CVE is not a Windows patching problem in the Patch Tuesday sense. It is an application lifecycle problem, and it belongs in the browser-management lane.
For WindowsForum readers, this is a familiar trap. Microsoft’s servicing stack can be perfectly healthy while third-party userland software remains exposed. Chrome may auto-update for consumer users, but enterprise environments often introduce policy, packaging, VDI snapshots, offline images, kiosk lockdowns, update deferrals, and change-control windows that slow browser patch adoption.
The result is that a Chrome critical bug often becomes a Windows endpoint risk through neglect rather than through Windows itself. Attackers do not care whether the vulnerable code shipped through Windows Update, Google Update, a software center package, or a manually installed enterprise MSI. They care whether the exposed browser process is reachable by a crafted page.
A memory-safety flaw in such a component does not necessarily mean credentials are directly stolen. The CVE does not say that DigitalCredentials data was exposed, nor does it describe credential exfiltration. The impact described is sandbox escape after renderer compromise, which is a different and broader category of danger.
Still, the component should make security teams pause. Identity surfaces are high-value because they mediate trust. Even when a given vulnerability is “just” memory corruption, bugs in these pathways increase anxiety because they sit close to authentication flows, user consent prompts, device APIs, and cross-origin boundaries.
The browser industry has spent years moving sensitive flows away from passwords and toward stronger mechanisms. That is good security. But each new credential API also adds implementation complexity, and complexity is where memory-safety bugs, lifetime bugs, and state-machine bugs like to live.
Attackers also build chains. A renderer exploit that cannot escape the sandbox may be useful for stealing web-session data within the browser context, but it is far less useful for durable endpoint compromise. Pair it with a sandbox escape, however, and the calculus changes.
That is why the most expensive browser exploit chains often include multiple vulnerabilities. One bug gets code execution in the renderer. Another breaks out of the sandbox. A third may elevate privileges, bypass a platform mitigation, or gain persistence. CVE-2026-12008 fits cleanly into the middle of that pattern.
There is no public indication in the supplied data that this specific CVE is being exploited in the wild. That distinction matters, especially because a separate Chrome issue from the same general period, CVE-2026-11645, has been discussed as actively exploited. But absence of public exploitation is not a reason to wait on a sandbox escape fix; it is a reason to patch before exploit details circulate.
For Windows administrators, Edge is the obvious adjacent concern. Microsoft ships Edge on Chromium, integrates it deeply into Windows, and services it through Microsoft’s own update channels rather than Chrome’s. A Chrome CVE does not automatically mean Edge is vulnerable in exactly the same way, but it does mean Edge release notes and version baselines should be checked when a critical Chromium bug lands.
This is one of the quiet consequences of the Chromium monoculture. The shared engine gives users better compatibility and vendors a massive security engineering base. It also means that memory-corruption bugs in shared components can ripple across products before every downstream vendor has published clear guidance.
Enterprise IT should resist the urge to treat “Chrome patched” as the end of the task. The better question is: which Chromium-derived browsers are in the environment, which versions are actually running, and which update mechanisms control them? On Windows fleets, the answer often includes more browsers than the official standard build image admits.
Enterprise environments are different. Browser updates can break legacy web applications, extensions, kiosk workflows, certificate-inspection products, authentication agents, and brittle intranet portals. That reality is why organizations pin versions, test rings, and staged rollouts exist.
The problem is that a critical sandbox escape compresses the acceptable testing window. A week may be reasonable for a routine feature regression. It is harder to justify when the bug class is memory corruption in a web-exposed component and the fix is already in stable.
The right compromise is not blind panic. It is tiered acceleration. Push the patched build to security-sensitive users, privileged administrators, finance teams, developers, and exposed kiosk or shared-device environments first, while a fast compatibility pass runs for the rest of the fleet. The organizations that struggle most are the ones that have no reliable browser inventory and therefore cannot tell whether they are moving quickly or merely hoping they are.
The burden shifts to defenders, who must act on incomplete information. That is uncomfortable but unavoidable. Browser security has become a race between patch deployment and exploit reconstruction, and public advisories are intentionally written to give defenders enough to prioritize without giving attackers everything they need.
This is also why CVE feeds can feel underwhelming at first publication. NVD may show missing NIST scoring, CPEs still loading, and reanalysis in progress. The Chromium bug may be locked. The vendor advisory may provide a one-line description. None of that means the issue is theoretical.
In fact, the combination of a critical Chromium severity, a sandbox-escape description, a restricted issue, and a stable-channel security update is more than enough to justify urgency. The absence of detail is not a signal of low risk. It is part of the coordinated defense strategy.
This is not an indictment of Chrome’s security team. It is a structural fact about a codebase that parses nearly everything the internet can throw at it while maintaining performance, compatibility, GPU acceleration, media pipelines, extension hooks, accessibility layers, and platform integration. The browser is the modern operating system’s most hostile application.
The industry’s gradual move toward memory-safe languages is relevant here, but it will not produce overnight relief. Browsers are vast, performance-sensitive, and full of legacy assumptions. The transition will be measured in subsystems and years, not product cycles.
Until then, defense remains layered: reduce bug density, detect more failures before release, isolate risky processes, harden the sandbox, and patch fast when the inevitable escape bugs appear. CVE-2026-12008 is a reminder that all of those layers matter because none of them is sufficient by itself.
A compromised browser can become the bridge between a malicious web page and the rest of the enterprise. Even before an attacker escapes the sandbox, session tokens, OAuth flows, SSO prompts, and browser-stored data create valuable opportunities. After a sandbox escape, the endpoint itself becomes a more realistic target.
On Windows fleets, the practical response is to bring browser management into the same discipline as OS patching. That means policy-controlled updates, inventory visibility, extension governance, crash and exploit telemetry where available, and rapid exception handling for machines that fail to update.
It also means accounting for the awkward cases: RDS hosts, VDI gold images, nonpersistent desktops, lab machines, air-gapped workstations that occasionally reconnect, packaged portable browsers, developer-installed alternates, and unmanaged local admin installs. Those are the corners where a patched stable channel and a vulnerable real-world fleet can coexist.
The Bug Is Small on Paper and Large in the Threat Model
The vulnerability sits in DigitalCredentials, a browser capability tied to the larger effort to make identity, credentials, and verification flows work more natively on the web. That makes it a modern Chrome bug in the most literal sense: not an old plug-in relic, not a forgotten compatibility corner, but a flaw in the machinery being added as browsers absorb more of the identity layer.The reported weakness is CWE-416, use after free, one of the classic memory-safety failure modes. In simple terms, software frees a chunk of memory and later keeps using it as though it were still valid. Attackers prize this class of bug because, under the right circumstances, stale memory references can be massaged into type confusion, object corruption, control-flow manipulation, or access to data and capabilities the attacker should not have.
The key phrase in the CVE description is that the attacker must have already compromised the renderer process. That narrows the initial entry path but increases the significance of the bug. Chrome’s renderer is intentionally exposed to hostile content because it parses HTML, CSS, JavaScript, images, fonts, video, and an ever-expanding set of web APIs; the browser’s answer to that exposure is process isolation and sandboxing.
CVE-2026-12008 is therefore best read as a second-stage vulnerability. It is not necessarily the first domino in an attack chain. It is the kind of bug that can turn “code running inside the browser’s cage” into “code with a path out of the cage,” which is the difference between a contained browser exploit and a much more serious endpoint compromise.
Chrome’s Sandbox Is the Story, Not the CVSS Score
The CISA-ADP CVSS 3.1 score attached to the entry is 8.3, which lands in the “High” range, while Chromium labels the issue “Critical.” That mismatch is not a contradiction so much as a reminder that scoring systems and engineering severity often measure different things. CVSS is a structured attempt to describe exploitability and impact; Chromium’s severity reflects how dangerous the bug is inside Chrome’s own security architecture.The CVSS vector says the attack is network-accessible, requires no privileges, and does require user interaction. It also assigns high impact to confidentiality, integrity, and availability, with scope changed. The attack complexity is marked high, which makes sense for a sandbox escape dependent on a prior renderer compromise.
For defenders, the practical reading is blunt: this is not a wormable LAN bug, but it is serious in browser-exploit terms. The user interaction requirement may be no more exotic than visiting a malicious or compromised page. The prior renderer compromise requirement means the vulnerability is likely most useful when chained with another bug, a malicious extension path, a renderer exploit, or some other method of gaining execution inside Chrome’s content process.
That is why a simple “8.3 High” can undersell the operational urgency. Browser sandbox escapes are leverage. They are not always loud on their own, but they are exactly what sophisticated exploit chains need when the goal is to move from web content into the local machine.
The Fix Landed Inside a Crowded Chrome Security Drop
Google’s June 11 Chrome stable update moved desktop users to 149.0.7827.114/.115 on Windows and Mac and 149.0.7827.114 on Linux. The same advisory listed 28 security fixes, including several critical issues: Core, DigitalCredentials, Accessibility, GPU, and WebMIDI all appeared in the critical cluster.That matters because CVE-2026-12008 did not arrive as a lonely emergency patch with a flashing red banner. It arrived amid a dense release full of memory-corruption bugs, validation problems, GPU issues, media bugs, and browser-component hardening. In Chrome land, a serious bug can hide in plain sight because the cadence of security fixes is relentless.
The DigitalCredentials issue was reported by Google on May 27, 2026, and the public CVE followed on June 11. The Chromium issue tracker entry is permission-restricted, which is normal for newly patched browser vulnerabilities. Google routinely keeps details private until enough users have updated, both to avoid handing attackers a blueprint and to give downstream Chromium-based browsers time to catch up.
That disclosure posture creates an awkward gap for IT teams. The public has enough information to know the class of bug, affected component, fixed version, and broad exploitation conditions. It does not have the exploit primitive, proof-of-concept details, or complete root-cause analysis. In practice, that means defenders should patch first and ask finer-grained questions later.
The Version Boundary Is Messier Than It Looks
The NVD description says Google Chrome prior to 149.0.7827.115 is affected. Google’s stable-channel advisory says the fixed desktop release is 149.0.7827.114/.115 for Windows and Mac and 149.0.7827.114 for Linux. NVD’s change history, meanwhile, shows an initial CPE configuration that excludes versions up to 149.0.7827.114, while the prose description uses 149.0.7827.115.This is the kind of discrepancy that drives asset managers mad. It is also common when vendor release numbering, platform-specific builds, and NVD enrichment processes collide. Chrome often ships slightly different build numbers across platforms, and Windows/Mac advisories may show paired version numbers when staged builds or platform differences exist.
The safest operational line is not to overfit on the last digit. On Windows and macOS, administrators should verify that machines are on the current 149.0.7827.114/.115 stable build as offered by Google’s updater, with special attention to any clients still below that release family. On Linux, package versions should be checked through the distribution or Google repository channel providing Chrome.
The NVD page is also marked as undergoing reanalysis. That means metadata such as CVSS, CPE applicability, and affected configurations may continue to move. For vulnerability management teams, the correct response is to treat NVD as an important feed but not the only source of truth; the vendor advisory should drive the immediate patch decision.
The CPE Entry Tells a Windows Story by Accident
The NVD CPE configuration is interesting because it shows Chrome paired with operating-system CPEs for Microsoft Windows, Linux kernel, and Apple macOS. At first glance, that can look as if Windows itself is vulnerable. It is not. The vulnerable application is Chrome; the operating-system entries express the platforms on which the affected Chrome application runs.That distinction matters for Windows administrators because vulnerability scanners can turn CPE logic into noisy dashboards. A Windows CPE associated with a Chrome CVE is not a Windows patching problem in the Patch Tuesday sense. It is an application lifecycle problem, and it belongs in the browser-management lane.
For WindowsForum readers, this is a familiar trap. Microsoft’s servicing stack can be perfectly healthy while third-party userland software remains exposed. Chrome may auto-update for consumer users, but enterprise environments often introduce policy, packaging, VDI snapshots, offline images, kiosk lockdowns, update deferrals, and change-control windows that slow browser patch adoption.
The result is that a Chrome critical bug often becomes a Windows endpoint risk through neglect rather than through Windows itself. Attackers do not care whether the vulnerable code shipped through Windows Update, Google Update, a software center package, or a manually installed enterprise MSI. They care whether the exposed browser process is reachable by a crafted page.
Digital Credentials Expand the Browser’s Blast Radius
DigitalCredentials is notable because identity features are no longer peripheral to the browser. The web browser has become the place where passkeys, federated identity, device-bound credentials, wallet-like attestations, and enterprise sign-in flows increasingly converge. That gives browser vendors a difficult job: expose powerful identity primitives to websites while preventing malicious sites from abusing them.A memory-safety flaw in such a component does not necessarily mean credentials are directly stolen. The CVE does not say that DigitalCredentials data was exposed, nor does it describe credential exfiltration. The impact described is sandbox escape after renderer compromise, which is a different and broader category of danger.
Still, the component should make security teams pause. Identity surfaces are high-value because they mediate trust. Even when a given vulnerability is “just” memory corruption, bugs in these pathways increase anxiety because they sit close to authentication flows, user consent prompts, device APIs, and cross-origin boundaries.
The browser industry has spent years moving sensitive flows away from passwords and toward stronger mechanisms. That is good security. But each new credential API also adds implementation complexity, and complexity is where memory-safety bugs, lifetime bugs, and state-machine bugs like to live.
Renderer Compromise Is Not a Comforting Prerequisite
Some readers will be tempted to down-rank the issue because the attacker must first compromise the renderer. That is a mistake. Chrome’s renderer is not a trusted castle; it is a hostile frontier. The browser’s architecture assumes that parsing the web will always be dangerous, and the sandbox exists because renderer compromise is considered plausible.Attackers also build chains. A renderer exploit that cannot escape the sandbox may be useful for stealing web-session data within the browser context, but it is far less useful for durable endpoint compromise. Pair it with a sandbox escape, however, and the calculus changes.
That is why the most expensive browser exploit chains often include multiple vulnerabilities. One bug gets code execution in the renderer. Another breaks out of the sandbox. A third may elevate privileges, bypass a platform mitigation, or gain persistence. CVE-2026-12008 fits cleanly into the middle of that pattern.
There is no public indication in the supplied data that this specific CVE is being exploited in the wild. That distinction matters, especially because a separate Chrome issue from the same general period, CVE-2026-11645, has been discussed as actively exploited. But absence of public exploitation is not a reason to wait on a sandbox escape fix; it is a reason to patch before exploit details circulate.
Edge and Chromium Browsers Sit in the Same Weather System
The CVE is assigned to Google Chrome, but the underlying code lives in Chromium. That means the broader risk question naturally extends to Chromium-based browsers, including Microsoft Edge, Brave, Vivaldi, Opera, and others, depending on whether they include the affected component and when they pick up the upstream patch.For Windows administrators, Edge is the obvious adjacent concern. Microsoft ships Edge on Chromium, integrates it deeply into Windows, and services it through Microsoft’s own update channels rather than Chrome’s. A Chrome CVE does not automatically mean Edge is vulnerable in exactly the same way, but it does mean Edge release notes and version baselines should be checked when a critical Chromium bug lands.
This is one of the quiet consequences of the Chromium monoculture. The shared engine gives users better compatibility and vendors a massive security engineering base. It also means that memory-corruption bugs in shared components can ripple across products before every downstream vendor has published clear guidance.
Enterprise IT should resist the urge to treat “Chrome patched” as the end of the task. The better question is: which Chromium-derived browsers are in the environment, which versions are actually running, and which update mechanisms control them? On Windows fleets, the answer often includes more browsers than the official standard build image admits.
Auto-Update Helps Consumers and Exposes Enterprise Drag
For home users, the fix path is refreshingly simple: let Chrome update, relaunch the browser, and confirm the version. Chrome’s update mechanism is one of the better consumer security systems in mainstream software precisely because it removes most user decision-making from the patch process.Enterprise environments are different. Browser updates can break legacy web applications, extensions, kiosk workflows, certificate-inspection products, authentication agents, and brittle intranet portals. That reality is why organizations pin versions, test rings, and staged rollouts exist.
The problem is that a critical sandbox escape compresses the acceptable testing window. A week may be reasonable for a routine feature regression. It is harder to justify when the bug class is memory corruption in a web-exposed component and the fix is already in stable.
The right compromise is not blind panic. It is tiered acceleration. Push the patched build to security-sensitive users, privileged administrators, finance teams, developers, and exposed kiosk or shared-device environments first, while a fast compatibility pass runs for the rest of the fleet. The organizations that struggle most are the ones that have no reliable browser inventory and therefore cannot tell whether they are moving quickly or merely hoping they are.
The Disclosure Gap Is a Feature, and Also a Burden
Google’s advisory notes that bug details may remain restricted until most users are updated. Security professionals sometimes resent this opacity, but the logic is sound. Publishing exploit mechanics for a fresh sandbox escape before the patch has saturated the install base would be irresponsible.The burden shifts to defenders, who must act on incomplete information. That is uncomfortable but unavoidable. Browser security has become a race between patch deployment and exploit reconstruction, and public advisories are intentionally written to give defenders enough to prioritize without giving attackers everything they need.
This is also why CVE feeds can feel underwhelming at first publication. NVD may show missing NIST scoring, CPEs still loading, and reanalysis in progress. The Chromium bug may be locked. The vendor advisory may provide a one-line description. None of that means the issue is theoretical.
In fact, the combination of a critical Chromium severity, a sandbox-escape description, a restricted issue, and a stable-channel security update is more than enough to justify urgency. The absence of detail is not a signal of low risk. It is part of the coordinated defense strategy.
Memory Safety Keeps Winning the Argument
CVE-2026-12008 is another entry in the long ledger of memory-safety failures that continue to shape browser security. Chrome has invested heavily in fuzzing, sanitizers, process isolation, site isolation, control-flow integrity, MiraclePtr-style mitigations, and sandbox hardening. Yet use-after-free bugs keep appearing because C++ lifetime management remains brutally difficult at browser scale.This is not an indictment of Chrome’s security team. It is a structural fact about a codebase that parses nearly everything the internet can throw at it while maintaining performance, compatibility, GPU acceleration, media pipelines, extension hooks, accessibility layers, and platform integration. The browser is the modern operating system’s most hostile application.
The industry’s gradual move toward memory-safe languages is relevant here, but it will not produce overnight relief. Browsers are vast, performance-sensitive, and full of legacy assumptions. The transition will be measured in subsystems and years, not product cycles.
Until then, defense remains layered: reduce bug density, detect more failures before release, isolate risky processes, harden the sandbox, and patch fast when the inevitable escape bugs appear. CVE-2026-12008 is a reminder that all of those layers matter because none of them is sufficient by itself.
Windows Admins Should Treat Browsers Like Tier-One Infrastructure
Many organizations still treat browsers as user productivity tools rather than tier-one infrastructure. That model is obsolete. The browser now handles identity, SaaS access, privileged admin consoles, internal dashboards, code repositories, cloud control planes, and device enrollment workflows.A compromised browser can become the bridge between a malicious web page and the rest of the enterprise. Even before an attacker escapes the sandbox, session tokens, OAuth flows, SSO prompts, and browser-stored data create valuable opportunities. After a sandbox escape, the endpoint itself becomes a more realistic target.
On Windows fleets, the practical response is to bring browser management into the same discipline as OS patching. That means policy-controlled updates, inventory visibility, extension governance, crash and exploit telemetry where available, and rapid exception handling for machines that fail to update.
It also means accounting for the awkward cases: RDS hosts, VDI gold images, nonpersistent desktops, lab machines, air-gapped workstations that occasionally reconnect, packaged portable browsers, developer-installed alternates, and unmanaged local admin installs. Those are the corners where a patched stable channel and a vulnerable real-world fleet can coexist.
The June Chrome Patch Is a Test of Browser Hygiene
The immediate action is straightforward, but the larger lesson is more uncomfortable. If an organization cannot quickly answer which Chrome versions it runs, which Chromium-based alternatives are present, and which machines have failed to update, then CVE-2026-12008 is not just a vulnerability. It is an audit finding waiting to happen.- Chrome desktop systems should be moved to the June 11, 2026 stable-channel build line, with Windows and Mac clients receiving 149.0.7827.114/.115 and Linux clients receiving 149.0.7827.114 through the appropriate channel.
- Machines running Chrome versions earlier than the fixed build should be treated as exposed to a critical sandbox-escape vulnerability, even though public exploit details remain restricted.
- Security teams should verify Microsoft Edge and other Chromium-based browsers separately rather than assuming Google’s Chrome patch covers the entire browser estate.
- Scanner findings that associate the CVE with Windows, Linux, or macOS should be interpreted as platform applicability for Chrome, not as an operating-system vulnerability.
- The most important operational metric is not whether auto-update is enabled in theory, but whether endpoints have actually relaunched into the fixed version.
References
- Primary source: NVD / Chromium
Published: 2026-06-15T07:00:26-07:00
NVD - CVE-2026-12008
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-06-15T07:00:26-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2026-12008 - Google Chrome Use-After-Free Sandbox Escape
Use after free in DigitalCredentials in Google Chrome 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
