Google fixed CVE-2026-14398 in Chrome 150.0.7871.46. According to the National Vulnerability Database record for CVE-2026-14398, Chrome versions before 150.0.7871.46 are affected by a use-after-free vulnerability in ANGLE that could allow a remote attacker using a crafted HTML page to potentially escape the browser sandbox. The NVD record displays a CISA-ADP CVSS 3.1 score of 9.6 Critical and a CISA-ADP SSVC assessment listing exploitation as none, automatable as no, and technical impact as total. Administrators should promptly update affected installations through their approved process and close the finding only after current evidence confirms Chrome 150.0.7871.46 or later.
The record supports urgent version-based remediation, but it does not support describing CVE-2026-14398 as an actively exploited zero-day. “Exploitation: none” is a point-in-time SSVC assessment, not a guarantee that exploitation is impossible or that the status will remain unchanged.
The exact Chrome menu path, automatic update-check behavior, relaunch sequence, and post-relaunch user-interface workflow are not established by the supplied vulnerability record. Users should follow Google’s current product instructions or their organization’s approved support process rather than treating a CVE database entry as Chrome update documentation.
CVE-2026-14398 is classified as CWE-416, Use After Free, in ANGLE. A use-after-free flaw occurs when software continues to access an object or memory region after it has been released. Depending on the surrounding code and memory state, that class of error can produce a crash, unintended memory behavior, or attacker-controlled effects.
The CVE description supplies a more specific consequence: a remote attacker could use a crafted HTML page to potentially escape the browser sandbox. The word “potentially” must remain attached to that outcome. The record does not establish that sandbox escape is reliable on every affected installation or that visiting any ordinary page will trigger the vulnerability.
The documented sandbox consequence is nevertheless significant. Browser sandboxes are intended to contain untrusted web content and limit its access to resources outside the browser’s restricted security boundary. A vulnerability that may cross that boundary justifies rapid remediation even when no known exploitation is listed.
The public record does not establish that successful exploitation automatically provides administrator privileges, persistence, credential theft, endpoint-security bypass, or unrestricted control of the operating system. Those outcomes must not be added to alerts, ticket titles, or executive summaries without separate evidence.
This must be attributed precisely. CISA-ADP contributed the 9.6 score; NVD displays it. In the supplied record, NVD had not supplied its own CVSS 4.0, CVSS 3.x, or CVSS 2.0 assessment. It would therefore be inaccurate to state that “NVD scored the vulnerability 9.6” or that “NIST assigned a 9.6 rating.”
That distinction can affect vulnerability-management tools. A system that imports contributed assessments may display 9.6 Critical, while a system configured to read only an NVD-authored field may show no score. An empty NVD-native score field does not reduce the vulnerability’s documented impact or erase the contributed CISA-ADP assessment.
The score also does not measure observed attack activity. CVSS models exploit conditions and potential technical impact. It does not prove that exploit code is public, that attacks are underway, or that exploitation will work identically across all affected environments.
User interaction should not be translated into either extreme. Chrome is not compromised merely because it is installed, but processing web content is the browser’s normal purpose. The requirement for interaction is relevant context, not a reason to leave an affected browser below the fixed threshold.
Likewise, low attack complexity is a metric in the contributed vector, not proof that developing a stable exploit is trivial. The restricted technical information leaves unanswered questions about the triggering sequence, memory conditions, mitigations, and exploit reliability. None of those unknowns changes the availability of a fixed-version boundary.
“Exploitation: none” means the supplied assessment did not identify known exploitation at that point in time. It should not be expanded into a claim that CISA, Google, NIST, or NVD proved that exploitation had never occurred anywhere. It also should not be replaced with language suggesting an active campaign unless later authoritative evidence changes the status.
“Automatable: no” means CISA-ADP did not categorize the exploitation process as automatable under the SSVC framework. It does not prove that attacks cannot be scaled, that exploit delivery cannot be automated, or that every attempt would require extensive manual work.
“Technical impact: total” reflects the seriousness of the modeled successful outcome. That assessment is consistent with the contributed CVSS vector’s changed scope and high confidentiality, integrity, and availability impacts.
Together, the fields support a measured response:
The timeline also illustrates why attribution matters. A single NVD page may display a Chrome-originated vulnerability description, CISA-ADP scoring and SSVC information, and NIST analysis. The organization displaying a field is not necessarily the organization that authored that field.
For CVE-2026-14398, the defensible attribution is:
It also does not provide enough evidence to determine whether another Chromium-derived browser is affected. Microsoft Edge and other products need product-specific vendor confirmation; shared Chromium or ANGLE ancestry alone is not a complete applicability determination.
The supplied record does not establish a CVE-specific crash signature, malicious domain, file hash, network pattern, endpoint event, or other detection artifact. A browser crash on an affected version is not proof of exploitation, and the absence of a crash is not proof that an older installation was safe.
Those limitations constrain reporting and detection engineering, but they do not prevent remediation. Product and version remain the documented control points.
Similarly, the supplied facts do not establish that a successful package download, update assignment, management job, endpoint check-in, or green console status proves that Chrome has moved outside the affected range. Those signals may be useful operational evidence, but the CVE-specific closure question is whether a trustworthy current result places the installed version at or above the threshold.
“Unknown” must remain a separate state. An offline device, stale record, missing inventory result, or conflicting version report is not evidence of compliance. Every unresolved device should have an owner and a defined follow-up path rather than disappearing into a successful deployment total.
Compatibility exceptions should also remain visible. If an organization cannot immediately update an affected installation, the exception record should identify the device or group, current version, business reason, responsible owner, review date, and planned remediation path. The supplied CVE information does not identify a temporary configuration change that is equivalent to installing a version outside the affected range.
Updating Chrome removes the documented version exposure. It does not automatically explain suspicious activity that occurred before remediation, and it does not close an unrelated security incident. If an exposed endpoint also shows credible signs of compromise, responders should preserve and analyze the relevant evidence under their established procedures.
Until that evidence changes, the closure standard for CVE-2026-14398 remains direct: identify affected Chrome installations, move them outside the NVD-documented range, verify the resulting installed version, and keep every unknown or excepted device visible until it has a defensible disposition.
What Changed / What to Do Now
| Item | Verified finding |
|---|---|
| Affected product | Google Chrome |
| Affected range | Versions before 150.0.7871.46, according to the NVD record |
| Fixed threshold | Version 150.0.7871.46 or later, based on the NVD affected range |
| Weakness | CWE-416, Use After Free, in ANGLE |
| Exploit scenario | The NVD description says a remote attacker could use a crafted HTML page to potentially escape the browser sandbox |
| Severity assessment | CISA-ADP contributed a CVSS 3.1 score of 9.6 Critical; NVD displays that score but had not supplied its own assessment |
| SSVC status | CISA-ADP recorded exploitation as none, automatable as no, and technical impact as total |
| Required action | Update affected Chrome installations and verify a current installed version at or above 150.0.7871.46 |
The exact Chrome menu path, automatic update-check behavior, relaunch sequence, and post-relaunch user-interface workflow are not established by the supplied vulnerability record. Users should follow Google’s current product instructions or their organization’s approved support process rather than treating a CVE database entry as Chrome update documentation.
Chrome’s Fix Establishes the Operational Boundary
The National Vulnerability Database’s affected configuration places Google Chrome versions before 150.0.7871.46 inside the documented range. That makes 150.0.7871.46 the minimum fixed threshold supported by the supplied record. A later Chrome version also falls outside that affected range; the record does not require an organization to remain on the minimum build.CVE-2026-14398 is classified as CWE-416, Use After Free, in ANGLE. A use-after-free flaw occurs when software continues to access an object or memory region after it has been released. Depending on the surrounding code and memory state, that class of error can produce a crash, unintended memory behavior, or attacker-controlled effects.
The CVE description supplies a more specific consequence: a remote attacker could use a crafted HTML page to potentially escape the browser sandbox. The word “potentially” must remain attached to that outcome. The record does not establish that sandbox escape is reliable on every affected installation or that visiting any ordinary page will trigger the vulnerability.
The documented sandbox consequence is nevertheless significant. Browser sandboxes are intended to contain untrusted web content and limit its access to resources outside the browser’s restricted security boundary. A vulnerability that may cross that boundary justifies rapid remediation even when no known exploitation is listed.
The public record does not establish that successful exploitation automatically provides administrator privileges, persistence, credential theft, endpoint-security bypass, or unrestricted control of the operating system. Those outcomes must not be added to alerts, ticket titles, or executive summaries without separate evidence.
The 9.6 Score Comes From CISA-ADP
CISA-ADP contributed a CVSS 3.1 base score of 9.6 Critical for CVE-2026-14398. The vector shown in the supplied record is AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H.| CVSS element | Contributed value | Meaning within the assessment |
|---|---|---|
| Attack vector | Network | The modeled attack begins through remotely supplied content |
| Attack complexity | Low | The vector does not require a specialized external condition |
| Privileges required | None | The attacker does not need existing authenticated privileges |
| User interaction | Required | The victim must interact with or process the crafted content |
| Scope | Changed | The modeled result crosses a security authority or boundary |
| Confidentiality | High | Successful exploitation may have severe confidentiality impact |
| Integrity | High | Successful exploitation may have severe integrity impact |
| Availability | High | Successful exploitation may have severe availability impact |
That distinction can affect vulnerability-management tools. A system that imports contributed assessments may display 9.6 Critical, while a system configured to read only an NVD-authored field may show no score. An empty NVD-native score field does not reduce the vulnerability’s documented impact or erase the contributed CISA-ADP assessment.
The score also does not measure observed attack activity. CVSS models exploit conditions and potential technical impact. It does not prove that exploit code is public, that attacks are underway, or that exploitation will work identically across all affected environments.
User interaction should not be translated into either extreme. Chrome is not compromised merely because it is installed, but processing web content is the browser’s normal purpose. The requirement for interaction is relevant context, not a reason to leave an affected browser below the fixed threshold.
Likewise, low attack complexity is a metric in the contributed vector, not proof that developing a stable exploit is trivial. The restricted technical information leaves unanswered questions about the triggering sequence, memory conditions, mitigations, and exploit reliability. None of those unknowns changes the availability of a fixed-version boundary.
SSVC Reports No Known Exploitation and Total Technical Impact
The CISA-ADP Stakeholder-Specific Vulnerability Categorization assessment displayed in the NVD record lists:- Exploitation: None
- Automatable: No
- Technical impact: Total
“Exploitation: none” means the supplied assessment did not identify known exploitation at that point in time. It should not be expanded into a claim that CISA, Google, NIST, or NVD proved that exploitation had never occurred anywhere. It also should not be replaced with language suggesting an active campaign unless later authoritative evidence changes the status.
“Automatable: no” means CISA-ADP did not categorize the exploitation process as automatable under the SSVC framework. It does not prove that attacks cannot be scaled, that exploit delivery cannot be automated, or that every attempt would require extensive manual work.
“Technical impact: total” reflects the seriousness of the modeled successful outcome. That assessment is consistent with the contributed CVSS vector’s changed scope and high confidentiality, integrity, and availability impacts.
Together, the fields support a measured response:
- Do not claim that CVE-2026-14398 is being actively exploited.
- Do not treat “exploitation: none” as permission to delay remediation.
- Use the published fixed threshold while it is available ahead of any documented attack activity.
- Monitor the vulnerability record and authoritative vendor information for changes.
Disclosure and Response Timeline
The supplied record provides a verified dated sequence:- July 1, 2026 — NVD publication: The National Vulnerability Database published the CVE-2026-14398 record.
- July 2, 2026 — NIST initial analysis: NIST added its initial analysis to the NVD record.
- July 3, 2026 — NVD last modification: The record shows a last-modified date of July 3, 2026.
The timeline also illustrates why attribution matters. A single NVD page may display a Chrome-originated vulnerability description, CISA-ADP scoring and SSVC information, and NIST analysis. The organization displaying a field is not necessarily the organization that authored that field.
For CVE-2026-14398, the defensible attribution is:
- The record identifies Google Chrome and ANGLE in the vulnerability description.
- CISA-ADP contributed the CVSS 3.1 score and SSVC values.
- NVD displays those contributions alongside NIST’s analysis and the affected configuration.
- NVD had not supplied a separate native CVSS assessment in the supplied record.
What Is Not Known
The underlying Chromium issue is restricted, so the public record does not disclose the vulnerable ANGLE object, the exact triggering sequence, the relevant memory layout, exploit reliability, a proof of concept, or CVE-specific indicators of compromise.It also does not provide enough evidence to determine whether another Chromium-derived browser is affected. Microsoft Edge and other products need product-specific vendor confirmation; shared Chromium or ANGLE ancestry alone is not a complete applicability determination.
The supplied record does not establish a CVE-specific crash signature, malicious domain, file hash, network pattern, endpoint event, or other detection artifact. A browser crash on an affected version is not proof of exploitation, and the absence of a crash is not proof that an older installation was safe.
Those limitations constrain reporting and detection engineering, but they do not prevent remediation. Product and version remain the documented control points.
Managed-Estate Workflow
The administrator workflow can be reduced to four steps:- Identify in-scope devices on which Google Chrome is installed.
- Obtain current, trustworthy evidence of the installed Chrome version.
- Remediate every installation below 150.0.7871.46 through the organization’s approved update process.
- Recheck the version and retain affected or unknown devices in the remediation queue until compliance is confirmed.
Similarly, the supplied facts do not establish that a successful package download, update assignment, management job, endpoint check-in, or green console status proves that Chrome has moved outside the affected range. Those signals may be useful operational evidence, but the CVE-specific closure question is whether a trustworthy current result places the installed version at or above the threshold.
Closure Test
| Endpoint result | CVE-2026-14398 state | Administrator decision |
|---|---|---|
| Chrome version is below 150.0.7871.46 | Affected | Update and recheck |
| Chrome version is 150.0.7871.46 or later | Outside the documented affected range | Close after recording the evidence |
| Chrome is confirmed not installed | No Chrome installation to remediate | Record as not applicable |
| Version is missing, stale, conflicting, or unverified | Unknown | Keep open and investigate |
Compatibility exceptions should also remain visible. If an organization cannot immediately update an affected installation, the exception record should identify the device or group, current version, business reason, responsible owner, review date, and planned remediation path. The supplied CVE information does not identify a temporary configuration change that is equivalent to installing a version outside the affected range.
Detection Begins With Exposure
Because the public record contains no CVE-specific exploit indicators, the first detection task is to locate vulnerable software. Security teams should answer three questions:- Is Google Chrome installed?
- Is its current version below 150.0.7871.46?
- If the version cannot be confirmed, who owns the unresolved device?
Updating Chrome removes the documented version exposure. It does not automatically explain suspicious activity that occurred before remediation, and it does not close an unrelated security incident. If an exposed endpoint also shows credible signs of compromise, responders should preserve and analyze the relevant evidence under their established procedures.
Why Prompt Remediation Is Warranted
The prioritization decision rests on a short set of verified facts:- The affected software is a web browser that routinely processes untrusted remote content.
- The vulnerability is a use-after-free condition in ANGLE.
- The documented delivery scenario uses a crafted HTML page.
- The stated potential consequence is escape from the browser sandbox.
- The CISA-ADP vector requires no prior privileges but does require user interaction.
- CISA-ADP contributed a 9.6 Critical CVSS 3.1 score.
- CISA-ADP recorded exploitation as none, automatable as no, and technical impact as total.
- The NVD record supplies a concrete affected range and fixed threshold.
Administrator Checklist
- Identify in-scope Google Chrome installations.
- Obtain a current installed version from each in-scope device.
- Classify versions below 150.0.7871.46 as affected.
- Keep missing, stale, or conflicting results in an unknown queue.
- Remediate affected installations through the organization’s approved process.
- Collect fresh version evidence after remediation.
- Close the finding only when Chrome 150.0.7871.46 or later is confirmed.
- Record devices without Chrome as not applicable rather than compliant.
- Assign an owner and follow-up plan to every unresolved or excepted device.
- Preserve the distinction between CISA-ADP’s 9.6 score and the absence of an NVD-authored score.
- Preserve the SSVC wording: exploitation none, automatable no, technical impact total.
- Monitor authoritative records for changes to exploitation status, product scope, or remediation guidance.
Until that evidence changes, the closure standard for CVE-2026-14398 remains direct: identify affected Chrome installations, move them outside the NVD-documented range, verify the resulting installed version, and keep every unknown or excepted device visible until it has a defensible disposition.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:37:41-07:00
NVD - CVE-2026-14398
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:37:41-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: chromium.org
- Related coverage: blog.chromium.org
Chromium Blog: Chromium Graphics Overhaul
For some time now, there’s been a lot of work going on to overhaul Chromium’s graphics system. New APIs and markup like WebGL and 3D CSS tr...blog.chromium.org
- Related coverage: new.chromium.org
