Google Chrome versions earlier than 150.0.7871.46 are affected by CVE-2026-14420, a Critical out-of-bounds read and write in Dawn that could allow a remote attacker using a crafted HTML page to potentially escape the browser sandbox. The affected product established by the public record is Google Chrome; the record does not establish that Microsoft Edge, every Chromium-based browser, Windows itself, or any other specific operating system is affected. CISA-ADP contributed a CVSS 3.1 score of 9.6 Critical, while its SSVC assessment lists exploitation as “none,” automatable as “no,” and technical impact as “total.”
Update now: Open
The public CVE description identifies CVE-2026-14420 as an out-of-bounds read and write in Dawn. It says a remote attacker could potentially perform a sandbox escape by convincing a user to open a crafted HTML page.
That description establishes several important facts. The attack vector involves remotely supplied web content, user interaction is required, and no prior privileges are required under the CISA-ADP CVSS assessment. The stated potential result is movement beyond Chrome’s sandbox rather than an effect explicitly confined to the original browser process.
The qualifier potentially matters. The record describes a possible security outcome; it does not provide a complete public exploit chain or establish that attackers are currently achieving that outcome. The associated Chromium issue is permissions-restricted, so the public material does not disclose the precise vulnerable operation, triggering conditions, exploit reliability, proof-of-concept code, or CVE-specific indicators of compromise.
That evidence boundary should be stated once and applied consistently:
Administrators and users should compare the complete four-part version. A result that says only “Chrome 150” is insufficient because builds within the same major release can fall on opposite sides of the boundary.
Version components should be compared numerically and in sequence:
The attribution matters. The supplied record does not contain a separate NVD-authored or NIST-authored CVSS assessment. Accurate reporting should therefore say that CISA-ADP contributed the 9.6 score displayed by NVD, not that “NVD scored the vulnerability 9.6.”
The vector models:
The changed-scope selection is consistent with the CVE description’s potential sandbox-escape outcome. It indicates that successful exploitation may affect resources governed by a security authority beyond the vulnerable component. It should not, however, be expanded into a claim of kernel access, administrator privileges, persistence, domain compromise, or total control of a user’s computer. The public record does not document those outcomes.
The following attribution table keeps the assessments separate:
Internal tickets, dashboards, vulnerability notices, and executive briefings should preserve that provenance. Labeling the value simply as an “NVD score” would conceal who calculated it.
“Exploitation: none” means the supplied SSVC assessment did not identify exploitation at the time represented by the record. It does not guarantee that exploitation is impossible or that the status cannot change later.
“Automatable: no” should also be reported without overinterpretation. It does not prove that attack delivery cannot be automated, that exploitation cannot scale, or that every attempt requires extensive manual work. It is the SSVC decision value contributed for this vulnerability.
“Technical impact: total” reflects the seriousness of the modeled successful outcome. That value aligns with the CVSS assessment’s changed scope and high confidentiality, integrity, and availability impacts.
Together, these fields support a measured conclusion: the supplied record does not establish active exploitation, but it does document a high-impact potential result and a clear update threshold. Administrators can remediate promptly without describing the vulnerability as an actively exploited zero-day.
The supplied facts do not support claims that the restriction reflects a standard pre-majority-update policy, that it is part of a particular rapid-release disclosure process, or that Google is withholding details until most users have updated. Those explanations should not be attached to this CVE without separate first-party documentation.
The restriction means the public record does not disclose:
An out-of-bounds read involves software accessing data beyond an intended memory boundary. An out-of-bounds write involves modifying memory beyond that boundary. Beyond those general definitions, administrators should avoid inventing details about shaders, buffers, command serialization, graphics backends, native APIs, drivers, or Dawn’s architecture. The supplied NVD facts do not establish those specifics for this vulnerability.
The record also does not identify a supported configuration workaround. Disabling hardware acceleration, changing graphics settings, blocking a particular browser feature, or applying a command-line switch should not be presented as equivalent to installing the fixed Chrome version unless Google publishes CVE-specific guidance establishing that result.
Subsequent CISA-ADP enrichment: CISA-ADP contributed the 9.6 Critical CVSS 3.1 calculation, the CWE mappings, and the SSVC values listing exploitation as “none,” automatable as “no,” and technical impact as “total.”
Subsequent NIST analysis: NIST added affected-product configuration information identifying Google Chrome versions earlier than 150.0.7871.46 as vulnerable.
Later SSVC metadata modification: CISA-ADP modified SSVC metadata without changing the substantive decision points listed in the supplied record.
This sequence explains why one NVD page can contain information from several sources. Chrome supplied the core CVE material, CISA-ADP supplied the displayed severity and SSVC assessments, and NIST supplied configuration analysis. NVD presents those contributions together, but presentation does not make every field NVD-authored.
Exact July 2 and July 3 event claims are omitted here because they are not necessary to apply the fix and should not be stated without confirmed source-level timestamps for CVE-2026-14420.
The CVE record does not prescribe a particular endpoint-management product, browser-management platform, inventory agent, policy, registry query, or software-distribution method. Organizations can use their established tools, but the evidence they collect must answer two concrete questions:
A deployment job marked successful is useful operational information, but it is not the CVE-specific closure test. The closure test is a complete running Chrome version at or above 150.0.7871.46, verified after relaunch.
Where centralized results are unclear, a user or support technician can verify the endpoint directly by opening
The record does not list Microsoft Edge, every Chromium-derived browser, embedded browser runtimes, standalone Dawn consumers, graphics drivers, or Windows as affected products. Shared components or common upstream ancestry may justify watching other vendors for advisories, but they do not establish identical affected ranges.
Administrators should avoid two opposite errors:
The same distinction applies when Chrome is installed but is not the default browser. Default-browser status does not determine applicability. If Google Chrome is present and in scope, its own complete version must be checked.
The phrase “sandbox escape” also should not be expanded into unsupported claims about a complete Windows compromise. The CVE description establishes the potential crossing of Chrome’s sandbox boundary. It does not specify the resulting operating-system privileges, persistence, credential access, kernel access, or broader attack chain.
Generic browser crashes or unusual system activity should not be labeled as exploitation of this vulnerability without additional technical evidence. Conversely, the absence of a crash or security alert does not prove that an older Chrome installation is safe.
The defensible exposure test is therefore version-based:
For individual users, remediation takes a few steps: open
For enterprises, the work is complete only when the administrator has collected the full running Chrome version and relaunch state for each installation. A result of 150.0.7871.46 or later passes. A result below 150.0.7871.46 fails. Missing, stale, truncated, contradictory, or pre-relaunch evidence remains unknown and should stay open.
Additional technical details or revised exploitation information may emerge later. Until the authoritative record changes, the immediate objective is precise and verifiable: move every affected Google Chrome installation beyond the published version boundary, complete the relaunch, and retain fresh evidence proving that the running browser is no longer below 150.0.7871.46.
Update now: Open
chrome://settings/help, or select Chrome’s three-dot menu and choose Help > About Google Chrome. Wait for Chrome to complete the update check and apply the available update, then click Relaunch. After Chrome reopens, return to the same page and confirm that the complete displayed version is 150.0.7871.46 or later. A version below that boundary remains affected.
A Crafted Page Can Reach Toward Chrome’s Sandbox Boundary
The public CVE description identifies CVE-2026-14420 as an out-of-bounds read and write in Dawn. It says a remote attacker could potentially perform a sandbox escape by convincing a user to open a crafted HTML page.That description establishes several important facts. The attack vector involves remotely supplied web content, user interaction is required, and no prior privileges are required under the CISA-ADP CVSS assessment. The stated potential result is movement beyond Chrome’s sandbox rather than an effect explicitly confined to the original browser process.
The qualifier potentially matters. The record describes a possible security outcome; it does not provide a complete public exploit chain or establish that attackers are currently achieving that outcome. The associated Chromium issue is permissions-restricted, so the public material does not disclose the precise vulnerable operation, triggering conditions, exploit reliability, proof-of-concept code, or CVE-specific indicators of compromise.
That evidence boundary should be stated once and applied consistently:
- Known: Google Chrome versions before 150.0.7871.46 are affected.
- Known: The issue is an out-of-bounds read and write in Dawn.
- Known: The documented attack scenario uses a crafted HTML page.
- Known: The stated potential result is a Chrome sandbox escape.
- Known: CISA-ADP’s assessment requires user interaction and no prior privileges.
- Known: The supplied SSVC assessment records exploitation as “none.”
- Unknown from the public record: The exact trigger, exploit reliability, required browser configuration, proof-of-concept details, and post-exploitation behavior.
Version 150.0.7871.46 Is the Security Boundary That Matters
Google Chrome versions earlier than 150.0.7871.46 fall within the documented affected range. Version 150.0.7871.46 itself, and numerically later versions, meet the stated remediation threshold.Administrators and users should compare the complete four-part version. A result that says only “Chrome 150” is insufficient because builds within the same major release can fall on opposite sides of the boundary.
| Chrome state | Version condition | CVE-2026-14420 status | Required response |
|---|---|---|---|
| Older installation | Earlier than 150.0.7871.46 | Within the affected range | Update, relaunch, and verify again |
| Fixed threshold | Exactly 150.0.7871.46 | Outside the affected range | Record as passing after relaunch verification |
| Newer installation | Later than 150.0.7871.46 | Outside the affected range | Record as passing after verification |
| Incomplete result | “Chrome 150” without the remaining components | Unverified | Collect the complete version |
| Missing, stale, or conflicting result | Current version cannot be established | Unknown | Keep open until fresh evidence is collected |
150, then 0, then 7871, then 46. The major milestone alone is not compliance evidence.Exact Chrome update procedure
- Open Google Chrome.
- Enter
chrome://settings/helpin the address bar and press Enter. Alternatively, open the three-dot menu and select Help > About Google Chrome. - Wait for Chrome to complete its update check and apply the available update.
- If Chrome displays Relaunch, save any necessary work and click it.
- After Chrome reopens, return to
chrome://settings/helpor Help > About Google Chrome. - Read the complete displayed Chrome version.
- Confirm that it is 150.0.7871.46 or later.
The 9.6 Score Comes From CISA-ADP, Not NVD
The National Vulnerability Database displays a CISA-ADP CVSS 3.1 assessment for CVE-2026-14420. Its vector isCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, producing a base score of 9.6 Critical.The attribution matters. The supplied record does not contain a separate NVD-authored or NIST-authored CVSS assessment. Accurate reporting should therefore say that CISA-ADP contributed the 9.6 score displayed by NVD, not that “NVD scored the vulnerability 9.6.”
The vector models:
- A network attack vector.
- Low attack complexity under the CVSS definition.
- No privileges required.
- Required user interaction.
- Changed scope.
- High potential effects on confidentiality, integrity, and availability.
The changed-scope selection is consistent with the CVE description’s potential sandbox-escape outcome. It indicates that successful exploitation may affect resources governed by a security authority beyond the vulnerable component. It should not, however, be expanded into a claim of kernel access, administrator privileges, persistence, domain compromise, or total control of a user’s computer. The public record does not document those outcomes.
The following attribution table keeps the assessments separate:
| Assessment source | Rating or status | What it establishes |
|---|---|---|
| Chromium | Critical | The vendor-side security severity associated with the issue |
| CISA-ADP CVSS 3.1 | 9.6 Critical | A contributed standardized severity calculation displayed by NVD |
| CISA-ADP SSVC | Exploitation: none; automatable: no; technical impact: total | Point-in-time decision-support information |
| NVD/NIST CVSS | No separate score in the supplied record | NVD displays the CISA-ADP contribution but did not author it |
SSVC Says No Known Exploitation, but Total Technical Impact
CISA-ADP’s SSVC entry lists exploitation as “none,” automatable as “no,” and technical impact as “total.”“Exploitation: none” means the supplied SSVC assessment did not identify exploitation at the time represented by the record. It does not guarantee that exploitation is impossible or that the status cannot change later.
“Automatable: no” should also be reported without overinterpretation. It does not prove that attack delivery cannot be automated, that exploitation cannot scale, or that every attempt requires extensive manual work. It is the SSVC decision value contributed for this vulnerability.
“Technical impact: total” reflects the seriousness of the modeled successful outcome. That value aligns with the CVSS assessment’s changed scope and high confidentiality, integrity, and availability impacts.
Together, these fields support a measured conclusion: the supplied record does not establish active exploitation, but it does document a high-impact potential result and a clear update threshold. Administrators can remediate promptly without describing the vulnerability as an actively exploited zero-day.
The Restricted Issue Leaves Exploitation Details Unknown
The Chromium issue associated with CVE-2026-14420 requires permission to view. That establishes that public access is restricted; it does not, by itself, establish why access was restricted or when additional details may become available.The supplied facts do not support claims that the restriction reflects a standard pre-majority-update policy, that it is part of a particular rapid-release disclosure process, or that Google is withholding details until most users have updated. Those explanations should not be attached to this CVE without separate first-party documentation.
The restriction means the public record does not disclose:
- The precise Dawn function or object involved.
- The exact memory layout or triggering operation.
- Whether a particular browser option or feature state is required.
- The reliability of the out-of-bounds access.
- Whether another vulnerability would be required for a practical exploit chain.
- A proof of concept or exploit sample.
- CVE-specific malicious domains, hashes, network patterns, or endpoint artifacts.
An out-of-bounds read involves software accessing data beyond an intended memory boundary. An out-of-bounds write involves modifying memory beyond that boundary. Beyond those general definitions, administrators should avoid inventing details about shaders, buffers, command serialization, graphics backends, native APIs, drivers, or Dawn’s architecture. The supplied NVD facts do not establish those specifics for this vulnerability.
The record also does not identify a supported configuration workaround. Disabling hardware acceleration, changing graphics settings, blocking a particular browser feature, or applying a command-line switch should not be presented as equivalent to installing the fixed Chrome version unless Google publishes CVE-specific guidance establishing that result.
Record Timeline and Attribution
The supplied NVD history establishes that NVD received the CVE information from Chrome on July 1, 2026. That wording is narrower and more accurate than saying Google publicly disclosed the vulnerability on that date.Timeline
July 1, 2026 — Chrome-originated CVE information received by NVD: The record identifies Chrome as the source and supplies the vulnerability description, affected-version information, Chrome advisory reference, and permission-restricted Chromium issue reference.Subsequent CISA-ADP enrichment: CISA-ADP contributed the 9.6 Critical CVSS 3.1 calculation, the CWE mappings, and the SSVC values listing exploitation as “none,” automatable as “no,” and technical impact as “total.”
Subsequent NIST analysis: NIST added affected-product configuration information identifying Google Chrome versions earlier than 150.0.7871.46 as vulnerable.
Later SSVC metadata modification: CISA-ADP modified SSVC metadata without changing the substantive decision points listed in the supplied record.
This sequence explains why one NVD page can contain information from several sources. Chrome supplied the core CVE material, CISA-ADP supplied the displayed severity and SSVC assessments, and NIST supplied configuration analysis. NVD presents those contributions together, but presentation does not make every field NVD-authored.
Exact July 2 and July 3 event claims are omitted here because they are not necessary to apply the fix and should not be stated without confirmed source-level timestamps for CVE-2026-14420.
Enterprise Closure Requires Version and Relaunch Evidence
For managed environments, the objective is not merely to send an update instruction. It is to produce current evidence showing that each in-scope Google Chrome installation is running version 150.0.7871.46 or later after the required relaunch.The CVE record does not prescribe a particular endpoint-management product, browser-management platform, inventory agent, policy, registry query, or software-distribution method. Organizations can use their established tools, but the evidence they collect must answer two concrete questions:
- What is the complete version of Chrome currently running on the endpoint?
- Has Chrome been relaunched since the corrective update was applied?
- Device or asset identity.
- Complete four-part running Chrome version.
- Time of the verification.
- Relaunch state or evidence that the version was collected after Chrome restarted.
- Owner and follow-up action for any unresolved endpoint.
| Enterprise verification result | Status | Administrator action |
|---|---|---|
| Full running version is 150.0.7871.46 or later, verified after relaunch | Pass | Record the evidence and close the finding for that installation |
| Full running version is earlier than 150.0.7871.46 | Fail | Keep open, update Chrome, relaunch it, and collect fresh evidence |
| Version is missing, truncated, stale, or conflicting | Unknown | Keep open until a trustworthy current version is obtained |
| Update was assigned but relaunch state is unknown | Unknown | Confirm relaunch and re-query the running version |
| Google Chrome is confirmed not installed | Not applicable | Record that determination separately from compliant devices |
Where centralized results are unclear, a user or support technician can verify the endpoint directly by opening
chrome://settings/help, allowing the check to finish, clicking Relaunch, reopening the page, and reporting the full displayed version. Any result below 150.0.7871.46 fails. Any result equal to or later than 150.0.7871.46 passes. Missing or incomplete evidence remains unresolved.Action checklist for admins
- Identify in-scope devices on which Google Chrome is installed.
- Collect the complete running Chrome version rather than only the major milestone.
- Flag every result earlier than 150.0.7871.46 as affected.
- Treat missing, stale, truncated, or conflicting results as unknown.
- Deploy an approved Chrome release at or above 150.0.7871.46 through the organization’s established process.
- Arrange and confirm the Chrome relaunch needed to complete remediation.
- Re-query the running version after relaunch.
- Record the device identity, full version, verification time, and relaunch state.
- Close only installations verified at 150.0.7871.46 or later.
- Keep installations below the boundary in the remediation queue.
- Assign an owner and follow-up plan to every unresolved endpoint.
- Preserve the attribution of the 9.6 score to CISA-ADP.
- Preserve the SSVC wording: exploitation “none,” automatable “no,” and technical impact “total.”
- Do not assign Chrome’s version threshold to Edge or another Chromium-derived product without product-specific vendor guidance.
- Monitor authoritative Chrome, NVD, and CISA information for changes to product scope or exploitation status.
This Record Establishes Chrome, Not Edge or Every Chromium Browser
The affected product identified in the supplied record is Google Chrome. That is the product scope supported by the evidence.The record does not list Microsoft Edge, every Chromium-derived browser, embedded browser runtimes, standalone Dawn consumers, graphics drivers, or Windows as affected products. Shared components or common upstream ancestry may justify watching other vendors for advisories, but they do not establish identical affected ranges.
Administrators should avoid two opposite errors:
- Do not declare every Chromium-derived product vulnerable solely because the Chrome record names Dawn.
- Do not declare another product unaffected solely because it is absent from this Chrome-specific record.
The same distinction applies when Chrome is installed but is not the default browser. Default-browser status does not determine applicability. If Google Chrome is present and in scope, its own complete version must be checked.
The phrase “sandbox escape” also should not be expanded into unsupported claims about a complete Windows compromise. The CVE description establishes the potential crossing of Chrome’s sandbox boundary. It does not specify the resulting operating-system privileges, persistence, credential access, kernel access, or broader attack chain.
Version-Based Remediation Is the Available Control
The supplied public information does not provide CVE-specific indicators that can replace version checks. It contains no malicious domain, file hash, exploit signature, process pattern, command line, or network indicator tied specifically to CVE-2026-14420.Generic browser crashes or unusual system activity should not be labeled as exploitation of this vulnerability without additional technical evidence. Conversely, the absence of a crash or security alert does not prove that an older Chrome installation is safe.
The defensible exposure test is therefore version-based:
- Determine whether Google Chrome is installed.
- Obtain the complete running version.
- Update it if the version is below 150.0.7871.46.
- Relaunch Chrome.
- Collect fresh evidence showing 150.0.7871.46 or later.
The Patch Is Straightforward; Verification Is the Real Finish Line
CVE-2026-14420 presents a clear operational rule despite its restricted technical details. Google Chrome versions earlier than 150.0.7871.46 are within the affected range. CISA-ADP contributed the 9.6 Critical CVSS score displayed by NVD, while its SSVC assessment reports exploitation as “none,” automatable as “no,” and technical impact as “total.” Chrome is the only affected product established by this record.For individual users, remediation takes a few steps: open
chrome://settings/help, wait for the update check, click Relaunch, and confirm the full displayed version is 150.0.7871.46 or later.For enterprises, the work is complete only when the administrator has collected the full running Chrome version and relaunch state for each installation. A result of 150.0.7871.46 or later passes. A result below 150.0.7871.46 fails. Missing, stale, truncated, contradictory, or pre-relaunch evidence remains unknown and should stay open.
Additional technical details or revised exploitation information may emerge later. Until the authoritative record changes, the immediate objective is precise and verifiable: move every affected Google Chrome installation beyond the published version boundary, complete the relaunch, and retain fresh evidence proving that the running browser is no longer below 150.0.7871.46.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:38:09-07:00
NVD - CVE-2026-14420
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:38:09-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: chromium.org
- Related coverage: dawn.googlesource.com
