Google Chrome 150.0.7871.128/.129 for Windows and macOS fixes CVE-2026-15905, a high-severity use-after-free flaw in Chromium’s Aura UI framework. Windows users and administrators should treat Chrome versions earlier than 150.0.7871.128 as requiring an expedited browser update, even though the National Vulnerability Database currently returns “CVE ID Not Found” for the identifier.
Google disclosed the issue in its July 16 Stable Channel update for desktop, where it lists CVE-2026-15905 as “Use after free in Aura,” reported internally on July 9. The same release contains six other security fixes, including critical use-after-free vulnerabilities in CameraCapture, GPU, and Network.
The immediate action is straightforward: update managed and unmanaged Chrome installations to 150.0.7871.128 or later. Windows builds may report 150.0.7871.128 or 150.0.7871.129, both of which are within Google’s fixed release.
The NVD page’s “CVE ID Not Found” message is easy to misread as an invalid or unconfirmed advisory. In this case, it reflects a timing gap in vulnerability-data publishing rather than a retraction: Google’s own Chrome Releases bulletin assigns the CVE, names the affected component, rates it High, and identifies the fixed Stable release.
NIST explicitly notes that a CVE may not yet be visible in NVD when its CVE record remains reserved or has not been ingested. That delay matters for operations teams whose patch workflows depend on NVD-enriched data, CVSS fields, CPE mappings, or scanner feeds. A missing NVD record should not be used as a reason to defer a vendor-issued browser update.
Tenable’s newly published Nessus coverage reaches the same practical conclusion. Its detection content flags Chrome installations below 150.0.7871.128 as affected by the July security release and includes CVE-2026-15905 among the identified vulnerabilities. The plugin is version-based rather than exploit-based, which is normal for browser patch assessment.
For this incident, Google’s release note is the authoritative source for the fix boundary. The NVD record may gain a description, CVSS scoring, affected-product metadata, and references later, but none of those additions changes the update already available to users.
A use-after-free occurs when software continues to access an object after the memory backing that object has been released. The effect can range from a reproducible browser crash to memory corruption that an attacker can potentially turn into code execution or a security-boundary bypass. The severity depends on the precise object lifecycle, the execution context, mitigations, and whether another flaw is needed to create a workable exploitation chain.
Google has not published technical details for CVE-2026-15905, proof-of-concept code, a bounty amount, or an exploit narrative. Its release process routinely keeps Chromium bug details restricted until most users have received the update, reducing the window in which public technical information can be used against unpatched systems.
That absence is important. Administrators should not infer remote code execution, sandbox escape, or active exploitation from “use after free” alone. Conversely, the lack of public exploit details does not make the vulnerability low priority: Google assigned it a High severity rating and shipped it in the first Chrome 150 Stable security update.
The release includes several critical memory-safety fixes alongside the Aura flaw, but it contains no special warning attached to CVE-2026-15905. Tenable’s associated detection metadata likewise describes no known public exploit at publication. As of July 17, the evidence supports ordinary but prompt patching rather than incident-response assumptions.
This distinction can help security teams prioritize appropriately:
For managed fleets, the stronger approach is to verify actual installed versions through endpoint-management inventory rather than relying on update policy intent. Browser auto-update services can be disabled, delayed by user session behavior, blocked by application-control rules, or superseded by packaging controls. Shared kiosks, VDI golden images, lab systems, and devices with limited user sign-in are common places for browser versions to drift.
Chrome Enterprise administrators should confirm that their update channel and deployment tooling have begun offering Chrome 150. Organizations that deliberately pin Chrome to a previous version for compatibility validation now have a concrete security reason to complete that validation quickly. Extended Stable environments also need a separate check: Google labels this bulletin as including Extended Stable updates, but the relevant question is the installed build number, not merely the channel name.
The update also applies beyond Chrome. Chromium-based browsers frequently absorb upstream fixes on their own schedules, and a Chromium bug in Aura can be relevant to other Windows browsers or embedded applications. But CVE-2026-15905 should not be mapped blindly to Microsoft Edge, Brave, Vivaldi, Opera, Electron applications, or custom Chromium distributions without a vendor advisory or a confirmed Chromium version relationship.
That caveat is particularly important on Windows, where Edge is commonly managed as part of the operating-system servicing baseline. Microsoft has not issued a corresponding CVE-2026-15905 advisory in its Security Update Guide at the time of publication. Edge administrators should monitor Microsoft’s release notes rather than assume Google Chrome’s fixed version translates directly to Edge’s versioning.
For Windows administrators, the operational truth is already clear: Google shipped the fix on July 16, 2026, in Chrome 150.0.7871.128/.129. The NVD listing may be incomplete today, but the patch window is open now—and devices still below that build are the ones that need attention.
Google disclosed the issue in its July 16 Stable Channel update for desktop, where it lists CVE-2026-15905 as “Use after free in Aura,” reported internally on July 9. The same release contains six other security fixes, including critical use-after-free vulnerabilities in CameraCapture, GPU, and Network.
The immediate action is straightforward: update managed and unmanaged Chrome installations to 150.0.7871.128 or later. Windows builds may report 150.0.7871.128 or 150.0.7871.129, both of which are within Google’s fixed release.
The NVD Entry Is Missing, Not the Fix
The NVD page’s “CVE ID Not Found” message is easy to misread as an invalid or unconfirmed advisory. In this case, it reflects a timing gap in vulnerability-data publishing rather than a retraction: Google’s own Chrome Releases bulletin assigns the CVE, names the affected component, rates it High, and identifies the fixed Stable release.NIST explicitly notes that a CVE may not yet be visible in NVD when its CVE record remains reserved or has not been ingested. That delay matters for operations teams whose patch workflows depend on NVD-enriched data, CVSS fields, CPE mappings, or scanner feeds. A missing NVD record should not be used as a reason to defer a vendor-issued browser update.
Tenable’s newly published Nessus coverage reaches the same practical conclusion. Its detection content flags Chrome installations below 150.0.7871.128 as affected by the July security release and includes CVE-2026-15905 among the identified vulnerabilities. The plugin is version-based rather than exploit-based, which is normal for browser patch assessment.
For this incident, Google’s release note is the authoritative source for the fix boundary. The NVD record may gain a description, CVSS scoring, affected-product metadata, and references later, but none of those additions changes the update already available to users.
Aura Is Chrome’s Native Windowing Layer
Aura is a Chromium UI framework used for native application windows, widgets, input handling, focus management, compositor-backed interface surfaces, and related desktop shell behavior. On Windows, it is part of the browser’s native application layer rather than the HTML and JavaScript content rendered inside a webpage.A use-after-free occurs when software continues to access an object after the memory backing that object has been released. The effect can range from a reproducible browser crash to memory corruption that an attacker can potentially turn into code execution or a security-boundary bypass. The severity depends on the precise object lifecycle, the execution context, mitigations, and whether another flaw is needed to create a workable exploitation chain.
Google has not published technical details for CVE-2026-15905, proof-of-concept code, a bounty amount, or an exploit narrative. Its release process routinely keeps Chromium bug details restricted until most users have received the update, reducing the window in which public technical information can be used against unpatched systems.
That absence is important. Administrators should not infer remote code execution, sandbox escape, or active exploitation from “use after free” alone. Conversely, the lack of public exploit details does not make the vulnerability low priority: Google assigned it a High severity rating and shipped it in the first Chrome 150 Stable security update.
No Public Evidence of Active Exploitation
Google’s July 16 bulletin does not say that CVE-2026-15905 is being exploited in the wild. That wording is significant because Google typically calls out known active exploitation directly when it has evidence of it.The release includes several critical memory-safety fixes alongside the Aura flaw, but it contains no special warning attached to CVE-2026-15905. Tenable’s associated detection metadata likewise describes no known public exploit at publication. As of July 17, the evidence supports ordinary but prompt patching rather than incident-response assumptions.
This distinction can help security teams prioritize appropriately:
- Chrome installations below 150.0.7871.128 should be upgraded through the normal emergency browser-patching process.
- Teams should avoid treating the NVD’s empty entry as proof that the issue is invalid or irrelevant.
- SOC teams should not automatically classify crashes, UI anomalies, or web activity as indicators of compromise solely because of this CVE.
- Threat-hunting escalation should be driven by telemetry, suspicious browser behavior, exploit intelligence, or a later vendor statement indicating active abuse.
Chrome 150 Is the Line Administrators Need to Track
Google says the Stable channel update is rolling out over days and weeks, so some Windows endpoints may not yet have picked it up automatically. In Chrome, the installed version can be checked from the About Google Chrome page or through thechrome://settings/help interface; opening that page normally triggers an update check. A relaunch is usually required to load the newly installed browser binaries.For managed fleets, the stronger approach is to verify actual installed versions through endpoint-management inventory rather than relying on update policy intent. Browser auto-update services can be disabled, delayed by user session behavior, blocked by application-control rules, or superseded by packaging controls. Shared kiosks, VDI golden images, lab systems, and devices with limited user sign-in are common places for browser versions to drift.
Chrome Enterprise administrators should confirm that their update channel and deployment tooling have begun offering Chrome 150. Organizations that deliberately pin Chrome to a previous version for compatibility validation now have a concrete security reason to complete that validation quickly. Extended Stable environments also need a separate check: Google labels this bulletin as including Extended Stable updates, but the relevant question is the installed build number, not merely the channel name.
The update also applies beyond Chrome. Chromium-based browsers frequently absorb upstream fixes on their own schedules, and a Chromium bug in Aura can be relevant to other Windows browsers or embedded applications. But CVE-2026-15905 should not be mapped blindly to Microsoft Edge, Brave, Vivaldi, Opera, Electron applications, or custom Chromium distributions without a vendor advisory or a confirmed Chromium version relationship.
That caveat is particularly important on Windows, where Edge is commonly managed as part of the operating-system servicing baseline. Microsoft has not issued a corresponding CVE-2026-15905 advisory in its Security Update Guide at the time of publication. Edge administrators should monitor Microsoft’s release notes rather than assume Google Chrome’s fixed version translates directly to Edge’s versioning.
The Vulnerability Database Will Catch Up After the Browser Does
CVE-2026-15905 is a useful reminder that the public vulnerability-data ecosystem does not move in a single synchronized step. A Chrome Stable release, a CVE assignment, a scanner rule, the CVE Program record, NVD enrichment, and downstream asset-management coverage can all appear at different times.For Windows administrators, the operational truth is already clear: Google shipped the fix on July 16, 2026, in Chrome 150.0.7871.128/.129. The NVD listing may be incomplete today, but the patch window is open now—and devices still below that build are the ones that need attention.
References
- Primary source: NVD / Chromium
Published: 2026-07-17T17:42:44-07:00
NVD - CVE-2026-15905
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-17T17:42:44-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com