Google Chrome 150.0.7871.128 for Windows includes a fix for CVE-2026-15902, a high-severity use-after-free vulnerability in Chromium’s Cast component. Windows users and administrators should ensure Chrome has updated immediately; the issue is one of seven security fixes shipped in Google’s July 16 Stable Channel update.
Google’s Chrome Releases bulletin identifies CVE-2026-15902 as “Use after free in Cast,” reported internally by Google on June 10. The accompanying update also addresses three critical use-after-free bugs in CameraCapture, GPU, and Network, plus high-severity issues in V8, Ozone, and Aura. CERT-FR has independently listed the same seven CVEs and identifies Chrome versions before 150.0.7871.128 on Windows and Linux as affected.
The immediate operational point is straightforward: Chrome installations below 150.0.7871.128 on Windows should be treated as out of date, regardless of whether Cast is actively used by the employee or system in question.
The NVD page for CVE-2026-15902 currently displays the familiar “CVE ID Not Found” message. That message is easy to misread as evidence that the identifier is invalid, speculative, or unrelated to a released patch. It is none of those things in this case.
NVD’s own notice explains that CVE entries can lag after assignment, particularly while a record remains reserved or has not yet completed NVD’s enrichment and publication workflow. Google’s July 16 Chrome bulletin, the CVE identifier, and downstream advisories from CERT-FR and security vendors all align on the vulnerability’s existence and its inclusion in Chrome 150.0.7871.128.
For patch management teams, this is an important distinction. NVD is a major vulnerability-data source, but it is not the authoritative release gate for a vendor patch. Google’s security release notice is the controlling evidence for whether Chrome has shipped a fix; NVD metadata, CVSS scoring, CPE mappings, and enriched descriptions may follow later.
That delay can also affect automated processes. Vulnerability scanners and CMDB-based reporting that rely exclusively on NVD enrichment may initially show an incomplete picture, even where endpoint software inventory clearly shows an older, vulnerable Chrome build.
A use-after-free flaw occurs when software continues to access memory after that memory has been released. Depending on the precise code path and mitigations in place, that kind of defect can lead to a crash, memory corruption, information exposure, or code execution. Google has not yet released technical details for CVE-2026-15902, nor has it said that the bug is being exploited in the wild.
That absence of exploitation reporting matters. Administrators should not label this a confirmed zero-day or assume that a typical malicious webpage alone can trigger it. At the same time, the weakness belongs in a security-sensitive portion of the browser that may interact with devices on the local network, which makes prompt updating sensible in offices, schools, shared Wi-Fi environments, and meeting-room deployments.
Google commonly restricts bug details and associated issue-tracker access until the update has reached a broad share of users. The practice limits the amount of immediately actionable information available to attackers attempting to reverse-engineer a newly released fix. It also means that the public currently lacks a confirmed attack path, a known affected Cast device list, and a vendor-supplied CVSS score for this individual CVE.
Users can verify the installed build by opening Chrome’s menu, selecting Help, then About Google Chrome. Chrome will normally begin checking for an available update from that page. A restart completes the update when Chrome reports that a relaunch is required.
Enterprise teams should not depend solely on a user-driven check. Chrome’s version can be collected through endpoint-management platforms, browser-management reporting, software inventory, or vulnerability scanning. The key reporting query is uncomplicated: find Windows systems with Google Chrome versions earlier than 150.0.7871.128, then remediate and confirm the post-update version.
A short response plan is appropriate:
Windows administrators should therefore avoid a common shortcut: updating Chrome is not proof that Edge is protected, and updating Edge is not proof that Chrome is current. Each installed browser or Chromium-derived application needs to be assessed against its own vendor release information.
Microsoft Edge is especially relevant in Windows environments because it is widely deployed and tightly integrated with operating-system workflows. But the right operational response is to monitor Microsoft’s security release notes and update Edge through its normal channel, rather than assuming that Chrome 150’s version number maps directly to an Edge build. The same caution applies to WebView2 Runtime, whose Chromium base and patch cadence are managed separately.
For organizations that disable Cast through policy, the control can reduce feature exposure, but it should not be treated as a substitute for patching. Policy state is often inconsistent across BYOD systems, unmanaged laptops, developer machines, and conference-room devices. More importantly, Google’s public advisory does not state that disabling Cast fully removes the vulnerable code path.
The next milestone is NVD enrichment: a finalized vulnerability description, severity assessment, affected-product metadata, and potentially references to Google’s restricted issue tracker may appear later. None of that changes the present decision. Chrome 150.0.7871.128 is the required Windows baseline, and the lack of an NVD record should be documented as a feed-lag issue—not accepted as an excuse to defer the update.
Google’s Chrome Releases bulletin identifies CVE-2026-15902 as “Use after free in Cast,” reported internally by Google on June 10. The accompanying update also addresses three critical use-after-free bugs in CameraCapture, GPU, and Network, plus high-severity issues in V8, Ozone, and Aura. CERT-FR has independently listed the same seven CVEs and identifies Chrome versions before 150.0.7871.128 on Windows and Linux as affected.
The immediate operational point is straightforward: Chrome installations below 150.0.7871.128 on Windows should be treated as out of date, regardless of whether Cast is actively used by the employee or system in question.
The Missing NVD Entry Is a Data-Timing Problem, Not a Reason to Wait
The NVD page for CVE-2026-15902 currently displays the familiar “CVE ID Not Found” message. That message is easy to misread as evidence that the identifier is invalid, speculative, or unrelated to a released patch. It is none of those things in this case.NVD’s own notice explains that CVE entries can lag after assignment, particularly while a record remains reserved or has not yet completed NVD’s enrichment and publication workflow. Google’s July 16 Chrome bulletin, the CVE identifier, and downstream advisories from CERT-FR and security vendors all align on the vulnerability’s existence and its inclusion in Chrome 150.0.7871.128.
For patch management teams, this is an important distinction. NVD is a major vulnerability-data source, but it is not the authoritative release gate for a vendor patch. Google’s security release notice is the controlling evidence for whether Chrome has shipped a fix; NVD metadata, CVSS scoring, CPE mappings, and enriched descriptions may follow later.
That delay can also affect automated processes. Vulnerability scanners and CMDB-based reporting that rely exclusively on NVD enrichment may initially show an incomplete picture, even where endpoint software inventory clearly shows an older, vulnerable Chrome build.
Cast Is More Than the Button in the Browser Toolbar
Chrome’s Cast stack supports discovery and communication with compatible receivers, including Chromecast devices, Google TV hardware, conference-room displays, smart displays, and some enterprise presentation systems. It is easy to view it as a consumer feature because the visible browser UI is often just the Cast button; technically, however, the component handles network-facing device interactions.A use-after-free flaw occurs when software continues to access memory after that memory has been released. Depending on the precise code path and mitigations in place, that kind of defect can lead to a crash, memory corruption, information exposure, or code execution. Google has not yet released technical details for CVE-2026-15902, nor has it said that the bug is being exploited in the wild.
That absence of exploitation reporting matters. Administrators should not label this a confirmed zero-day or assume that a typical malicious webpage alone can trigger it. At the same time, the weakness belongs in a security-sensitive portion of the browser that may interact with devices on the local network, which makes prompt updating sensible in offices, schools, shared Wi-Fi environments, and meeting-room deployments.
Google commonly restricts bug details and associated issue-tracker access until the update has reached a broad share of users. The practice limits the amount of immediately actionable information available to attackers attempting to reverse-engineer a newly released fix. It also means that the public currently lacks a confirmed attack path, a known affected Cast device list, and a vendor-supplied CVSS score for this individual CVE.
Chrome 150 Is the Baseline Windows Teams Need to Check
For Windows, the actionable remediation target is Chrome 150.0.7871.128 or newer. Google staged the release over days and weeks, so not every endpoint will necessarily receive it at the same moment through ordinary background updating.Users can verify the installed build by opening Chrome’s menu, selecting Help, then About Google Chrome. Chrome will normally begin checking for an available update from that page. A restart completes the update when Chrome reports that a relaunch is required.
Enterprise teams should not depend solely on a user-driven check. Chrome’s version can be collected through endpoint-management platforms, browser-management reporting, software inventory, or vulnerability scanning. The key reporting query is uncomplicated: find Windows systems with Google Chrome versions earlier than 150.0.7871.128, then remediate and confirm the post-update version.
A short response plan is appropriate:
- Update managed Windows endpoints to Chrome 150.0.7871.128 or later and require a browser restart where the update is pending.
- Identify systems that have Chrome installed but are rarely restarted, including kiosks, meeting-room PCs, shared workstations, and persistent virtual desktops.
- Review local-network exposure where Chrome Cast is permitted, particularly on guest wireless networks and conference-room VLANs.
- Record CVE-2026-15902 as vendor-fixed even if NVD-dependent tooling has not yet populated a full record, score, or product mapping.
Chromium Browser Fleets Need Separate Vendor Checks
CVE-2026-15902 is a Chromium vulnerability, but a Chrome patch does not automatically mean every Chromium-based browser has already absorbed the fix. Microsoft Edge, Brave, Vivaldi, Opera, Electron applications, embedded WebView2 deployments, and custom Chromium builds all have their own release schedules and support boundaries.Windows administrators should therefore avoid a common shortcut: updating Chrome is not proof that Edge is protected, and updating Edge is not proof that Chrome is current. Each installed browser or Chromium-derived application needs to be assessed against its own vendor release information.
Microsoft Edge is especially relevant in Windows environments because it is widely deployed and tightly integrated with operating-system workflows. But the right operational response is to monitor Microsoft’s security release notes and update Edge through its normal channel, rather than assuming that Chrome 150’s version number maps directly to an Edge build. The same caution applies to WebView2 Runtime, whose Chromium base and patch cadence are managed separately.
For organizations that disable Cast through policy, the control can reduce feature exposure, but it should not be treated as a substitute for patching. Policy state is often inconsistent across BYOD systems, unmanaged laptops, developer machines, and conference-room devices. More importantly, Google’s public advisory does not state that disabling Cast fully removes the vulnerable code path.
The next milestone is NVD enrichment: a finalized vulnerability description, severity assessment, affected-product metadata, and potentially references to Google’s restricted issue tracker may appear later. None of that changes the present decision. Chrome 150.0.7871.128 is the required Windows baseline, and the lack of an NVD record should be documented as a feed-lag issue—not accepted as an excuse to defer the update.
References
- Primary source: NVD / Chromium
Published: 2026-07-17T17:42:40-07:00
NVD - CVE-2026-15902
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-17T17:42:40-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com