Update Google Chrome to 150.0.7871.46 or later and relaunch it; CVE-2026-14425 affects earlier Chrome versions and may permit a sandbox escape through a crafted HTML page. Google rates the Chromium security severity as High, while a separate CISA-ADP contribution supplies a 9.6 Critical CVSS 3.1 score. The 9.6 value appears in the NVD record, but it is not an NVD-authored score.
The vulnerability deserves prompt action because the published description connects attacker-controlled HTML with a potential browser sandbox escape. The available SSVC record lists exploitation: none, automatable: no, and technical impact: total. Those fields should be reported as written without treating them as proof of active exploitation or as a prediction of how exploitation might develop.
The published description is concise: Google Chrome before version 150.0.7871.46 may allow a remote attacker to perform a sandbox escape through a crafted HTML page. It does not say that every crafted page will succeed, identify a confirmed attack campaign, or document a complete compromise sequence. It establishes the affected component, the weakness category, the remote HTML delivery condition, and the potential sandbox-escape result.
That potential result is the important boundary in the record. A sandbox is intended to limit what browser content can affect. A vulnerability described as permitting a potential sandbox escape therefore warrants more attention than a record limited to a tab crash or another effect contained within the browser’s restricted environment.
The contributed CVSS vector records user interaction as required. In this case, the disclosed mechanism is a crafted HTML page. Administrators should not translate that condition into a requirement for elevated privileges, local software installation, or a complex action unless another source specifically establishes such a requirement.
At the same time, the record does not provide enough public detail to describe the exact trigger, vulnerable function, memory layout, exploit reliability, or environmental prerequisites. The referenced Chromium issue is marked as permission-required, but that status alone establishes only that unrestricted public access is unavailable. It does not support broader conclusions about why access is restricted or what additional technical information any particular party possesses.
The defensible response is therefore version-based remediation. The published fixed boundary is known, while speculative configuration changes are not identified as substitutes for the corrected Chrome release.
Version 150.0.7871.46 is a minimum fixed threshold, not a recommendation to hold systems permanently on that release. If the organization’s approved Chrome channel provides a later supported build, administrators should deploy that later build rather than downgrade or pin Chrome to the minimum version associated with this CVE.
The validation step should use the complete four-part version. Reporting only “Chrome 150” is not enough to distinguish a fixed installation from another build in the same major-version family.
Those labels come from different assessment sources:
The vector records the following modeled characteristics:
It would therefore be inaccurate to describe CVE-2026-14425 simply as “NVD-rated 9.6” or “NVD Critical.” A precise vulnerability ticket or news summary should say:
Organizations may assign different remediation deadlines to a vendor-rated High vulnerability and a CVSS score of 9.6. If internal policy creates that distinction, the ticket should preserve both values rather than replacing Google’s severity with the contributed score or omitting the contributed score because Google used a different label.
The practical result remains straightforward under either assessment: Chrome versions earlier than 150.0.7871.46 should be updated and verified promptly.
These values should be repeated without adding conclusions that the record does not contain.
Exploitation: none means that the SSVC entry records no exploitation. It should not be rewritten as proof that exploitation is impossible, that no proof of concept exists, or that no system has ever encountered a malicious page.
Automatable: no is the value listed in the record. Without additional sourced analysis, it should not be expanded into claims about exploit scale, victim selection, delivery infrastructure, or the reasoning behind the SSVC determination.
Technical impact: total is likewise the recorded selection. The record does not need to be embellished with a custom definition to justify remediation, because the Chrome description already identifies the potential outcome as a sandbox escape.
Taken together, these fields provide useful context but do not replace the version test. They do not change the affected boundary and do not create an alternative mitigation. Administrators still need to move Chrome to 150.0.7871.46 or later, relaunch it, and verify the resulting version.
CISA-ADP enrichment — CISA-ADP supplies the CVSS 3.1 vector and 9.6 Critical score. It also supplies the SSVC values listing exploitation as none, automatable as no, and technical impact as total.
NIST/NVD analysis — The NVD record presents the Chrome affected-product configuration and displays the contributed assessment data. The presence of the CISA-ADP score on the NVD page does not make it an NVD-authored CVSS score.
This division of responsibility is more important than an unsupported hour-by-hour disclosure narrative. Security teams should record which organization supplied each assessment so later audits can distinguish vendor severity, contributed CVSS data, SSVC values, and affected-product enrichment.
The exact commands, Chrome Enterprise policies, and management-console paths are organization-specific because the supplied vulnerability record does not identify a required Windows management product or deployment mechanism. Each organization should translate the following procedure into its approved tooling before declaring the issue remediated.
Administrators should not copy
The inverse assumption would also go beyond the evidence. The absence of Edge from this Chrome record should not be presented as proof that every other Chromium-derived browser is unaffected. Administrators should evaluate other browsers through the advisories and fixed versions published by their respective vendors.
For vulnerability-management purposes, maintain three distinct facts:
The permission-required issue reference does not justify guessing at those missing details. It establishes restricted access to that reference, nothing more.
Security teams can continue using their normal browser and endpoint monitoring, but the published facts do not support a CVE-specific detection recipe. A clean alert dashboard also does not establish that a system running an affected Chrome version is safe.
The source-grounded, measurable control is version compliance:
The scoring record requires more careful language. Google calls the Chromium issue High severity. CISA-ADP contributes a CVSS 3.1 vector that produces a 9.6 Critical score. NVD displays that contribution, but the 9.6 score should not be attributed to NVD as its own assessment.
The SSVC entry should be equally precise: exploitation is listed as none, automatable as no, and technical impact as total. Those values add context but do not justify predictions about exploit development, attack delivery, or future campaigns.
For individual Windows users, the final action is:
Open Chrome menu > Help > About Google Chrome, update to 150.0.7871.46 or later, select Relaunch, and reopen About Google Chrome to confirm the fixed version.
For managed Windows environments, query the fleet for Google Chrome versions below
Remediate now
- In Chrome, open the three-dot menu.
- Select Help > About Google Chrome.
- Verify that the displayed version is 150.0.7871.46 or later.
- If Chrome offers an update, allow it to finish and select Relaunch.
- After Chrome reopens, return to Help > About Google Chrome and confirm that the active version is still 150.0.7871.46 or later.
150.0.7871.46, deploy the current organization-approved Chrome release through that same management platform, require a relaunch under the organization’s change policy, and run the identical version query again. Do not close the remediation ticket solely because a deployment job reports success; the follow-up inventory must show no managed Chrome installation below the fixed threshold.The vulnerability deserves prompt action because the published description connects attacker-controlled HTML with a potential browser sandbox escape. The available SSVC record lists exploitation: none, automatable: no, and technical impact: total. Those fields should be reported as written without treating them as proof of active exploitation or as a prediction of how exploitation might develop.
A Browser Bug Becomes More Serious at the Sandbox Boundary
CVE-2026-14425 is classified as CWE-416, Use After Free, in Chrome’s ANGLE component. A use-after-free weakness occurs when software accesses memory after the object associated with that memory has been released.The published description is concise: Google Chrome before version 150.0.7871.46 may allow a remote attacker to perform a sandbox escape through a crafted HTML page. It does not say that every crafted page will succeed, identify a confirmed attack campaign, or document a complete compromise sequence. It establishes the affected component, the weakness category, the remote HTML delivery condition, and the potential sandbox-escape result.
That potential result is the important boundary in the record. A sandbox is intended to limit what browser content can affect. A vulnerability described as permitting a potential sandbox escape therefore warrants more attention than a record limited to a tab crash or another effect contained within the browser’s restricted environment.
The contributed CVSS vector records user interaction as required. In this case, the disclosed mechanism is a crafted HTML page. Administrators should not translate that condition into a requirement for elevated privileges, local software installation, or a complex action unless another source specifically establishes such a requirement.
At the same time, the record does not provide enough public detail to describe the exact trigger, vulnerable function, memory layout, exploit reliability, or environmental prerequisites. The referenced Chromium issue is marked as permission-required, but that status alone establishes only that unrestricted public access is unavailable. It does not support broader conclusions about why access is restricted or what additional technical information any particular party possesses.
The defensible response is therefore version-based remediation. The published fixed boundary is known, while speculative configuration changes are not identified as substitutes for the corrected Chrome release.
The Version Line Is Clear
The affected configuration covers Google Chrome versions earlier than 150.0.7871.46. That gives users and administrators a direct compliance test: the version shown after updating and relaunching Chrome must be 150.0.7871.46 or later.| Deployment state | Chrome version | CVE-2026-14425 status | Required response |
|---|---|---|---|
| Below the fixed threshold | Earlier than 150.0.7871.46 | Affected | Update, relaunch, and recheck |
| Fixed threshold reached | 150.0.7871.46 | Fixed baseline for this CVE | Confirm through About Google Chrome |
| Later maintained build | Later than 150.0.7871.46 | Outside the published affected range | Retain the approved later release |
The validation step should use the complete four-part version. Reporting only “Chrome 150” is not enough to distinguish a fixed installation from another build in the same major-version family.
This four-step check is more useful than a generic instruction to “patch Chrome” because it ends with evidence from the browser’s own version display. For a managed fleet, the corresponding evidence is a post-remediation inventory result showing that no in-scope Chrome installation remains below the fixed threshold.
High and Critical Describe Different Assessments
The strongest interpretive point in the public record is the difference between Google’s High Chromium severity and the 9.6 Critical CVSS 3.1 contribution from CISA-ADP.Those labels come from different assessment sources:
- Google: High severity under the Chromium security process.
- CISA-ADP: CVSS 3.1 base score of 9.6, which maps to Critical.
- NVD: Displays the contributed CISA-ADP score but does not author that 9.6 value.
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:HThe vector records the following modeled characteristics:
- AV:N — Network attack vector
- AC:L — Low attack complexity
- PR:N — No privileges required
- UI:R — User interaction required
- S:C — Changed scope
- C:H — High confidentiality impact
- I:H — High integrity impact
- A:H — High availability impact
It would therefore be inaccurate to describe CVE-2026-14425 simply as “NVD-rated 9.6” or “NVD Critical.” A precise vulnerability ticket or news summary should say:
That wording preserves both assessments and their provenance. It also explains why one source may call the vulnerability High while another interface emphasizes Critical without implying that either label was copied incorrectly.
Organizations may assign different remediation deadlines to a vendor-rated High vulnerability and a CVSS score of 9.6. If internal policy creates that distinction, the ticket should preserve both values rather than replacing Google’s severity with the contributed score or omitting the contributed score because Google used a different label.
The practical result remains straightforward under either assessment: Chrome versions earlier than 150.0.7871.46 should be updated and verified promptly.
Read the SSVC Fields Narrowly
The CISA-ADP SSVC record lists three relevant values:| SSVC field | Recorded value |
|---|---|
| Exploitation | None |
| Automatable | No |
| Technical impact | Total |
Exploitation: none means that the SSVC entry records no exploitation. It should not be rewritten as proof that exploitation is impossible, that no proof of concept exists, or that no system has ever encountered a malicious page.
Automatable: no is the value listed in the record. Without additional sourced analysis, it should not be expanded into claims about exploit scale, victim selection, delivery infrastructure, or the reasoning behind the SSVC determination.
Technical impact: total is likewise the recorded selection. The record does not need to be embellished with a custom definition to justify remediation, because the Chrome description already identifies the potential outcome as a sandbox escape.
Taken together, these fields provide useful context but do not replace the version test. They do not change the affected boundary and do not create an alternative mitigation. Administrators still need to move Chrome to 150.0.7871.46 or later, relaunch it, and verify the resulting version.
How the Public Record Was Enriched
The vulnerability record contains contributions from more than one source. The available material establishes the roles of Chrome, CISA-ADP, and NIST/NVD, but the unsupported July 1, July 2, and July 3 timestamps should not be treated as confirmed chronology.Timeline of record contributions
Chrome disclosure — The Chrome material supplies the vulnerability description, the High severity classification, the CWE-416 weakness designation, the affected-version boundary, and references including a permission-required Chromium issue.CISA-ADP enrichment — CISA-ADP supplies the CVSS 3.1 vector and 9.6 Critical score. It also supplies the SSVC values listing exploitation as none, automatable as no, and technical impact as total.
NIST/NVD analysis — The NVD record presents the Chrome affected-product configuration and displays the contributed assessment data. The presence of the CISA-ADP score on the NVD page does not make it an NVD-authored CVSS score.
This division of responsibility is more important than an unsupported hour-by-hour disclosure narrative. Security teams should record which organization supplied each assessment so later audits can distinguish vendor severity, contributed CVSS data, SSVC values, and affected-product enrichment.
Managed Windows Remediation Must Produce Evidence
An administrative checklist is useful only when it identifies what counts as success. “Inventory, push, relaunch, and re-query” is not sufficient if no one defines the inventory filter, deployment target, relaunch requirement, or validation result.The exact commands, Chrome Enterprise policies, and management-console paths are organization-specific because the supplied vulnerability record does not identify a required Windows management product or deployment mechanism. Each organization should translate the following procedure into its approved tooling before declaring the issue remediated.
Executable fleet procedure
- Define the affected query.
In the organization’s software-inventory or browser-management system, filter for:- Product: Google Chrome
- Complete version: lower than
150.0.7871.46 - Scope: all Windows endpoints covered by the remediation ticket
- Export or save the initial result.
Preserve the affected device list and query time. This becomes the baseline against which remediation is measured. - Deploy the approved release.
Use the organization’s normal Chrome deployment mechanism to install its current approved version, provided that version is 150.0.7871.46 or later. The exact package, command, policy, deployment ring, and console location must come from the organization’s existing management documentation. - Require a relaunch.
Notify users or enforce browser closure according to the organization’s approved change and disruption policy. The vulnerability ticket should name the relaunch deadline rather than merely state that a relaunch is recommended. - Run the same inventory query again.
Reuse the original filter for Google Chrome versions lower than150.0.7871.46. - Investigate every remaining result.
A successful remediation result is zero in-scope installations below the threshold, subject to documented exceptions. Deployment success percentages, package assignment, or a completed management job are not equivalent to that result. - Manually validate a representative sample.
On selected endpoints, open Chrome menu > Help > About Google Chrome and confirm the complete version after relaunch.
Admin checklist
- [ ] Save an initial inventory of Google Chrome installations below 150.0.7871.46.
- [ ] Deploy the current approved Chrome version through the organization’s documented management process.
- [ ] Set and communicate a relaunch deadline.
- [ ] Repeat the same affected-version query after that deadline.
- [ ] Investigate all remaining devices and document approved exceptions.
- [ ] Manually confirm the complete version through Help > About Google Chrome on a representative endpoint sample.
- [ ] Record severity provenance as Google High and CISA-ADP CVSS 3.1 9.6 Critical.
- [ ] Close remediation only when the post-deployment evidence shows no unexplained installation below 150.0.7871.46.
Do Not Extend the Chrome Record to Edge Without Evidence
ANGLE is associated with Chromium technology, but the verified affected product in this record is Google Chrome. The affected configuration and fixed version are expressed as Chrome product data.Administrators should not copy
150.0.7871.46 into a Microsoft Edge compliance rule. Edge uses its own product versioning, release process, and vendor advisories. The current record does not establish an affected Edge version or an Edge-specific remediation threshold.The inverse assumption would also go beyond the evidence. The absence of Edge from this Chrome record should not be presented as proof that every other Chromium-derived browser is unaffected. Administrators should evaluate other browsers through the advisories and fixed versions published by their respective vendors.
For vulnerability-management purposes, maintain three distinct facts:
- CVE-2026-14425’s published affected product is Google Chrome.
- The Chrome fixed threshold is 150.0.7871.46.
- Other products require their own vendor-confirmed applicability and remediation data.
Detection Is Not a Substitute for the Fixed Version
The public record identifies a crafted HTML page as the attack input and a potential sandbox escape as the outcome. It does not provide a malicious domain, payload pattern, network signature, crash signature, or other specific indicator that can be used to identify exploitation reliably.The permission-required issue reference does not justify guessing at those missing details. It establishes restricted access to that reference, nothing more.
Security teams can continue using their normal browser and endpoint monitoring, but the published facts do not support a CVE-specific detection recipe. A clean alert dashboard also does not establish that a system running an affected Chrome version is safe.
The source-grounded, measurable control is version compliance:
- Earlier than 150.0.7871.46: affected.
- 150.0.7871.46: fixed baseline for this vulnerability.
- Later than 150.0.7871.46: outside the published affected range.
What Defenders Should Carry Forward from the ANGLE Flaw
CVE-2026-14425 presents an unusually clear operational decision despite the limited technical detail. The product is Google Chrome, the weakness is a use-after-free in ANGLE, the published delivery mechanism is a crafted HTML page, and the stated potential outcome is a sandbox escape. The affected range ends at version 150.0.7871.46.The scoring record requires more careful language. Google calls the Chromium issue High severity. CISA-ADP contributes a CVSS 3.1 vector that produces a 9.6 Critical score. NVD displays that contribution, but the 9.6 score should not be attributed to NVD as its own assessment.
The SSVC entry should be equally precise: exploitation is listed as none, automatable as no, and technical impact as total. Those values add context but do not justify predictions about exploit development, attack delivery, or future campaigns.
For individual Windows users, the final action is:
Open Chrome menu > Help > About Google Chrome, update to 150.0.7871.46 or later, select Relaunch, and reopen About Google Chrome to confirm the fixed version.
For managed Windows environments, query the fleet for Google Chrome versions below
150.0.7871.46, deploy the current approved release using the organization’s documented management process, require a relaunch, and repeat the same query. Do not consider CVE-2026-14425 remediated until the browser or the post-deployment inventory confirms Google Chrome 150.0.7871.46 or later.References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:38:12-07:00
NVD - CVE-2026-14425
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:38:12-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: thehackerwire.com
Chrome ANGLE Use-After-Free Allows Sandbox Escape (CVE-2026-14425) – TheHackerWire
Summary CVE-2026-14425 identifies a critical use-after-free (UAF) vulnerability within ANGLE, Google Chrome's graphics abstraction layer. Published on July 1...www.thehackerwire.com
