Google Chrome versions before 150.0.7871.46 are affected by CVE-2026-14386, a High-severity out-of-bounds read associated with ANGLE. The Chrome-sourced vulnerability record says a remote attacker could use a crafted HTML page to potentially obtain sensitive information from process memory. The supplied CISA-ADP SSVC data records no known exploitation, but affected Windows systems should still be updated and Chrome relaunched.
Do this now on Windows: Open Chrome, select the three-dot menu (⋮) > Help > About Google Chrome, and confirm that the displayed version is 150.0.7871.46 or later. Allow Chrome to update if necessary, then click Relaunch if that option appears. Checking the version after relaunch is the clearest way to verify that the browser is no longer below the affected-version threshold.
CVE-2026-14386 is classified as CWE-125, Out-of-bounds Read, in ANGLE. According to the Chrome-sourced description published through the National Vulnerability Database, a remote attacker could trigger the condition through a crafted HTML page and potentially retrieve sensitive information from process memory.
The available CVSS vector describes a network-accessible issue with low attack complexity, no privileges required, and user interaction required. In practical terms, the victim must interact with malicious web content, such as by visiting a crafted page. The supplied record does not say that the attacker must first obtain a local account, install an extension, or persuade the victim to approve administrative privileges.
The record does not identify the exact browser feature, internal function, or process involved. It also does not establish what specific information could be disclosed, how reliably it could be recovered, or whether an attacker could select particular data to read. Those details should not be inferred from the weakness category alone.
An out-of-bounds read generally means that software accesses data beyond an intended memory boundary. That provides useful context for understanding the vulnerability class, but it does not prove that CVE-2026-14386 exposes passwords, cookies, encryption keys, arbitrary system memory, or data belonging to other applications.
The supported conclusion is narrower: a crafted HTML page could potentially expose sensitive information from process memory in affected Chrome versions.
That does not independently explain the underlying patch mechanics. It does, however, provide administrators and users with a direct compliance test.
Do not rely solely on seeing “Chrome 150” in an application list or software report. The full version matters. A system running an earlier 150.0.7871.x build remains below the stated threshold.
The browser’s own About page provides an immediately available check:
The CISA-ADP vector is:
That vector describes network reachability, low attack complexity, no required privileges, required user interaction, unchanged scope, High confidentiality impact, and no stated integrity or availability impact.
The CVSS score reflects the documented confidentiality consequence and the absence of identified integrity or availability effects. The public description does not characterize CVE-2026-14386 as an independent arbitrary-code-execution, system-takeover, file-modification, or denial-of-service vulnerability.
NVD had not provided its own CVSS 3.x, CVSS 4.0, or CVSS 2.0 assessment in the supplied record. The displayed 6.5 score came from CISA-ADP, not from an independent NVD scoring decision.
The accurate summary is therefore:
Vulnerable is not the same as exploited. A device below the version threshold contains the documented weakness. That fact alone does not demonstrate that malicious activity occurred on the device.
The reason for that access restriction is not established by the supplied record and should not be inferred. Likewise, the restricted issue does not prove that public proof-of-concept code, exploit signatures, or independent research do or do not exist elsewhere.
For defenders, the practical result is that the affected-version boundary remains the strongest public remediation test. The record does not support claims that disabling a particular Chrome feature, changing a graphics setting, blocking a specific file type, or applying another configuration change fully prevents exploitation.
Advice based only on the issue’s association with ANGLE would be speculative unless Google or another authoritative source documents the configuration as a mitigation. Administrators should therefore avoid treating adjacent settings as substitutes for reaching the stated version threshold.
If an organization cannot update immediately, it may choose temporary risk-reduction measures under its own security policy. Those measures should not be recorded as remediation of CVE-2026-14386 unless authoritative guidance establishes that they block the vulnerable path.
The exploitation value means that the supplied decision record did not identify known exploitation. It is not proof that exploitation is impossible, and it should not be converted into a permanent all-clear.
The “automatable: no” value should also retain its SSVC attribution. It does not justify a broader claim that malicious delivery could never be automated or that the issue could affect only individually selected targets. It is a field within a particular prioritization framework, not a complete prediction of all future attack methods.
The CVSS user-interaction requirement provides the more direct operational description: the target must interact with malicious content. In this case, the vulnerability description identifies that content as a crafted HTML page.
Taken together, the record supports a measured response. There is no known exploitation recorded in the supplied SSVC data, but the issue is remotely reachable, requires no prior privileges, has low attack complexity under the supplied CVSS assessment, and carries a potential High confidentiality impact. Updating and relaunching Chrome is warranted without portraying the issue as a confirmed zero-day campaign.
Administrators evaluating different security products should compare their results against that complete version boundary. A dashboard label or severity score is secondary to determining whether the installed and relaunched browser remains below 150.0.7871.46.
That means the Chrome record alone cannot establish that those browsers are affected. It also cannot establish that they are unaffected. Each browser vendor may publish its own advisory, release information, and version boundary.
Administrators should evaluate each deployed browser against guidance from its own vendor. Chrome’s version number should not be compared directly with the version number of another browser as though the products shared an identical release scheme.
The supported conclusion remains deliberately narrow:
An incident-response team reviewing an affected endpoint should first record the complete Chrome version and determine whether the browser was below the threshold during the period under investigation. The team should then preserve and review the evidence normally collected under the organization’s incident-response procedures, including relevant endpoint, browser, proxy, DNS, identity, and network records where those sources are available and appropriate.
The supplied vulnerability material does not provide a vulnerability-specific exploit signature, malicious domain list, file hash, event ID, or other indicator that can conclusively identify an attempted or successful attack. Responders should not invent such indicators or assume that every browser crash, graphics error, or suspicious webpage represents CVE-2026-14386.
Similarly, the absence of a known indicator should not be presented as proof that exploitation did not occur. The public record does not describe what exploitation evidence would necessarily remain on a target.
A concise response sequence is appropriate:
Open Chrome and go to ⋮ > Help > About Google Chrome. Confirm 150.0.7871.46 or later, click Relaunch if offered, and verify the version again afterward. Managed environments should identify and remediate every device whose complete Chrome version remains below that threshold.
Chromium rates the vulnerability High. CISA-ADP supplied a CVSS 3.1 score of 6.5 Medium, while NVD had not supplied its own CVSS assessment in the available record. The supplied SSVC data records no known exploitation, but that status should be monitored rather than treated as a guarantee.
The forward-looking task is equally simple: maintain reliable visibility into complete browser versions, make relaunch part of update verification, and reassess the issue if Chrome, CISA, or NVD publishes new information. Until then, the defensible conclusion is narrow and actionable—Chrome before 150.0.7871.46 is affected; update it, relaunch it, and confirm the running version.
Do this now on Windows: Open Chrome, select the three-dot menu (⋮) > Help > About Google Chrome, and confirm that the displayed version is 150.0.7871.46 or later. Allow Chrome to update if necessary, then click Relaunch if that option appears. Checking the version after relaunch is the clearest way to verify that the browser is no longer below the affected-version threshold.
A Crafted Web Page Can Trigger the Issue
CVE-2026-14386 is classified as CWE-125, Out-of-bounds Read, in ANGLE. According to the Chrome-sourced description published through the National Vulnerability Database, a remote attacker could trigger the condition through a crafted HTML page and potentially retrieve sensitive information from process memory.The available CVSS vector describes a network-accessible issue with low attack complexity, no privileges required, and user interaction required. In practical terms, the victim must interact with malicious web content, such as by visiting a crafted page. The supplied record does not say that the attacker must first obtain a local account, install an extension, or persuade the victim to approve administrative privileges.
The record does not identify the exact browser feature, internal function, or process involved. It also does not establish what specific information could be disclosed, how reliably it could be recovered, or whether an attacker could select particular data to read. Those details should not be inferred from the weakness category alone.
An out-of-bounds read generally means that software accesses data beyond an intended memory boundary. That provides useful context for understanding the vulnerability class, but it does not prove that CVE-2026-14386 exposes passwords, cookies, encryption keys, arbitrary system memory, or data belonging to other applications.
The supported conclusion is narrower: a crafted HTML page could potentially expose sensitive information from process memory in affected Chrome versions.
The Version Boundary Is the Essential Test
The affected-version rule is clear: Google Chrome releases before 150.0.7871.46 are affected. Version 150.0.7871.46 is the threshold identified by the record, and NIST’s initial product analysis uses the same boundary.That does not independently explain the underlying patch mechanics. It does, however, provide administrators and users with a direct compliance test.
| Chrome state | Version boundary | Status under the supplied record | Required action |
|---|---|---|---|
| Older installation | Before 150.0.7871.46 | Affected | Update Chrome and relaunch it |
| Threshold or later | 150.0.7871.46 or later | Outside the stated affected range | Confirm the displayed version after relaunch |
| Version unknown | Not verified | Exposure cannot be ruled out | Check ⋮ > Help > About Google Chrome |
The browser’s own About page provides an immediately available check:
- Open Google Chrome.
- Select the three-dot menu (⋮).
- Select Help.
- Select About Google Chrome.
- Confirm that the version is 150.0.7871.46 or later.
- If Chrome offers a Relaunch button, select it.
- Return to About Google Chrome after relaunch and verify the displayed version again.
Windows action box
- Verify: Open Chrome (⋮) > Help > About Google Chrome.
- Required version: Confirm 150.0.7871.46 or later.
- Complete the update: Click Relaunch if offered.
- Verify again: Reopen the About page and check the complete version.
- For administrators: Identify managed Windows devices reporting a full Chrome version below 150.0.7871.46, remediate them, and repeat inventory after users or administrators have relaunched the browser.
“High” and “6.5 Medium” Are Different Attributed Assessments
Chromium assigns CVE-2026-14386 a severity of High. Separately, CISA-ADP supplied a CVSS 3.1 score of 6.5, which falls in the Medium range.The CISA-ADP vector is:
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:NThat vector describes network reachability, low attack complexity, no required privileges, required user interaction, unchanged scope, High confidentiality impact, and no stated integrity or availability impact.
The CVSS score reflects the documented confidentiality consequence and the absence of identified integrity or availability effects. The public description does not characterize CVE-2026-14386 as an independent arbitrary-code-execution, system-takeover, file-modification, or denial-of-service vulnerability.
NVD had not provided its own CVSS 3.x, CVSS 4.0, or CVSS 2.0 assessment in the supplied record. The displayed 6.5 score came from CISA-ADP, not from an independent NVD scoring decision.
The accurate summary is therefore:
- Chromium severity: High.
- CISA-ADP CVSS 3.1: 6.5 Medium.
- NVD CVSS assessment: Not supplied in the available record.
What the Record Does—and Does Not—Establish
The public material supports several direct findings:- The affected product named in the record is Google Chrome.
- Versions before 150.0.7871.46 are affected.
- The weakness is categorized as an out-of-bounds read in ANGLE.
- A remote attacker could use a crafted HTML page to potentially obtain sensitive information from process memory.
- The attack vector is network-based.
- The CVSS assessment requires user interaction and no prior privileges.
- Chromium assigned High severity.
- CISA-ADP supplied a CVSS 3.1 score of 6.5 Medium.
- The supplied SSVC data records exploitation as none.
- The associated Chromium issue is permission-restricted.
- The precise web feature or graphics operation needed to trigger the issue.
- The specific process in which the disclosure occurs.
- The exact contents that could be exposed.
- Reliable access to arbitrary memory.
- Code execution, sandbox escape, privilege escalation, or complete Windows compromise.
- A demonstrated exploit chain.
- Exploitation of the vulnerability in the wild.
- The status of browsers other than Google Chrome.
- A configuration-based workaround that is equivalent to updating.
Vulnerable is not the same as exploited. A device below the version threshold contains the documented weakness. That fact alone does not demonstrate that malicious activity occurred on the device.
The Restricted Chromium Issue Limits Technical Conclusions
The Chromium issue associated with CVE-2026-14386 requires permission to access. As a result, the supplied public material does not provide implementation-level details such as reproduction steps, the affected function, or a complete technical explanation of the memory boundary error.The reason for that access restriction is not established by the supplied record and should not be inferred. Likewise, the restricted issue does not prove that public proof-of-concept code, exploit signatures, or independent research do or do not exist elsewhere.
For defenders, the practical result is that the affected-version boundary remains the strongest public remediation test. The record does not support claims that disabling a particular Chrome feature, changing a graphics setting, blocking a specific file type, or applying another configuration change fully prevents exploitation.
Advice based only on the issue’s association with ANGLE would be speculative unless Google or another authoritative source documents the configuration as a mitigation. Administrators should therefore avoid treating adjacent settings as substitutes for reaching the stated version threshold.
If an organization cannot update immediately, it may choose temporary risk-reduction measures under its own security policy. Those measures should not be recorded as remediation of CVE-2026-14386 unless authoritative guidance establishes that they block the vulnerable path.
CISA’s SSVC Record Shows No Known Exploitation
The supplied CISA-ADP SSVC data marks exploitation as none, automatable as no, and technical impact as partial.The exploitation value means that the supplied decision record did not identify known exploitation. It is not proof that exploitation is impossible, and it should not be converted into a permanent all-clear.
The “automatable: no” value should also retain its SSVC attribution. It does not justify a broader claim that malicious delivery could never be automated or that the issue could affect only individually selected targets. It is a field within a particular prioritization framework, not a complete prediction of all future attack methods.
The CVSS user-interaction requirement provides the more direct operational description: the target must interact with malicious content. In this case, the vulnerability description identifies that content as a crafted HTML page.
Taken together, the record supports a measured response. There is no known exploitation recorded in the supplied SSVC data, but the issue is remotely reachable, requires no prior privileges, has low attack complexity under the supplied CVSS assessment, and carries a potential High confidentiality impact. Updating and relaunching Chrome is warranted without portraying the issue as a confirmed zero-day campaign.
Record Development
The available vulnerability entry was assembled through several contributors rather than appearing as a single, final assessment.Record sequence
- Chrome supplied the vulnerability description, weakness classification, affected-product information, and references.
- CISA-ADP contributed the CVSS 3.1 vector, score, and SSVC decision data.
- NIST’s initial analysis added a Chrome product configuration using 150.0.7871.46 as the affected-version boundary.
- NVD had not supplied its own CVSS 3.x, 4.0, or 2.0 assessment in the provided material.
Administrators evaluating different security products should compare their results against that complete version boundary. A dashboard label or severity score is secondary to determining whether the installed and relaunched browser remains below 150.0.7871.46.
Do Not Automatically Extend the Finding to Other Chromium Browsers
This vulnerability record names Google Chrome. It does not provide affected-version ranges for Microsoft Edge, Brave, Opera, or other products that may use Chromium components.That means the Chrome record alone cannot establish that those browsers are affected. It also cannot establish that they are unaffected. Each browser vendor may publish its own advisory, release information, and version boundary.
Administrators should evaluate each deployed browser against guidance from its own vendor. Chrome’s version number should not be compared directly with the version number of another browser as though the products shared an identical release scheme.
The supported conclusion remains deliberately narrow:
Any claim about another browser requires evidence from that browser’s vendor or another authoritative product-specific record.
Incident Response: Separate Exposure From Evidence of Attack
Finding Chrome below 150.0.7871.46 on a Windows endpoint establishes exposure to the documented vulnerability. It does not establish exploitation or compromise.An incident-response team reviewing an affected endpoint should first record the complete Chrome version and determine whether the browser was below the threshold during the period under investigation. The team should then preserve and review the evidence normally collected under the organization’s incident-response procedures, including relevant endpoint, browser, proxy, DNS, identity, and network records where those sources are available and appropriate.
The supplied vulnerability material does not provide a vulnerability-specific exploit signature, malicious domain list, file hash, event ID, or other indicator that can conclusively identify an attempted or successful attack. Responders should not invent such indicators or assume that every browser crash, graphics error, or suspicious webpage represents CVE-2026-14386.
Similarly, the absence of a known indicator should not be presented as proof that exploitation did not occur. The public record does not describe what exploitation evidence would necessarily remain on a target.
A concise response sequence is appropriate:
- Verify the endpoint’s full Chrome version.
- Update to 150.0.7871.46 or later and relaunch Chrome.
- Confirm the version again after relaunch.
- Determine when the endpoint was below the threshold.
- Review available security telemetry for suspicious browsing or related activity during that period.
- Escalate only when the evidence supports a broader incident, rather than treating version exposure alone as proof of compromise.
- Document affected devices, completed remediation, unresolved inventory gaps, and any evidence requiring further investigation.
Administrator Checklist
| Task | Exact result to obtain |
|---|---|
| Check a Windows workstation | Open Chrome (⋮) > Help > About Google Chrome |
| Verify remediation | Confirm 150.0.7871.46 or later |
| Complete activation | Click Relaunch if offered |
| Validate after restart | Reopen the About page and confirm the complete version |
| Review managed devices | Identify full Chrome versions below 150.0.7871.46 using the organization’s established inventory |
| Close the deployment loop | Repeat inventory after relaunch and investigate devices still below the threshold |
| Handle suspected incidents | Treat an old version as evidence of exposure, not automatic proof of exploitation |
| Track changing risk | Monitor authoritative Chrome, CISA, and NVD information for updated exploitation or remediation guidance |
The Immediate Answer Is Still the Most Important One
CVE-2026-14386 does not need speculative exploit chains or unsupported architectural detail to justify action. The record already supplies a clear affected-version boundary and a straightforward Windows verification procedure.Open Chrome and go to ⋮ > Help > About Google Chrome. Confirm 150.0.7871.46 or later, click Relaunch if offered, and verify the version again afterward. Managed environments should identify and remediate every device whose complete Chrome version remains below that threshold.
Chromium rates the vulnerability High. CISA-ADP supplied a CVSS 3.1 score of 6.5 Medium, while NVD had not supplied its own CVSS assessment in the available record. The supplied SSVC data records no known exploitation, but that status should be monitored rather than treated as a guarantee.
The forward-looking task is equally simple: maintain reliable visibility into complete browser versions, make relaunch part of update verification, and reassess the issue if Chrome, CISA, or NVD publishes new information. Until then, the defensible conclusion is narrow and actionable—Chrome before 150.0.7871.46 is affected; update it, relaunch it, and confirm the running version.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:39:52-07:00
Loading…
nvd.nist.gov - Security advisory: MSRC
Published: 2026-07-11T15:39:52-07:00
Original feed URL
Loading…
msrc.microsoft.com - Official source: github.com
Loading…
github.com - Related coverage: chromium.org
Loading…
www.chromium.org - Related coverage: blog.chromium.org
Chromium Blog: Introducing the ANGLE Project
We're happy to announce a new open source project called Almost Native Graphics Layer Engine, or ANGLE for short. The goal of ANGLE is to la...blog.chromium.org
- Related coverage: developer.chrome.com
RenderingNG architecture | Chromium | Chrome for Developers
Learn the components of the RenderingNG architecture, and how the rendering pipeline flows through them.
developer.chrome.com
- Related coverage: khronos.org
Loading…
www.khronos.org - Related coverage: new.chromium.org
GPU Architecture Roadmap
new.chromium.org