Google Chrome versions earlier than 150.0.7871.46 are identified as affected by CVE-2026-14382; the supplied record uses 150.0.7871.46 as the version threshold and records no exploitation in the available CISA-ADP SSVC data. Windows users should update immediately: open Chrome, select More (three dots) > Help > About Google Chrome or enter chrome://settings/help, wait for the update check, confirm that Chrome reports 150.0.7871.46 or later, and then select Relaunch.
The vulnerability involves insufficient validation of untrusted input in ANGLE and could allow a remote attacker who has already compromised the renderer process to use a crafted HTML page to potentially escape Chrome’s sandbox. Chrome classifies the issue as High severity, while the NVD record displays a CISA-ADP CVSS 3.1 score of 9.6 Critical. Those labels come from different assessment sources, but they point to the same practical response: identify Chrome installations below the documented threshold, update them, relaunch the browser, and verify the complete installed version.
CVE-2026-14382 is described in the supplied record as insufficient validation of untrusted input in ANGLE. The description says a remote attacker who had compromised the renderer process could potentially use a crafted HTML page to perform a sandbox escape in Google Chrome versions earlier than 150.0.7871.46.
The renderer-compromise prerequisite is an important qualification. The public description does not establish that CVE-2026-14382 is, by itself, a complete webpage-to-Windows compromise. It describes a potential escape after the renderer has already been compromised, but the supplied material does not identify the separate renderer vulnerability, technique, or condition that would satisfy that prerequisite.
Even with that limitation, a potential sandbox escape warrants prompt attention because it concerns a containment boundary. The record’s wording indicates that the vulnerable behavior may allow an attacker to move beyond the security context in which compromised web content would otherwise remain constrained.
That does not prove that every visit to a crafted page results in compromise, that the flaw grants administrator privileges, or that it provides complete control of Windows. The supplied material does not include a public proof of concept, a technical root-cause analysis, a complete exploit chain, indicators of compromise, or evidence of a campaign using the vulnerability.
The restrained conclusion is still serious: the CVE record identifies a remotely reachable condition involving crafted HTML, a prerequisite renderer compromise, and a potential sandbox escape. Windows users do not need a public exploit walkthrough before checking whether their Chrome installation falls below the documented version boundary.
Users should compare all four components of the version number. Checking only that the browser reports “Chrome 150” is not precise enough because the affected boundary is the complete version 150.0.7871.46.
The displayed vector describes a network-accessible vulnerability with low attack complexity, no attacker privileges required, user interaction required, changed scope, and High potential impact to confidentiality, integrity, and availability. In operational terms, the scoring model considers the vulnerability remotely reachable and potentially capable of crossing a security boundary, while still requiring the user to interact with browser content.
User interaction should be interpreted in the context of a web browser. The public description identifies crafted HTML as the delivery mechanism, but it does not say that the user must install software, grant administrative rights, disable a security warning, or perform another specific high-friction action. Reporting should stop there rather than inventing a particular social-engineering scenario.
The High and Critical labels should also retain their provenance. Chrome’s rating is the vendor’s product classification. The 9.6 score is a CISA-ADP contribution displayed in the NVD record, not an independent CVSS calculation authored by NVD or NIST in the supplied material.
Without the underlying restricted issue details or an explicit explanation from the vendor, it would be speculative to claim exactly why Chrome’s classification and the contributed CVSS category differ. Product severity systems and standardized scoring models may weigh conditions differently. Administrators do not need to resolve that methodological difference before acting on a clear affected-version boundary.
The key wording is that the CVE record identifies Chrome versions below 150.0.7871.46 as affected. That single boundary should not be expanded into an unsupported claim that every later version is secure in all respects. It provides a direct remediation threshold for this CVE, not a permanent guarantee about Chrome releases.
The record also does not establish that the vulnerability grants administrator or SYSTEM privileges, provides persistence, bypasses endpoint security products, extracts credentials, accesses particular files, or produces a complete compromise of the device. Those outcomes should not be presented as facts without additional source-level evidence.
The CISA-ADP CVSS vector describes the issue as network-accessible and requiring user interaction, with no prior attacker privileges. Its changed-scope value is consistent with the assessment that successful exploitation could cross from one security authority into another.
The confidentiality, integrity, and availability impact fields are each rated High in the contributed vector. Those values express potential technical impact under the scoring model. They are not forensic evidence that an attacker has used CVE-2026-14382 to steal data, change systems, or disrupt affected computers.
The supplied SSVC fields add useful context:
“Automatable: no” likewise does not mean “not exploitable.” It is a decision-support value, not a technical guarantee. The public record does not explain which conditions led to that selection, so the article should not substitute a speculative list of hardware, targeting, timing, or environmental requirements.
“Technical impact: total” reflects the potential seriousness of crossing the identified boundary. It should not be restated as evidence of an observed total compromise. The supplied record describes possible technical consequences, not an incident investigation.
Taken together, these values support prompt remediation without suggesting that an active mass-exploitation emergency has been confirmed.
CISA-ADP assessment — CISA-ADP contributes the displayed CVSS 3.1 vector and 9.6 Critical score. It also supplies the SSVC selections recording exploitation as none, automatable as no, and technical impact as total.
NVD and NIST presentation — The NVD record presents vendor-originated CVE information, contributed assessment data, references, and affected-product information. A score shown on the NVD page should not automatically be described as an NVD-authored assessment when the record attributes it to CISA-ADP.
This sequence preserves the useful provenance without turning unsupported metadata or release assumptions into a precise disclosure chronology. The remediation decision does not depend on an invented rollout date. It depends on the affected product, the complete installed version, the documented threshold, and the current exploitation information in the supplied record.
For organizations, the equivalent objective is to collect reliable version evidence from every in-scope Chrome installation. A deployment action, help-desk instruction, or user notification may be part of the remediation process, but it is not by itself proof that the browser has crossed the CVE boundary.
This is a general administrative principle rather than a claim about Chrome’s updater or any particular management product. Different environments use different inventory, deployment, maintenance, and reporting systems. Administrators should consult the documentation for their supported Chrome Enterprise and endpoint-management tools before assuming that a status field represents the installed or currently observed browser version.
The evidence needed for this CVE is comparatively simple:
For the same reason, the record does not establish a CVE-specific workaround equivalent to moving Chrome beyond the affected boundary. Broad configuration changes may carry compatibility and operational costs without providing a verified mitigation for this vulnerability.
The primary response is to update Chrome, relaunch it, and verify the complete version. If an organization cannot immediately update a particular installation, any temporary restrictions should be treated as environment-specific risk controls rather than as proven substitutes for the version threshold.
Unknown status should also remain visible. An endpoint that has stopped reporting or returns an incomplete version is not demonstrated to be safe. It belongs in an unresolved queue until administrators can collect sufficient evidence.
The strong caution is a scope limitation of the supplied record: it identifies Google Chrome and provides an affected-version boundary for Chrome. It supplies no Microsoft Edge affected-version data and no affected-version matrix for other Chromium-derived browsers.
That means Chrome’s threshold must not be copied directly into an Edge, Brave, Opera, Vivaldi, or embedded-browser vulnerability ticket. A Chrome version number does not establish whether another product contains the relevant code, whether the issue is reachable in that product, or which downstream release would address it.
Shared technology can justify investigation, but it is not a substitute for product-specific applicability information. Administrators should consult each browser vendor’s own security information and deployment guidance before classifying another product as affected or remediated.
The same discipline applies when several browsers coexist on one Windows computer. Updating Chrome does not establish the status of Edge or another browser. Conversely, updating a different Chromium-derived browser does not demonstrate that Chrome has reached 150.0.7871.46.
Security teams should therefore track each installed browser as a separate product:
There is no supported basis here for describing malicious-page obfuscation, private exploit development, attacker code comparison, hardware fingerprinting, narrow GPU-state combinations, or a particular multistage chain. Such scenarios may arise in browser-security discussions generally, but this CVE record does not establish them.
The record also does not show:
The available evidence supports accelerated remediation because the affected range is explicit, the attack is described as remotely delivered through crafted HTML after renderer compromise, and the potential result crosses a browser security boundary. It supports measured communication because the supplied SSVC assessment records no exploitation and no automation.
It does not measure the number of vulnerable computers in a particular environment, the existence of public exploit code, the prevalence of attacks, or the business value of the affected endpoints. Those questions require separate inventory, threat intelligence, and risk analysis.
The SSVC contribution provides additional context by recording no exploitation, no automation, and total technical impact. That combination favors urgency without sensationalism: potentially severe consequences are identified, but the supplied data does not report active exploitation.
Chrome’s High classification does not justify postponing remediation, just as the contributed Critical score does not prove compromise is imminent. The most defensible priority decision comes from the complete record:
Administrators: Inventory every in-scope Google Chrome installation, compare the complete version with 150.0.7871.46, remediate all lower versions through supported processes, and collect fresh version evidence afterward. Keep lower, missing, stale, or conflicting results open until resolved.
Security teams: Preserve the assessment provenance. Chrome rates the issue High; CISA-ADP supplies the displayed 9.6 Critical CVSS score and the SSVC values. Do not describe the score as an independently authored NVD rating, and do not claim active exploitation when the supplied SSVC record says none.
Mixed-browser environments: Apply this boundary to Google Chrome only. The supplied record provides no affected or corrected version information for Microsoft Edge or other Chromium-derived browsers, so evaluate those products separately through their vendors.
The final test is straightforward: Google Chrome below 150.0.7871.46 remains within the documented affected range. Update, relaunch, and verify that every in-scope Chrome installation reports 150.0.7871.46 or later.
The vulnerability involves insufficient validation of untrusted input in ANGLE and could allow a remote attacker who has already compromised the renderer process to use a crafted HTML page to potentially escape Chrome’s sandbox. Chrome classifies the issue as High severity, while the NVD record displays a CISA-ADP CVSS 3.1 score of 9.6 Critical. Those labels come from different assessment sources, but they point to the same practical response: identify Chrome installations below the documented threshold, update them, relaunch the browser, and verify the complete installed version.
This Is a Potential Boundary Failure, Not Merely a Graphics Bug
CVE-2026-14382 is described in the supplied record as insufficient validation of untrusted input in ANGLE. The description says a remote attacker who had compromised the renderer process could potentially use a crafted HTML page to perform a sandbox escape in Google Chrome versions earlier than 150.0.7871.46.The renderer-compromise prerequisite is an important qualification. The public description does not establish that CVE-2026-14382 is, by itself, a complete webpage-to-Windows compromise. It describes a potential escape after the renderer has already been compromised, but the supplied material does not identify the separate renderer vulnerability, technique, or condition that would satisfy that prerequisite.
Even with that limitation, a potential sandbox escape warrants prompt attention because it concerns a containment boundary. The record’s wording indicates that the vulnerable behavior may allow an attacker to move beyond the security context in which compromised web content would otherwise remain constrained.
That does not prove that every visit to a crafted page results in compromise, that the flaw grants administrator privileges, or that it provides complete control of Windows. The supplied material does not include a public proof of concept, a technical root-cause analysis, a complete exploit chain, indicators of compromise, or evidence of a campaign using the vulnerability.
The restrained conclusion is still serious: the CVE record identifies a remotely reachable condition involving crafted HTML, a prerequisite renderer compromise, and a potential sandbox escape. Windows users do not need a public exploit walkthrough before checking whether their Chrome installation falls below the documented version boundary.
Update and Verify Chrome on Windows
The immediate user procedure is short:- Open Google Chrome.
- Select More, represented by the three-dot menu.
- Select Help > About Google Chrome.
- Alternatively, enter chrome://settings/help in the address bar.
- Wait for Chrome to complete its update check.
- Confirm that the complete version displayed is 150.0.7871.46 or later.
- Select Relaunch.
- Return to the About page after Chrome reopens and verify the complete version again.
Users should compare all four components of the version number. Checking only that the browser reports “Chrome 150” is not precise enough because the affected boundary is the complete version 150.0.7871.46.
Chrome’s “High” and CISA-ADP’s “Critical” Come From Different Assessments
The most conspicuous detail in the record is the severity difference. Chrome classifies CVE-2026-14382 as High, while the CISA-ADP contribution displayed by NVD assigns a CVSS 3.1 base score of 9.6, which falls in the Critical range.The displayed vector describes a network-accessible vulnerability with low attack complexity, no attacker privileges required, user interaction required, changed scope, and High potential impact to confidentiality, integrity, and availability. In operational terms, the scoring model considers the vulnerability remotely reachable and potentially capable of crossing a security boundary, while still requiring the user to interact with browser content.
User interaction should be interpreted in the context of a web browser. The public description identifies crafted HTML as the delivery mechanism, but it does not say that the user must install software, grant administrative rights, disable a security warning, or perform another specific high-friction action. Reporting should stop there rather than inventing a particular social-engineering scenario.
The High and Critical labels should also retain their provenance. Chrome’s rating is the vendor’s product classification. The 9.6 score is a CISA-ADP contribution displayed in the NVD record, not an independent CVSS calculation authored by NVD or NIST in the supplied material.
Without the underlying restricted issue details or an explicit explanation from the vendor, it would be speculative to claim exactly why Chrome’s classification and the contributed CVSS category differ. Product severity systems and standardized scoring models may weigh conditions differently. Administrators do not need to resolve that methodological difference before acting on a clear affected-version boundary.
| Chrome version state | What the supplied CVE record says | Practical interpretation |
|---|---|---|
| Earlier than 150.0.7871.46 | Identified as affected | Keep the installation in the remediation queue |
| 150.0.7871.46 | Version threshold identified by the record | Update, relaunch, and verify that the browser reports at least this complete version |
| Later than 150.0.7871.46 | Outside the record’s stated “earlier than” affected boundary | The CVE record does not identify these versions as affected, but it is not a universal assurance about every later Chrome build or every browser vulnerability |
| Missing, incomplete, or conflicting version result | Status cannot be determined | Treat the installation as unresolved until a complete version is collected |
What the Public Description Establishes
The supplied record supports several concrete findings:- The affected product is identified as Google Chrome.
- The affected component is identified as ANGLE.
- The weakness is described as insufficient validation of untrusted input.
- The record associates the vulnerability with improper input validation.
- The attack description involves crafted HTML.
- The description includes a prerequisite renderer compromise.
- The potential result is a Chrome sandbox escape.
- Versions earlier than 150.0.7871.46 are identified as affected.
- Chrome classifies the vulnerability as High.
- CISA-ADP contributes a CVSS 3.1 score of 9.6 Critical.
- The supplied CISA-ADP SSVC data records exploitation as none.
- The SSVC data records automatable as no and technical impact as total.
- The linked underlying issue is not publicly accessible in the supplied material.
The record also does not establish that the vulnerability grants administrator or SYSTEM privileges, provides persistence, bypasses endpoint security products, extracts credentials, accesses particular files, or produces a complete compromise of the device. Those outcomes should not be presented as facts without additional source-level evidence.
A Crafted Page Places the Issue in Chrome’s Normal Input Path
The attack description centers on a crafted HTML page. That makes ordinary browser content the documented delivery path, although the record also says the attacker must already have compromised the renderer process.The CISA-ADP CVSS vector describes the issue as network-accessible and requiring user interaction, with no prior attacker privileges. Its changed-scope value is consistent with the assessment that successful exploitation could cross from one security authority into another.
The confidentiality, integrity, and availability impact fields are each rated High in the contributed vector. Those values express potential technical impact under the scoring model. They are not forensic evidence that an attacker has used CVE-2026-14382 to steal data, change systems, or disrupt affected computers.
The supplied SSVC fields add useful context:
- Exploitation: none
- Automatable: no
- Technical impact: total
“Automatable: no” likewise does not mean “not exploitable.” It is a decision-support value, not a technical guarantee. The public record does not explain which conditions led to that selection, so the article should not substitute a speculative list of hardware, targeting, timing, or environmental requirements.
“Technical impact: total” reflects the potential seriousness of crossing the identified boundary. It should not be restated as evidence of an observed total compromise. The supplied record describes possible technical consequences, not an incident investigation.
Taken together, these values support prompt remediation without suggesting that an active mass-exploitation emergency has been confirmed.
Record Timeline Without Unsupported Rollout Dates
The supplied material shows that the public vulnerability record contains information and assessments from multiple sources. It does not provide adequate support for the previously stated June rollout dates or for specific July publication and enrichment events, so those calendar claims should not be repeated.Timeline
Chrome-originated vulnerability information — The record identifies Google Chrome, ANGLE, insufficient validation of untrusted input, crafted HTML, the renderer-compromise prerequisite, the potential sandbox escape, Chrome’s High classification, and the affected boundary below 150.0.7871.46.CISA-ADP assessment — CISA-ADP contributes the displayed CVSS 3.1 vector and 9.6 Critical score. It also supplies the SSVC selections recording exploitation as none, automatable as no, and technical impact as total.
NVD and NIST presentation — The NVD record presents vendor-originated CVE information, contributed assessment data, references, and affected-product information. A score shown on the NVD page should not automatically be described as an NVD-authored assessment when the record attributes it to CISA-ADP.
This sequence preserves the useful provenance without turning unsupported metadata or release assumptions into a precise disclosure chronology. The remediation decision does not depend on an invented rollout date. It depends on the affected product, the complete installed version, the documented threshold, and the current exploitation information in the supplied record.
The Affected Boundary Must Be Verified, Not Assumed
For individual users, the About Chrome screen provides a direct way to observe the browser’s complete version after the update and relaunch procedure.For organizations, the equivalent objective is to collect reliable version evidence from every in-scope Chrome installation. A deployment action, help-desk instruction, or user notification may be part of the remediation process, but it is not by itself proof that the browser has crossed the CVE boundary.
This is a general administrative principle rather than a claim about Chrome’s updater or any particular management product. Different environments use different inventory, deployment, maintenance, and reporting systems. Administrators should consult the documentation for their supported Chrome Enterprise and endpoint-management tools before assuming that a status field represents the installed or currently observed browser version.
The evidence needed for this CVE is comparatively simple:
- The device is in scope.
- Google Chrome is installed.
- The complete four-part version has been collected.
- The observed version is compared with 150.0.7871.46.
- A fresh observation is collected after remediation.
- Any installation still below the threshold remains open.
- Any missing or conflicting result remains unresolved.
Action checklist for administrators
- Inventory Google Chrome across managed Windows endpoints.
- Collect the complete four-part Chrome version rather than only the major release.
- Flag every installation below 150.0.7871.46 as affected.
- Treat missing, stale, incomplete, or conflicting version results as unresolved.
- Deploy a current approved Chrome release through the organization’s supported management process.
- Include Google’s documented About Google Chrome and Relaunch steps in user-facing instructions where appropriate.
- Collect fresh version evidence after remediation.
- Keep every installation below 150.0.7871.46 in the remediation queue.
- Investigate endpoints that cannot be inventoried or verified.
- Record the observed post-remediation version and the time it was collected.
- Evaluate Microsoft Edge and other browsers separately through their respective vendors.
- Monitor authoritative Chrome, NVD, CISA, and browser-vendor information for changes in exploitation status or affected-product scope.
Do Not Substitute Speculative Workarounds for the Version Threshold
The supplied record does not identify the precise invalid input, graphics feature, operating-system interaction, configuration dependency, or triggering condition. It therefore does not provide a sound basis for declaring that a particular GPU, graphics driver, Chrome policy, Windows release, hardware configuration, or browsing pattern prevents exploitation.For the same reason, the record does not establish a CVE-specific workaround equivalent to moving Chrome beyond the affected boundary. Broad configuration changes may carry compatibility and operational costs without providing a verified mitigation for this vulnerability.
The primary response is to update Chrome, relaunch it, and verify the complete version. If an organization cannot immediately update a particular installation, any temporary restrictions should be treated as environment-specific risk controls rather than as proven substitutes for the version threshold.
Unknown status should also remain visible. An endpoint that has stopped reporting or returns an incomplete version is not demonstrated to be safe. It belongs in an unresolved queue until administrators can collect sufficient evidence.
Other Chromium Browsers Are Outside the Supplied Record’s Confirmed Scope
Windows fleets commonly contain more than one Chromium-derived browser, so CVE-2026-14382 naturally raises questions about Microsoft Edge and other products.The strong caution is a scope limitation of the supplied record: it identifies Google Chrome and provides an affected-version boundary for Chrome. It supplies no Microsoft Edge affected-version data and no affected-version matrix for other Chromium-derived browsers.
That means Chrome’s threshold must not be copied directly into an Edge, Brave, Opera, Vivaldi, or embedded-browser vulnerability ticket. A Chrome version number does not establish whether another product contains the relevant code, whether the issue is reachable in that product, or which downstream release would address it.
Shared technology can justify investigation, but it is not a substitute for product-specific applicability information. Administrators should consult each browser vendor’s own security information and deployment guidance before classifying another product as affected or remediated.
The same discipline applies when several browsers coexist on one Windows computer. Updating Chrome does not establish the status of Edge or another browser. Conversely, updating a different Chromium-derived browser does not demonstrate that Chrome has reached 150.0.7871.46.
Security teams should therefore track each installed browser as a separate product:
- Identify the vendor and product.
- Obtain that vendor’s affected-version information.
- Apply the version boundary only to the product for which it was published.
- Verify the complete installed version independently.
- Keep unknown applicability open rather than assuming shared exposure or shared remediation.
Restricted Details Limit Analysis, Not Remediation
The underlying issue is not publicly accessible in the supplied material, so defenders do not have a detailed root-cause analysis or public trigger description. That limits what can responsibly be said about exploitability.There is no supported basis here for describing malicious-page obfuscation, private exploit development, attacker code comparison, hardware fingerprinting, narrow GPU-state combinations, or a particular multistage chain. Such scenarios may arise in browser-security discussions generally, but this CVE record does not establish them.
The record also does not show:
- A public proof of concept.
- A complete renderer exploit paired with the sandbox escape.
- A confirmed attack campaign.
- CVE-specific indicators of compromise.
- A particular Windows privilege level after exploitation.
- A persistence method.
- A reliable detection signature.
- A product configuration proven to neutralize the flaw.
- Applicability to Microsoft Edge or every Chromium-based browser.
- A separate corrected version for any downstream browser.
- The date on which every Chrome user or managed channel received a qualifying release.
The available evidence supports accelerated remediation because the affected range is explicit, the attack is described as remotely delivered through crafted HTML after renderer compromise, and the potential result crosses a browser security boundary. It supports measured communication because the supplied SSVC assessment records no exploitation and no automation.
The Score Is a Prioritization Signal, Not an Incident Report
A CVSS score is useful for sorting vulnerability work, but it does not report whether an organization has been attacked. The 9.6 CISA-ADP score describes technical characteristics and potential impact under the selected vector.It does not measure the number of vulnerable computers in a particular environment, the existence of public exploit code, the prevalence of attacks, or the business value of the affected endpoints. Those questions require separate inventory, threat intelligence, and risk analysis.
The SSVC contribution provides additional context by recording no exploitation, no automation, and total technical impact. That combination favors urgency without sensationalism: potentially severe consequences are identified, but the supplied data does not report active exploitation.
Chrome’s High classification does not justify postponing remediation, just as the contributed Critical score does not prove compromise is imminent. The most defensible priority decision comes from the complete record:
- Chrome is an internet-facing application that processes untrusted content.
- The issue is reachable through crafted HTML after a prerequisite renderer compromise.
- The potential result is a sandbox escape.
- The affected boundary is explicit.
- A version-check and relaunch procedure is available.
- The supplied SSVC data does not record exploitation.
- The record does not provide a complete exploit chain or evidence of attacks.
What to Do Now
Windows users: Open Chrome and select More > Help > About Google Chrome, or enter chrome://settings/help. Wait for the update check, confirm 150.0.7871.46 or later, select Relaunch, and verify the version again after Chrome reopens.Administrators: Inventory every in-scope Google Chrome installation, compare the complete version with 150.0.7871.46, remediate all lower versions through supported processes, and collect fresh version evidence afterward. Keep lower, missing, stale, or conflicting results open until resolved.
Security teams: Preserve the assessment provenance. Chrome rates the issue High; CISA-ADP supplies the displayed 9.6 Critical CVSS score and the SSVC values. Do not describe the score as an independently authored NVD rating, and do not claim active exploitation when the supplied SSVC record says none.
Mixed-browser environments: Apply this boundary to Google Chrome only. The supplied record provides no affected or corrected version information for Microsoft Edge or other Chromium-derived browsers, so evaluate those products separately through their vendors.
The final test is straightforward: Google Chrome below 150.0.7871.46 remains within the documented affected range. Update, relaunch, and verify that every in-scope Chrome installation reports 150.0.7871.46 or later.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:41:37-07:00
NVD - CVE-2026-14382
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:41:37-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: chromium.googlesource.com
- Related coverage: cvefeed.io
CVE-2026-14382 - ANGLE Sandbox Escape
Insufficient validation of untrusted input in ANGLE in Google Chrome prior to 150.0.7871.46 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)cvefeed.io - Related coverage: windowsforum.com
Chrome 150 Fixes Critical ANGLE Sandbox Escape (CVE-2026-13780) | Windows Forum
Google patched CVE-2026-13780 in Chrome 150.0.7871.47 for Windows and macOS after disclosing on June 30, 2026, that insufficient validation in ANGLE could...windowsforum.com