Google Chrome versions on macOS before 149.0.7827.103 are affected by CVE-2026-11687, a high-severity use-after-free vulnerability in Dawn that could let a remote attacker trigger heap corruption through a crafted HTML page. The CPE entry is not so much “missing” as it is unusually easy to misread: NVD models the vulnerable configuration as Google Chrome combined with Apple macOS. That matters because this is not a generic Chrome-on-every-platform bug in the public description. It is a Mac-specific Chrome flaw sitting in the browser’s increasingly security-sensitive graphics stack.
The natural instinct when reading an NVD entry for Chrome is to expect a clean application CPE: Google Chrome, all versions before the fixed build, done. CVE-2026-11687 does not quite fit that mental model. The public description says the vulnerability affects “Google Chrome on Mac” prior to 149.0.7827.103, and NVD reflects that by pairing the Chrome application CPE with an Apple macOS operating-system CPE.
That is why the configuration appears as an AND relationship rather than a simple one-line affected product. In plain English, NVD is saying: vulnerable Chrome, when running on macOS. It is not saying that macOS itself contains the Dawn memory-safety defect, nor that every macOS version is independently vulnerable.
The awkward part is the macOS CPE value. It uses a broad Apple macOS placeholder rather than enumerating specific macOS releases. That is common when the vulnerable condition is “this application on that platform” and the advisory does not narrow the exposure to Sonoma, Sequoia, Tahoe, or any other named macOS generation. From an asset-management standpoint, though, it can look incomplete because administrators want a bounded operating-system list, not a platform bucket.
So if the question is whether NVD is missing the Chrome CPE, the answer is no. The Chrome CPE is present. If the question is whether the macOS side of the configuration could be more precise, the answer is also yes — but only if Google or another authoritative source provides more granular platform data.
That does not make WebGPU inherently unsafe. It does mean that browser security now depends on a much larger set of complex subsystems behaving correctly under hostile input. A crafted HTML page is no longer a passive document; it can be a delivery mechanism for highly structured workloads designed to stress memory management, GPU command translation, and validation layers.
A use-after-free bug is exactly the kind of flaw security engineers dislike in this territory. The phrase means software continues to use a region of memory after it has already been released. If an attacker can influence what occupies that memory next, the bug can sometimes be turned from a crash into controlled corruption.
The public wording for CVE-2026-11687 is cautious: a remote attacker could “potentially exploit heap corruption” through a crafted HTML page. That is not the same thing as a confirmed remote-code-execution chain in the wild. But the CVSS 3.1 score assigned through CISA’s enrichment, 8.8 High, captures the reason defenders should not shrug: network attack vector, low attack complexity, no privileges required, user interaction required, and high impact across confidentiality, integrity, and availability.
That distinction should shape how IT teams triage it. A Windows fleet running Chrome 149.0.7827.102 may still have plenty of other Chrome security work to do from the same release train, but this particular CVE is not publicly described as a Windows exposure. A macOS fleet below 149.0.7827.103 is the population that matters for this record.
The temptation is to treat Chrome as a single cross-platform object in vulnerability management. That makes dashboards simpler, but it also creates false positives and false negatives. For CVE-2026-11687, the operating system context is not metadata decoration; it is part of the vulnerable condition.
This is also where CPE modeling gets messy. CPE was designed to identify products, versions, and platforms, but modern software is increasingly a stack of shared engines, platform-specific build paths, hardware-facing APIs, and feature flags. A vulnerability can live in a component that ships everywhere but only be reachable, exploitable, or confirmed on one operating system. NVD’s AND configuration is an attempt to capture that nuance with a vocabulary that often feels too rigid for it.
But “requires user interaction” is not a comfort blanket in browser security. The browser is the application users are trained to feed with untrusted content all day. Email links, chat messages, search results, malvertising, compromised websites, and poisoned documentation pages all collapse the distance between attacker and renderer.
The important boundary is between possible exploitation and observed exploitation. CVE-2026-11687 is not the same as the contemporaneous Chrome V8 issue CVE-2026-11645, which Google said had an exploit in the wild. Several advisories and headlines around the June Chrome update understandably focused on that zero-day, but it is a different bug.
That distinction matters because vulnerability programs should not inflate every same-day Chrome CVE into the zero-day narrative. CVE-2026-11687 deserves fast remediation because it is a high-severity memory-safety flaw in a browser component exposed to web content on macOS. It does not need to be misrepresented as known exploited to justify patching.
Chrome updates often download in the background, then wait for a browser restart. On personally managed machines, that delay may last hours or days. On enterprise Macs with persistent sessions, conferencing apps, web apps, and identity workflows all living in Chrome tabs, users may postpone restarts because the browser has become the workday.
For administrators, CVE-2026-11687 is a reminder that browser patch status should be measured by running version, not merely by update policy. A management console that says automatic updates are enabled is useful. It is not proof that every browser process on every Mac has crossed the fixed-build line.
The version threshold is concrete: Chrome for Mac must be at 149.0.7827.103 or later for this CVE. Anything below that on macOS should be treated as exposed. If an inventory tool collapses Chrome’s Windows, Linux, and Mac versions into one normalized record, this is the sort of issue that can disappear into bad abstraction.
NVD’s current configuration is a reasonable expression of the public facts: Chrome before 149.0.7827.103, combined with macOS. The broad macOS CPE is not elegant, but it is defensible unless a source identifies particular macOS versions as affected or unaffected. Vulnerability databases should not invent specificity just to satisfy a dashboard.
Still, security teams should understand the consequences. A scanner that ingests the CPE literally may flag every macOS host with vulnerable Chrome, regardless of macOS release. That is probably acceptable for remediation because the browser version is the control point. A scanner that expects an exact macOS version CPE, however, may fail to match because the OS side is too generic.
The best local rule is therefore simpler than the CPE: find macOS devices running Google Chrome below 149.0.7827.103. That is the operational truth. CPE should support that query, not replace it.
In Microsoft 365-heavy organizations, Chrome on macOS is still a front door into Entra ID sessions, SharePoint, Exchange Online, Teams web sessions, admin portals, and internal web apps. Browser compromise is not confined to the device brand. A stolen session token or corrupted browser process can become an identity problem, a data-access problem, or a lateral-movement problem.
That is especially true for developers and privileged users. Macs are common in engineering, design, security research, and executive populations. Those same groups often have broad repository access, production dashboards, cloud consoles, and long-lived browser sessions.
The practical takeaway for Windows admins is not to panic about macOS. It is to stop treating non-Windows browser patching as a side quest. The browser is now one of the most important enterprise runtimes, and Chrome’s cross-platform footprint means its Mac-specific bugs still land inside the same risk register.
For CVE-2026-11687, the restricted Chromium issue link is part of that pattern. The lack of public exploit mechanics should not be interpreted as lack of severity. It simply means defenders must operate from the metadata: component, platform, version boundary, vulnerability class, and impact score.
That metadata is enough to act. Dawn is a browser component tied to GPU-facing web capabilities. The flaw is memory-safety related. The attack can arrive over the network through crafted web content. The user must interact, but the browser’s normal job is to interact with untrusted web content.
What the advisory does not tell us is whether the flaw is reachable only under specific hardware, driver, feature, or macOS conditions. It also does not say whether exploitability is theoretical, demonstrated by researchers, or partially constrained by Chrome’s sandbox and platform mitigations. Those uncertainties are normal in early CVE records, and they are why version-based remediation remains the cleanest answer.
Security teams should avoid two common mistakes. The first is assuming the presence of Chrome 149 is enough. The affected line is “prior to 149.0.7827.103,” which means earlier 149 builds on Mac are still below the fix. The second is assuming that a later Chrome update aimed at other CVEs automatically explains the risk posture for this one. It may remediate it by supersedence, but the audit trail should still show that the fixed threshold was crossed.
For organizations with mixed fleets, remediation language should be platform-aware. Windows and Linux builds from the same Stable Channel update have their own version numbers and their own CVE exposure profile. A Mac-specific vulnerability should not be used to create unnecessary emergency tickets for systems that do not match the affected platform.
At the same time, do not let platform specificity slow down Chrome patching as a whole. The June 2026 Chrome update train contained numerous security fixes, including a separate V8 issue reported as exploited in the wild. If you operate Chrome anywhere, the broader release deserves prompt attention; CVE-2026-11687 simply adds a Mac-specific reason to move quickly.
Where defenders may still feel friction is in the macOS side of the match. Because the OS CPE is broad, scanner behavior will depend on how well the tool handles AND configurations and platform constraints. That is a tooling issue as much as a data issue.
For vulnerability managers, the correct validation query is concrete: show every macOS endpoint with Chrome below 149.0.7827.103. If the scanner cannot answer that directly, use endpoint inventory, MDM data, or browser reporting to close the gap. The CPE record is useful evidence, but the fleet query is the thing that reduces risk.
The CPE Looks Sparse Because the Bug Is Platform-Bound
The natural instinct when reading an NVD entry for Chrome is to expect a clean application CPE: Google Chrome, all versions before the fixed build, done. CVE-2026-11687 does not quite fit that mental model. The public description says the vulnerability affects “Google Chrome on Mac” prior to 149.0.7827.103, and NVD reflects that by pairing the Chrome application CPE with an Apple macOS operating-system CPE.That is why the configuration appears as an AND relationship rather than a simple one-line affected product. In plain English, NVD is saying: vulnerable Chrome, when running on macOS. It is not saying that macOS itself contains the Dawn memory-safety defect, nor that every macOS version is independently vulnerable.
The awkward part is the macOS CPE value. It uses a broad Apple macOS placeholder rather than enumerating specific macOS releases. That is common when the vulnerable condition is “this application on that platform” and the advisory does not narrow the exposure to Sonoma, Sequoia, Tahoe, or any other named macOS generation. From an asset-management standpoint, though, it can look incomplete because administrators want a bounded operating-system list, not a platform bucket.
So if the question is whether NVD is missing the Chrome CPE, the answer is no. The Chrome CPE is present. If the question is whether the macOS side of the configuration could be more precise, the answer is also yes — but only if Google or another authoritative source provides more granular platform data.
Dawn Is Not a Household Name, but It Sits on a Hot Path
Dawn is Chromium’s implementation layer for WebGPU, the browser technology that gives web applications modern access to GPU capabilities. That makes it part of a broader shift in browser risk: the web is no longer just documents, JavaScript, and media playback. It is also graphics pipelines, shader compilation, compute-style workloads, and hardware-adjacent abstractions that were once the domain of native applications.That does not make WebGPU inherently unsafe. It does mean that browser security now depends on a much larger set of complex subsystems behaving correctly under hostile input. A crafted HTML page is no longer a passive document; it can be a delivery mechanism for highly structured workloads designed to stress memory management, GPU command translation, and validation layers.
A use-after-free bug is exactly the kind of flaw security engineers dislike in this territory. The phrase means software continues to use a region of memory after it has already been released. If an attacker can influence what occupies that memory next, the bug can sometimes be turned from a crash into controlled corruption.
The public wording for CVE-2026-11687 is cautious: a remote attacker could “potentially exploit heap corruption” through a crafted HTML page. That is not the same thing as a confirmed remote-code-execution chain in the wild. But the CVSS 3.1 score assigned through CISA’s enrichment, 8.8 High, captures the reason defenders should not shrug: network attack vector, low attack complexity, no privileges required, user interaction required, and high impact across confidentiality, integrity, and availability.
The Mac-Only Detail Is the Signal, Not a Footnote
Chrome’s Stable Channel update around this bug used slightly different fixed build numbers across platforms: 149.0.7827.102 for Windows and Linux, and 149.0.7827.103 for Mac. That pattern is not unusual in Chrome releases, but for this CVE the platform language is unusually explicit. CVE-2026-11687 is described as Chrome on Mac prior to 149.0.7827.103.That distinction should shape how IT teams triage it. A Windows fleet running Chrome 149.0.7827.102 may still have plenty of other Chrome security work to do from the same release train, but this particular CVE is not publicly described as a Windows exposure. A macOS fleet below 149.0.7827.103 is the population that matters for this record.
The temptation is to treat Chrome as a single cross-platform object in vulnerability management. That makes dashboards simpler, but it also creates false positives and false negatives. For CVE-2026-11687, the operating system context is not metadata decoration; it is part of the vulnerable condition.
This is also where CPE modeling gets messy. CPE was designed to identify products, versions, and platforms, but modern software is increasingly a stack of shared engines, platform-specific build paths, hardware-facing APIs, and feature flags. A vulnerability can live in a component that ships everywhere but only be reachable, exploitable, or confirmed on one operating system. NVD’s AND configuration is an attempt to capture that nuance with a vocabulary that often feels too rigid for it.
Heap Corruption Still Starts With a Click
The CVSS vector includes user interaction required. In practical terms, that usually means the attacker needs the target to open or render a malicious page, click a link, visit a compromised site, or otherwise load crafted content. That is not the same as a wormable bug, and CISA’s SSVC-style enrichment reportedly marked the issue as not automatable with no known exploitation at the time of enrichment.But “requires user interaction” is not a comfort blanket in browser security. The browser is the application users are trained to feed with untrusted content all day. Email links, chat messages, search results, malvertising, compromised websites, and poisoned documentation pages all collapse the distance between attacker and renderer.
The important boundary is between possible exploitation and observed exploitation. CVE-2026-11687 is not the same as the contemporaneous Chrome V8 issue CVE-2026-11645, which Google said had an exploit in the wild. Several advisories and headlines around the June Chrome update understandably focused on that zero-day, but it is a different bug.
That distinction matters because vulnerability programs should not inflate every same-day Chrome CVE into the zero-day narrative. CVE-2026-11687 deserves fast remediation because it is a high-severity memory-safety flaw in a browser component exposed to web content on macOS. It does not need to be misrepresented as known exploited to justify patching.
The Real Risk Is the Browser Release Train, Not One CVE Row
Chrome’s rapid update model is both the defense and the operational headache. Google can push fixes quickly across an enormous install base, but enterprise environments still have to convert “available” into “installed, restarted, and verified.” That last step is where many browser vulnerabilities linger.Chrome updates often download in the background, then wait for a browser restart. On personally managed machines, that delay may last hours or days. On enterprise Macs with persistent sessions, conferencing apps, web apps, and identity workflows all living in Chrome tabs, users may postpone restarts because the browser has become the workday.
For administrators, CVE-2026-11687 is a reminder that browser patch status should be measured by running version, not merely by update policy. A management console that says automatic updates are enabled is useful. It is not proof that every browser process on every Mac has crossed the fixed-build line.
The version threshold is concrete: Chrome for Mac must be at 149.0.7827.103 or later for this CVE. Anything below that on macOS should be treated as exposed. If an inventory tool collapses Chrome’s Windows, Linux, and Mac versions into one normalized record, this is the sort of issue that can disappear into bad abstraction.
CPE Precision Is Now a Security Operations Problem
The user-facing question — “Are we missing a CPE here?” — sounds like taxonomy work. In practice, it is a detection question. If a scanner cannot represent “Chrome before this version on macOS,” it may either overreport the bug on Windows and Linux or underreport it on Macs.NVD’s current configuration is a reasonable expression of the public facts: Chrome before 149.0.7827.103, combined with macOS. The broad macOS CPE is not elegant, but it is defensible unless a source identifies particular macOS versions as affected or unaffected. Vulnerability databases should not invent specificity just to satisfy a dashboard.
Still, security teams should understand the consequences. A scanner that ingests the CPE literally may flag every macOS host with vulnerable Chrome, regardless of macOS release. That is probably acceptable for remediation because the browser version is the control point. A scanner that expects an exact macOS version CPE, however, may fail to match because the OS side is too generic.
The best local rule is therefore simpler than the CPE: find macOS devices running Google Chrome below 149.0.7827.103. That is the operational truth. CPE should support that query, not replace it.
Microsoft Shops Cannot Treat This as Someone Else’s Browser Problem
WindowsForum readers may reasonably ask why a Mac-specific Chrome CVE belongs in a Windows-centered publication. The answer is that few modern Windows environments are Windows-only. Identity, SaaS, browser policy, endpoint detection, and patch compliance now span Windows PCs, Macs, Linux workstations, mobile devices, and virtual desktops.In Microsoft 365-heavy organizations, Chrome on macOS is still a front door into Entra ID sessions, SharePoint, Exchange Online, Teams web sessions, admin portals, and internal web apps. Browser compromise is not confined to the device brand. A stolen session token or corrupted browser process can become an identity problem, a data-access problem, or a lateral-movement problem.
That is especially true for developers and privileged users. Macs are common in engineering, design, security research, and executive populations. Those same groups often have broad repository access, production dashboards, cloud consoles, and long-lived browser sessions.
The practical takeaway for Windows admins is not to panic about macOS. It is to stop treating non-Windows browser patching as a side quest. The browser is now one of the most important enterprise runtimes, and Chrome’s cross-platform footprint means its Mac-specific bugs still land inside the same risk register.
The Vendor Advisory Tells You Enough, but Not Everything
Google’s public Chrome advisories are intentionally restrained. They identify fixed versions, list CVEs, name vulnerability classes, and often withhold bug details until most users are updated. That restraint is sensible. Publishing exploit-friendly technical detail before patch uptake would help attackers more than defenders.For CVE-2026-11687, the restricted Chromium issue link is part of that pattern. The lack of public exploit mechanics should not be interpreted as lack of severity. It simply means defenders must operate from the metadata: component, platform, version boundary, vulnerability class, and impact score.
That metadata is enough to act. Dawn is a browser component tied to GPU-facing web capabilities. The flaw is memory-safety related. The attack can arrive over the network through crafted web content. The user must interact, but the browser’s normal job is to interact with untrusted web content.
What the advisory does not tell us is whether the flaw is reachable only under specific hardware, driver, feature, or macOS conditions. It also does not say whether exploitability is theoretical, demonstrated by researchers, or partially constrained by Chrome’s sandbox and platform mitigations. Those uncertainties are normal in early CVE records, and they are why version-based remediation remains the cleanest answer.
Patch Management Should Follow the Fixed Build, Not the Headline
The safest remediation instruction is boring: update Chrome on Mac to 149.0.7827.103 or later and verify that the browser has restarted into the new version. Chrome’s update page will generally fetch the update automatically, but managed environments should rely on their endpoint tooling, browser management console, or software update platform to confirm deployment.Security teams should avoid two common mistakes. The first is assuming the presence of Chrome 149 is enough. The affected line is “prior to 149.0.7827.103,” which means earlier 149 builds on Mac are still below the fix. The second is assuming that a later Chrome update aimed at other CVEs automatically explains the risk posture for this one. It may remediate it by supersedence, but the audit trail should still show that the fixed threshold was crossed.
For organizations with mixed fleets, remediation language should be platform-aware. Windows and Linux builds from the same Stable Channel update have their own version numbers and their own CVE exposure profile. A Mac-specific vulnerability should not be used to create unnecessary emergency tickets for systems that do not match the affected platform.
At the same time, do not let platform specificity slow down Chrome patching as a whole. The June 2026 Chrome update train contained numerous security fixes, including a separate V8 issue reported as exploited in the wild. If you operate Chrome anywhere, the broader release deserves prompt attention; CVE-2026-11687 simply adds a Mac-specific reason to move quickly.
The Useful Answer Is Shorter Than the Database Record
The cleanest read of CVE-2026-11687 is that the CPE is functionally present but imperfectly expressive. NVD’s configuration captures the key relationship: Google Chrome before the fixed Mac build, running on Apple macOS. The database is not missing the central Chrome product entry.Where defenders may still feel friction is in the macOS side of the match. Because the OS CPE is broad, scanner behavior will depend on how well the tool handles AND configurations and platform constraints. That is a tooling issue as much as a data issue.
For vulnerability managers, the correct validation query is concrete: show every macOS endpoint with Chrome below 149.0.7827.103. If the scanner cannot answer that directly, use endpoint inventory, MDM data, or browser reporting to close the gap. The CPE record is useful evidence, but the fleet query is the thing that reduces risk.
The Mac Chrome Build Is the Line Administrators Should Draw
CVE-2026-11687 is a narrow CVE with broad lessons: a Mac-specific Chrome memory-safety bug, in a graphics-adjacent browser component, represented through a CPE model that requires administrators to understand both application versioning and platform constraints. The practical path is not complicated, but it does require precision.- Chrome on macOS should be updated to 149.0.7827.103 or later to address CVE-2026-11687.
- The NVD configuration is not missing the Google Chrome CPE; it models the vulnerable condition as Chrome combined with Apple macOS.
- The broad macOS CPE may be less precise than administrators would like, but the public advisory does not currently justify inventing specific macOS version bounds.
- CVE-2026-11687 should not be confused with CVE-2026-11645, the separate Chrome V8 issue reported as exploited in the wild.
- Fleet validation should be based on observed Chrome versions on macOS endpoints, not merely on update-policy intent.
References
- Primary source: NVD / Chromium
Published: 2026-06-15T19:14:50-07:00
NVD - CVE-2026-11687
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-06-15T19:14:50-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: vulnerability.circl.lu
Vulnerability-Lookup
Vulnerability-Lookup - Fast vulnerability lookup correlation from different sources.vulnerability.circl.lu - Related coverage: radar.offseq.com
CVE-2026-11687: Use after free in Google Chrome - Live Threat Intelligence - Threat Radar | OffSeq.com
Detailed information about CVE-2026-11687: Use after free in Google Chrome affecting Google Chrome. Get real-time updates, technical details, and mitigation strradar.offseq.com
