CVE-2026-14418: Update Chrome to 150.0.7871.46 to Stop Data Leaks

CVE-2026-14418: What Windows users need to know
  • Affected: Google Chrome versions below 150.0.7871.46
  • Fixed: Google Chrome 150.0.7871.46 or later
  • Known impact: A remote attacker could use a crafted HTML page to leak cross-origin data
  • Exploitation status: Recorded as none in the cited CISA SSVC assessment
  • Action: Update Chrome, relaunch it, and verify the complete version number
Google has fixed CVE-2026-14418, a Chrome vulnerability classified by Chromium as High severity. The documented impact is a cross-origin data leak triggered through a crafted HTML page. The available record does not establish code execution, a sandbox escape, persistence, authentication bypass, or system takeover.
Windows users should take this action now:
  1. Open Google Chrome.
  2. Select the Chrome menu .
  3. Go to Help > About Google Chrome.
  4. Alternatively, enter chrome://settings/help in the address bar.
  5. Allow Chrome to install any available update.
  6. Click Relaunch.
  7. Return to the About Chrome page and confirm that the displayed version is 150.0.7871.46 or later.
Check the complete four-part version number. Seeing only “Chrome 150” is not sufficient to prove that the browser has reached the fixed build.

Cybersecurity illustration showing Chrome protection blocking malicious data exfiltration from an evil website.What Changed in Google Chrome​

CVE-2026-14418 affects Google Chrome versions earlier than 150.0.7871.46. The vulnerability is associated with ANGLE and is classified as CWE-457, Use of Uninitialized Variable.
Chrome’s description says a remote attacker could use a crafted HTML page to leak cross-origin data. That is the supported technical impact and should remain the center of the analysis.
The record does not identify what specific data could be exposed. It does not confirm the disclosure of passwords, cookies, authentication tokens, messages, documents, financial information, or content from any named application. It also does not establish that an attacker could read arbitrary browser or system memory.
“Cross-origin” refers to a boundary that browsers use to separate content belonging to different websites or web applications. In general terms, that separation helps prevent a page controlled by one origin from freely accessing information associated with another. CVE-2026-14418 is relevant because the documented result crosses that boundary, but the public description does not explain the precise mechanism or the kinds of information that could be recovered.
That makes this a prompt patching issue without turning it into evidence of a complete endpoint compromise.

Who Is Affected​

The affected product identified in the supplied CVE record is Google Chrome. The version threshold is direct:
Chrome versionStatus
Earlier than 150.0.7871.46Affected
150.0.7871.46 or laterOutside the stated affected range
Windows users and administrators should base remediation on the full installed Chrome version rather than the major release number alone.
The CVE record does not provide a universal test for Microsoft Edge or every other Chromium-derived browser. Shared Chromium ancestry does not mean that all related products have identical version numbers, patch schedules, or affected-code states.
Administrators should therefore keep the warning narrow:
  • Updating Microsoft Edge should not be treated as proof that a separately installed copy of Google Chrome has been updated.
  • Chrome’s fixed-version threshold should not automatically be applied to Edge or another Chromium-derived product.
  • Other browsers and applications should be evaluated through their own vendors’ advisories and version information.
The immediate confirmed action is to identify Google Chrome installations below 150.0.7871.46 and update them.

How to Verify and Fix CVE-2026-14418 on Windows​

For an individual Windows PC, use Chrome’s built-in version page:
  1. Start Chrome.
  2. Open ⋮ > Help > About Google Chrome.
  3. If preferred, navigate directly to chrome://settings/help.
  4. Wait while Chrome checks for an available update.
  5. Select Relaunch when the option appears.
  6. Reopen chrome://settings/help.
  7. Confirm that Chrome reports 150.0.7871.46 or later.
The final verification step matters. The administrative goal is not merely to initiate an update but to confirm that the browser reports a version outside the affected range.
Organizations should use their established browser-management or software-deployment tools to find Chrome installations below the cutoff. Because the supplied CVE material does not document the behavior of any particular management platform, administrators should validate results using whatever inventory and version-reporting controls their environment already trusts.
A practical verification query should distinguish among:
  • Google Chrome and other browsers
  • Stable and non-stable Chrome channels
  • Complete four-part version numbers
  • Devices that have checked in and devices whose status is unknown
  • Installed applications and copies packaged inside separately managed environments
The CVE establishes the Chrome version boundary. It does not establish equivalent boundaries for embedded frameworks, portable browsers, development builds, or third-party Chromium applications.

Severity and Exploitation Status​

CVE-2026-14418 carries two severity presentations that may initially appear inconsistent:
Assessment sourceResultOperational meaning
ChromiumHighChrome’s product-security assessment treats the vulnerability as a significant browser issue
CISA-ADP CVSS 3.14.3 MediumThe contributed vector models a network-reachable attack requiring user interaction, with low confidentiality impact and no stated integrity or availability impact
CISA SSVCExploitation: none; automatable: no; technical impact: partialThe cited assessment did not record exploitation and did not classify the attack as automatable
NVDNo NVD-authored score in the supplied recordThe absence of an NVD score is not a separate finding that the vulnerability has no risk
The contributed CVSS 3.1 assessment describes the vulnerability as network reachable, low complexity, requiring no privileges, and requiring user interaction. Its recorded impact is Low for confidentiality and None for integrity and availability.
The user-interaction requirement is consistent with the documented crafted-page scenario. It supports saying that a user must interact with attacker-controlled web content, but it does not reveal every condition required to trigger the flaw. The record does not provide a reproduction sequence or enough technical detail to describe exploit reliability.
The difference between Chromium’s High label and the 4.3 Medium score is not a reason to delay remediation. The ratings serve different purposes: Chromium provides a product-level severity judgment, while CVSS expresses a standardized set of attack and impact metrics.
The operational conclusion is more useful than debating which label should dominate:
  • The vulnerability can be reached remotely through crafted web content.
  • It does not require an attacker to begin with local or authenticated access.
  • User interaction is required.
  • The documented result is a confidentiality impact.
  • A fixed Chrome version is available.
  • The cited SSVC assessment records exploitation as none.
That profile supports timely deployment through normal browser-patching processes. It does not, by itself, support claims that an organization has been breached or that affected computers must be wiped, disconnected, or subjected to emergency credential resets.

CVSS Versus Chromium’s High Rating​

The CVSS score should not be interpreted as a complete description of Chrome’s internal security priorities. Likewise, Chromium’s High rating should not be expanded into consequences that the CVE record does not report.
The CISA-ADP vector supports the following statements:
  • The attack vector is network based.
  • Attack complexity is assessed as low.
  • No privileges are required.
  • User interaction is required.
  • Confidentiality impact is assessed as low.
  • No integrity or availability impact is recorded.
It does not support saying that the vulnerability provides remote code execution, changes browser content, destroys data, causes a persistent compromise, or grants control of Windows.
Chromium’s High rating supports prioritizing the update, but it does not override those limits. The responsible reading is that Chrome’s security team considered the flaw important within the browser while the submitted CVSS assessment describes a restricted, confidentiality-only technical impact.
This is an expedited routine update: patch promptly and verify the result, but do not present the CVE as a confirmed zero-day campaign or a complete browser takeover.

What Is Not Known Publicly​

The Chromium issue linked to CVE-2026-14418 displays Permissions Required. That establishes that public access through the linked issue is restricted.
It does not, by itself, establish why access is restricted, whether additional technical information is available elsewhere, or when the issue may become public. It also should not be used as proof that no researcher, vendor, or other party has published related analysis.
Based on the supplied record, the following details remain unconfirmed:
  • The exact data exposed by the cross-origin leak
  • The specific HTML, graphics, or browser operations needed to trigger it
  • The reliability or repeatability of the leak
  • Whether additional environmental conditions are required
  • Whether behavior differs by operating system, GPU, driver, or browser configuration
  • Whether a particular Chrome setting prevents exploitation
  • Whether the issue affects a non-Chrome Chromium product
  • Whether exploitation can be identified through a dependable network or endpoint signature
The vulnerability’s association with ANGLE does not provide enough information to fill those gaps. Without separate sourcing, reporting should not make claims about ANGLE’s expanded name, Chrome backend defaults, rendering responsibilities, Canvas2D use, or supported graphics backends.
The same restraint applies to CWE-457. The record supplies the weakness category and its name, but it does not explain how the uninitialized value behaved in this specific flaw. It would be speculative to claim that CVE-2026-14418 involved a particular memory region, control-flow effect, crash condition, or consequence beyond the documented cross-origin data leak.
No workaround should be presented as equivalent to the update unless Google identifies it as such. In particular, the supplied record does not establish that disabling hardware acceleration, blocking a specific graphics API, changing a policy, or filtering a particular page pattern removes the vulnerable path.
The reliable remediation is to move Google Chrome to version 150.0.7871.46 or later.

Disclosure and Assessment Sequence​

The supplied vulnerability information reflects several stages of assessment:
  1. Chrome supplied the CVE description, affected-version information, weakness classification, and associated references.
  2. CISA-ADP contributed a CVSS 3.1 score and SSVC assessment.
  3. NIST added normalized product and affected-version information to the NVD record.
  4. The supplied NVD information did not include an NVD-authored CVSS score.
Specific publication and modification dates should not be inferred where they have not been separately verified. The sequence is still useful because it explains why vulnerability tools may show information from several contributors rather than one unified severity decision.
Administrators should record the source of each metric when importing the CVE into internal systems. A CISA-ADP score displayed by NVD should not be mislabeled as an NVD-authored assessment, and Chromium’s severity rating should remain identified as the vendor’s product-security rating.

Administrative Checklist for Windows Fleets​

Immediate action​

  • Inventory Google Chrome across managed Windows endpoints.
  • Identify every reported version earlier than 150.0.7871.46.
  • Deploy Chrome 150.0.7871.46 or a later supported release.
  • Instruct users to open ⋮ > Help > About Google Chrome, complete the update, and click Relaunch.
  • Verify the full version after relaunch.
  • Treat devices with missing or stale inventory as unresolved rather than compliant.

Product validation​

  • Confirm that inventory results refer specifically to Google Chrome.
  • Do not assume that updating Edge also updates Chrome.
  • Do not apply Chrome’s version threshold directly to every Chromium-derived browser.
  • Check other products against their own vendors’ information.
  • Distinguish stable Chrome from beta, development, testing, or specially packaged builds.

Risk handling​

  • Prioritize systems that can access untrusted web content.
  • Use the cited exploitation status accurately: the SSVC assessment records exploitation as none.
  • Do not translate “none” into a guarantee that exploitation has never occurred or cannot occur later.
  • Do not initiate breach-response actions solely because a vulnerable Chrome version is present.
  • Escalate separately if independent endpoint, network, identity, or incident-response evidence indicates suspicious activity.

Reporting​

  • Track the full four-part Chrome version.
  • Record the date and method of verification using the organization’s normal administrative process.
  • Separate confirmed remediation from pending or unknown status.
  • Recheck systems that remain below the fixed-version threshold.
  • Keep unsupported technical assumptions out of executive and user communications.

What Users Should Be Told​

A concise user notice can avoid both alarm and ambiguity:
Google has fixed a Chrome security vulnerability that could allow a crafted webpage to leak data across website boundaries. Open Chrome, select ⋮ > Help > About Google Chrome, install the available update, and click Relaunch. Confirm that your version is 150.0.7871.46 or later.
That message gives users a direct procedure, a measurable success condition, and an accurate description of the risk. It avoids unsupported claims about stolen passwords, compromised accounts, malware installation, or control of the computer.
Users should also understand that checking Microsoft Edge does not verify Google Chrome. If both browsers are installed, each product must be checked and maintained separately.

Version State Is the Decisive Control​

CVE-2026-14418 is important because it concerns a browser-enforced separation boundary, but the public facts are narrower than many possible attack narratives. A crafted HTML page could leak cross-origin data in affected Chrome versions. The record does not specify the exposed data, demonstrate authentication bypass, or report code execution.
The fixed-version boundary provides administrators with a clear decision:
  • Below 150.0.7871.46: remediate.
  • 150.0.7871.46 or later: outside the stated affected range.
The cited SSVC assessment recorded no exploitation, so the disclosure does not call for panic or unsupported incident claims. It does call for a prompt, verifiable browser update.
Open Chrome menu ⋮ > Help > About Google Chrome, install the update, select Relaunch, and confirm 150.0.7871.46 or later. For enterprise teams, apply the same standard at fleet scale: identify the product correctly, verify the complete version, and keep unresolved devices visible until their status is confirmed.

References​

  1. Primary source: NVD / Chromium
    Published: 2026-07-11T15:38:07-07:00
  2. Security advisory: MSRC
    Published: 2026-07-11T15:38:07-07:00
    Original feed URL
  3. Related coverage: chromium.googlesource.com
  4. Related coverage: govcert.gov.hk
  5. Related coverage: windowsforum.com
 

Back
Top