Google has fixed CVE-2026-14391, a medium-severity integer overflow in ANGLE affecting Google Chrome on Windows before version 150.0.7871.46. According to the National Vulnerability Database description, crafted HTML could allow a remote attacker to obtain potentially sensitive information from process memory, but only after the attacker had already compromised the Chrome renderer process.
That prerequisite is the central limitation on the vulnerability. CVE-2026-14391 is not described as independently causing the initial renderer compromise, and its recorded impact is information disclosure rather than code execution, data modification, or service disruption. Windows users should nevertheless move promptly to a qualifying Chrome build because the fixed-version threshold is clear and remediation is straightforward.
To check Chrome manually on Windows, open Chrome and select Menu ⋮ > Help > About Google Chrome. Confirm that the version shown is 150.0.7871.46 or later, and then click Relaunch if Chrome offers that option. After Chrome reopens, return to the same About page and verify the version again.
The Most Important Detail Is the Attack That Must Happen First
The shortest descriptions of CVE-2026-14391 call it an integer overflow in ANGLE, but that label alone does not explain the practical risk. The National Vulnerability Database says a remote attacker could use a crafted HTML page to obtain potentially sensitive information from process memory on affected Windows systems.The decisive qualification is that the attacker must already have compromised the Chrome renderer process. CVE-2026-14391 is therefore not described as the vulnerability that grants control of the renderer merely because a user encounters a malicious page. Instead, the published description places it after an earlier compromise.
That makes the issue relevant primarily as an additional capability inside a larger attack. Once an attacker has gained control in the required context, disclosure of process-memory information may help expose data that was not intended to be available to hostile web content.
The public description does not identify the exact information that could be recovered, the affected ANGLE operation, the reliability of extraction, or whether the exposed information would be equally useful on every affected Windows configuration. Those details should not be inferred from the vulnerability class alone.
The CISA-ADP assessment records high confidentiality impact, no integrity impact, and no availability impact. In practical terms, the available assessment treats unintended access to information as the security consequence of this CVE. It does not attribute file modification, persistent control, operating-system compromise, or deliberate service interruption to CVE-2026-14391 itself.
This is why a Medium rating can be appropriate without making the issue harmless. The published attack conditions constrain exploitation, but affected systems still contain a known flaw with a defined fixed-version boundary.
ANGLE Is Where the Numeric Error Occurs
ANGLE is the affected component named in the public CVE record. The available material does not establish the precise vulnerable function or provide enough technical detail to reconstruct the underlying error, so broader claims about ANGLE’s role in every Chrome graphics path would go beyond the supplied evidence.The vulnerability is associated with CWE-190, Integer Overflow or Wraparound. This weakness occurs when a numeric operation produces a result outside the representable range of the relevant data type, causing the resulting value to differ from what the program’s logic expected.
The consequence of an integer overflow depends on how the resulting value is used. A miscalculated value could affect a size, count, offset, boundary check, allocation, or another operation. The public information for CVE-2026-14391 does not disclose which of those possibilities applies, so the precise mechanism should remain unspecified.
The CVE material also associates the issue with CWE-472, External Control of Assumed-Immutable Web Parameter. That classification indicates a concern involving externally influenced web input and a value the software expected to remain stable or trustworthy. It does not, by itself, disclose the triggering parameter or establish a complete exploitation sequence.
Together, the classifications support a limited conclusion: attacker-influenced web content can reach a vulnerable condition involving numeric assumptions, and exploitation under the required circumstances can expose potentially sensitive process-memory information. They do not establish code execution, sandbox escape, or control of the Windows operating system.
The affected configuration is also specific. The NVD record identifies Google Chrome on Microsoft Windows below the fixed-version threshold. Administrators should not automatically extend that statement to every product containing ANGLE, every Chromium-derived browser, or every operating system.
| Environment | Version condition | Publicly recorded status | Practical interpretation |
|---|---|---|---|
| Google Chrome on Windows | Earlier than 150.0.7871.46 | Affected | Identify and remediate these installations |
| Google Chrome on Windows | 150.0.7871.46 or later | Meets the fixed threshold | Verify the version after relaunch |
| Chrome on other operating systems | Not identified in the stated affected configuration | Outside the documented Windows scope | Do not infer applicability without product-specific evidence |
| Other Chromium-derived browsers | Not established by this Chrome CVE record alone | Requires vendor confirmation | Check the relevant vendor’s advisory and version guidance |
What the CVSS Vector Does—and Does Not—Say
The CISA-ADP CVSS 3.1 vector is:AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N
That vector supports the following characteristics:
- Attack Vector: Network — the malicious input can be delivered remotely.
- Attack Complexity: High — successful exploitation depends on conditions beyond simply reaching the affected software.
- Privileges Required: None — the attacker does not need an authenticated or privileged account as a starting requirement under the CVSS assessment.
- User Interaction: Required — a user must interact with or encounter the relevant content.
- Scope: Unchanged — the CVSS assessment does not record a changed security authority.
- Confidentiality: High — successful exploitation can have a substantial confidentiality impact.
- Integrity: None — the assessment does not attribute data modification to this CVE.
- Availability: None — the assessment does not attribute an availability impact to this CVE.
Likewise, “user interaction required” should be interpreted narrowly. It means the assessment includes a user-dependent step; it does not, without additional technical documentation, define exactly what the user must click or how the crafted content reaches the vulnerable condition.
The unchanged-scope metric is a CVSS classification. It should not be expanded into unsupported conclusions about the precise renderer, sandbox, process, or operating-system boundaries involved in a complete attack.
The resulting score is 5.3 Medium. It is a standardized representation of the recorded technical characteristics, not a universal patch deadline. Organizations may assign additional urgency based on their exposure to untrusted web content, the sensitivity of browser sessions, and the reliability of their browser-update processes.
The Score Is CISA-ADP’s, Not NVD’s
The 5.3 Medium score shown in the record comes from CISA-ADP. It should not be described as an NVD-authored CVSS score.That distinction matters because vulnerability pages can present data contributed by multiple organizations. NVD hosts and enriches vulnerability information, while outside contributors may supply scoring or other analysis. Readers should check the attribution attached to a score rather than assuming every value displayed by NVD was calculated by NIST.
The Chrome severity label and the CISA-ADP calculation both place the issue in the Medium range. The CISA-ADP vector explains the balance: potentially serious confidentiality impact, but with High attack complexity, required user interaction, and no recorded integrity or availability impact.
CISA’s recorded Stakeholder-Specific Vulnerability Categorization data adds three operational observations:
- No known exploitation
- Not automatable
- Partial technical impact
The “not automatable” designation is also an assessment rather than a guarantee. It is consistent with the documented need for user interaction and an already-compromised renderer, but it does not establish that no attacker could automate individual stages of a larger operation.
“Partial” technical impact keeps the recorded outcome in perspective. The CVE is associated with information disclosure, not a documented total compromise of Chrome, Windows, or the device.
The practical conclusion is uncomplicated: there is no known exploitation in the supplied SSVC data, but there is also no reason to preserve a known-vulnerable Chrome installation when a clear fixed-version threshold is available.
The Public Record Provides Enough Information to Remediate
The restricted technical detail surrounding a browser vulnerability can make an advisory feel incomplete. In this case, however, defenders already have the core facts required for immediate remediation:- The affected application is Google Chrome.
- The documented platform is Microsoft Windows.
- Versions earlier than 150.0.7871.46 are affected.
- Version 150.0.7871.46 is the fixed-version threshold identified in the record.
- The affected component is ANGLE.
- The vulnerability class includes integer overflow or wraparound.
- The described outcome is disclosure of potentially sensitive process-memory information.
- Exploitation requires a previously compromised renderer process.
- The recorded SSVC data reports no known exploitation.
Similarly, the record should not be padded with an unsupported report date, publication date, reward amount, researcher attribution, release date, or count of fixes included in the surrounding Chrome release. None of those details is necessary to identify vulnerable systems or complete remediation.
Record-development timeline
Vendor/CVE information recorded — The vulnerability record identified Chrome on Windows before 150.0.7871.46 as affected and described the renderer-compromise prerequisite and potential process-memory disclosure.CISA-ADP scoring added — The record received the CVSS 3.1 vector that produces the 5.3 Medium score.
SSVC information recorded — CISA’s stakeholder-focused data reported no known exploitation, no automation, and partial technical impact.
NIST analysis added — NIST enriched the record with weakness and affected-configuration information.
This sequence describes how the public record developed without assigning unsupported dates or implying a vendor-release chronology that the available evidence does not prove. It also illustrates why defenders should distinguish among vendor information, CVE data, CISA-ADP scoring, SSVC assessments, and NIST enrichment.
Version Compliance Is the Remediation Standard
The remediation threshold is precise: Google Chrome on Windows must be at version 150.0.7871.46 or later.“Chrome 150” is not specific enough. A build carrying the same major-version number but falling below 150.0.7871.46 would not satisfy the documented threshold. Inventory and compliance rules should compare the full four-part version number.
For an individual Windows user, the concrete verification procedure is:
- Open Google Chrome.
- Select the three-dot menu ⋮ in the upper-right corner.
- Select Help.
- Select About Google Chrome.
- Confirm that the displayed version is 150.0.7871.46 or later.
- If Chrome displays a Relaunch button, click it.
- After Chrome reopens, return to Menu ⋮ > Help > About Google Chrome and confirm the qualifying version again.
Administrators should use the same fixed threshold for fleet compliance. A deployment task marked successful is useful operational data, but the security objective is the resulting application version. Systems should be re-inventoried after deployment and relaunch so the organization can identify endpoints that remain below the threshold.
This approach also handles exceptions cleanly. A device is either reporting a qualifying Chrome version or it is not. Policy intent, deployment-ring membership, package approval, and maintenance status may explain noncompliance, but they do not replace the version check.
Action checklist for administrators
- Inventory Google Chrome installations on Windows.
- Identify every installation reporting a version earlier than 150.0.7871.46.
- Deploy 150.0.7871.46 or a later qualifying build to those systems.
- Relaunch Chrome on the affected systems.
- Re-inventory the Windows Chrome population after relaunch.
- Investigate devices that still report a version below 150.0.7871.46.
- Confirm that newly provisioned or reimaged Windows systems also receive a qualifying build.
- Review unmanaged, offline, or intermittently connected endpoints that may be absent from the primary inventory.
- Continue monitoring authoritative vulnerability records for changes in exploitation status or remediation guidance.
The Threat Model Rewards Discipline Over Alarm
For a typical Windows user, the correct response is to check the installed version, install or complete the available update process, and relaunch if prompted. The current recorded evidence does not show known exploitation, and the vulnerability is not described as independently producing the initial renderer compromise.For a business, the same technical facts can justify stronger operational attention. Browsers routinely handle authenticated sessions and sensitive business information. An information-disclosure flaw may be more consequential on systems used for administration, development, finance, communications, or access to internal services, even when the flaw represents only one part of a hypothetical broader attack.
That is a risk-management judgment, not a claim that CVE-2026-14391 has been shown to steal a particular credential or compromise a particular service. The public record does not establish those outcomes.
The evidence also does not support disabling graphics acceleration across a fleet as the primary response. Without public trigger details, such a configuration change would have uncertain relevance and could create compatibility or performance consequences. The documented remediation target is a qualifying Chrome version.
Nor should organizations declare every Chromium-derived browser vulnerable solely because Chrome and ANGLE are named in this CVE. Shared technology can make related-vendor review sensible, but applicability must come from each product’s own security information or another authoritative affected-product record.
Disciplined vulnerability management is more useful than dramatic interpretation:
- Identify the documented affected population.
- Move every affected installation to the fixed threshold or later.
- Relaunch Chrome.
- Verify the resulting version.
- Recheck endpoints that fail compliance.
- Monitor for changes in the exploitation assessment.
Restricted Details Put the Emphasis on Inventory
When detailed issue information is available, defenders may be able to search for trigger patterns, crash signatures, proof-of-concept behavior, or other exploit-specific indicators. The supplied public material for CVE-2026-14391 does not provide that level of detail.That shifts the immediate defensive burden to asset and version data. Security teams should be able to answer:
- How many Windows devices have Google Chrome installed?
- Which full Chrome version does each device report?
- Which installations remain below 150.0.7871.46?
- Which devices have not reported recently?
- Which systems failed deployment or relaunch?
- Can newly built or restored systems reintroduce an older version?
- Are unmanaged Windows endpoints missing from the normal inventory?
Conversely, restricted exploit details do not prevent effective remediation when the fixed boundary is known. An endpoint reporting Chrome 150.0.7871.46 or later is on the qualifying side of the documented version threshold, regardless of whether defenders know the precise ANGLE calculation that caused the flaw.
CVE-2026-14391 also demonstrates why browser patching should be treated as a verification problem rather than an announcement problem. Knowing that a corrected build exists is only the first step. The defensible outcome is a Windows Chrome inventory showing no installations below 150.0.7871.46, followed by continued monitoring in case the exploitation status or vendor guidance changes.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:37:35-07:00
NVD - CVE-2026-14391
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:37:35-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: chromium.googlesource.com
- Related coverage: rpmfind.net
- Related coverage: linuxsecurity.com
Fedora 44 Chromium 150.0.7871.46 Critical Security Release
Chromium update in Fedora 44 fixes 433 issues including critical flaws enhancing browser security.
linuxsecurity.com
- Related coverage: security-tracker.debian.org
- Related coverage: cvefeed.io
CVE-2026-14391 - ANGLE Integer Overflow Information Disclosure
Integer overflow in ANGLE in Google Chrome on Windows prior to 150.0.7871.46 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium)cvefeed.io - Related coverage: security.snyk.io
External Control of Assumed-Immutable Web Parameter in chromium | CVE-2026-14391 | Snyk
External Control of Assumed-Immutable Web Parameter in chromium | CVE-2026-14391security.snyk.io