Google Chrome versions before 150.0.7871.46 are affected by CVE-2026-14430, a High-severity integer overflow in the V8 JavaScript engine. According to the supplied vulnerability record, a remote attacker could use crafted HTML to execute arbitrary code inside Chrome’s sandbox. The record does not establish a sandbox escape, full Windows compromise, active exploitation, or a specific attack campaign.
If the reported version is below 150.0.7871.46, allow Chrome to update through the normal approved process. Relaunch the browser afterward, then check the complete version again. The post-relaunch result is the evidence that matters.
If Chrome is controlled by an employer, school, or another organization and the update is unavailable or blocked, contact the responsible administrator. Do not bypass management controls or install an unapproved browser package.
That definition requires a numeric comparison using the entire version. Two installations can share the same major version while falling on opposite sides of the boundary. Reports that truncate the version to “150,” or omit one or more components, are insufficient for verification.
Version 150.0.7871.46 and later numeric versions fall outside the affected range documented for CVE-2026-14430. This conclusion must remain narrowly framed. It means the installation is not identified as affected by this CVE’s published version range; it does not certify the browser as fully secure, confirm that every available update has been installed, or address unrelated vulnerabilities.
The supplied material does not establish a particular Chrome release date, platform-specific follow-up version, rollout schedule, or deployment duration. Administrators should base closure on observed endpoint evidence rather than assumptions about when an update ought to have reached a device.
The supported findings are:
The sandbox limitation is significant but does not make the vulnerability harmless. It identifies the boundary of the published outcome. An attacker who reaches arbitrary code execution has crossed the intended boundary between supplying web content and controlling execution in the browser context.
At the same time, sandboxed execution should not be described as automatic control of Windows. The supplied record does not state that CVE-2026-14430 alone escapes the Chrome sandbox, elevates privileges, installs software, changes protected operating-system settings, or grants unrestricted access to the device.
The accurate description is therefore specific: affected Chrome versions can allow crafted HTML to produce arbitrary code execution inside Chrome’s sandbox.
The source of that assessment matters. The 8.8 score is a CISA-ADP contribution displayed in the NVD record, not an NVD- or NIST-authored score.
In the supplied material, NVD had not provided its own CVSS 4.0, CVSS 3.x, or CVSS 2.0 assessment. That does not invalidate the contributed score. It means vulnerability reports, dashboards, and executive summaries should preserve the attribution instead of treating every metric displayed by NVD as an NVD calculation.
The CISA-ADP SSVC assessment records:
“Exploitation: none” means the represented assessment did not identify exploitation. It is not proof that exploitation has never happened or cannot be reported later.
“Automatable: no” should likewise be reported as the recorded value. It does not establish that exploit development is impossible or that every attack would require extensive manual effort.
“Technical impact: total” is the value shown in the assessment. Separately, the published CVE outcome is arbitrary code execution inside Chrome’s sandbox. The SSVC value should not be expanded into a claim of total Windows compromise.
A vulnerable version is evidence of exposure, not evidence that the device has been compromised. Incident-response escalation should depend on independent endpoint, network, identity, browser, or forensic indicators rather than the version finding alone.
The record does not support conclusions about when the corrected Chrome build entered a stable channel, how rapidly it was distributed, which platforms received particular follow-up versions, or when endpoint and vulnerability-management products incorporated the information.
It does not confirm:
CWE-190 aligns directly with the published integer-overflow description. Further interpretation of either classification would require supporting technical material.
Microsoft Edge, Brave, Vivaldi, Opera, and similar products use their own release numbers, update channels, packaging, and vendor advisories. Chrome’s threshold should not be copied into an inventory rule for those browsers.
Updating Microsoft Edge does not verify Google Chrome, and updating Chrome does not verify another installed browser. Windows environments with multiple browsers should inventory and remediate each product independently.
CISA-ADP assigned the vulnerability an 8.8 High CVSS 3.1 score. Its SSVC assessment records exploitation as none, automatable as no, and technical impact as total. Those values should retain their attribution and should not be converted into claims of active attacks, impossible exploitation, or complete Windows compromise.
For Windows environments, the remediation standard is compact: collect the full four-part Chrome version, update installations below 150.0.7871.46, relaunch the browser, and collect fresh evidence. Managed devices that cannot update should be escalated through normal administration channels, while other Chromium-based browsers should be checked against their own vendors’ information.
Future advisories or public-record changes may add exploitation evidence, technical analysis, release details, or revised assessments. Until then, defenders can act without speculation: move Google Chrome outside this CVE’s documented affected range and verify the browser version actually running on each device.
| Reported Google Chrome state | CVE-2026-14430 status | Required response |
|---|---|---|
| Earlier than 150.0.7871.46 | Within the documented affected range | Update, relaunch, and verify again |
| Exactly 150.0.7871.46 | Outside the documented affected range | Record the complete verified version |
| Later than 150.0.7871.46 | Outside the documented affected range | Record the version and continue normal browser maintenance |
| Version unavailable, incomplete, or stale | Unknown | Obtain current four-part version evidence |
What to Do Now
Windows users
Check the complete Google Chrome version rather than relying on the major release number alone. An installation identified only as “Chrome 150” has not been verified against this CVE’s affected-version boundary.If the reported version is below 150.0.7871.46, allow Chrome to update through the normal approved process. Relaunch the browser afterward, then check the complete version again. The post-relaunch result is the evidence that matters.
If Chrome is controlled by an employer, school, or another organization and the update is unavailable or blocked, contact the responsible administrator. Do not bypass management controls or install an unapproved browser package.
Windows administrators
Use the organization’s established inventory and software-management systems to locate affected installations. The minimum defensible workflow is:- Inventory Google Chrome on in-scope Windows devices.
- Collect the complete four-part version.
- Flag every version below 150.0.7871.46.
- Treat missing, partial, or stale results as unresolved.
- Deploy an approved Chrome release outside the documented affected range.
- Ensure Chrome is relaunched after the update.
- Collect fresh version evidence rather than relying only on deployment status.
- Investigate devices that remain below the threshold or fail to report.
- Track other Chromium-based browsers separately under their own vendors’ guidance.
The Version Number Is the Security Boundary
The most operationally useful fact in the supplied record is the affected-version definition: Google Chrome versions before 150.0.7871.46 are affected.That definition requires a numeric comparison using the entire version. Two installations can share the same major version while falling on opposite sides of the boundary. Reports that truncate the version to “150,” or omit one or more components, are insufficient for verification.
Version 150.0.7871.46 and later numeric versions fall outside the affected range documented for CVE-2026-14430. This conclusion must remain narrowly framed. It means the installation is not identified as affected by this CVE’s published version range; it does not certify the browser as fully secure, confirm that every available update has been installed, or address unrelated vulnerabilities.
The supplied material does not establish a particular Chrome release date, platform-specific follow-up version, rollout schedule, or deployment duration. Administrators should base closure on observed endpoint evidence rather than assumptions about when an update ought to have reached a device.
What the Public Record Establishes
CVE-2026-14430 is described as an integer overflow in V8, the JavaScript engine used by Google Chrome. The documented attack condition is a crafted HTML page, and the stated outcome is arbitrary code execution inside Chrome’s sandbox.The supported findings are:
- The identified product is Google Chrome.
- The affected component is V8.
- The weakness is described as an integer overflow.
- Crafted HTML is the documented attack input.
- The attack is remotely reachable under the contributed assessment.
- User interaction is required under the supplied CVSS vector.
- Existing privileges are not required under that vector.
- Successful exploitation can result in arbitrary code execution inside the sandbox.
- Chrome versions before 150.0.7871.46 are within the documented affected range.
The sandbox limitation is significant but does not make the vulnerability harmless. It identifies the boundary of the published outcome. An attacker who reaches arbitrary code execution has crossed the intended boundary between supplying web content and controlling execution in the browser context.
At the same time, sandboxed execution should not be described as automatic control of Windows. The supplied record does not state that CVE-2026-14430 alone escapes the Chrome sandbox, elevates privileges, installs software, changes protected operating-system settings, or grants unrestricted access to the device.
The accurate description is therefore specific: affected Chrome versions can allow crafted HTML to produce arbitrary code execution inside Chrome’s sandbox.
Severity and Assessment Attribution
CISA-ADP assigned CVE-2026-14430 a CVSS 3.1 base score of 8.8, categorized as High. The supplied vector is:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HThe source of that assessment matters. The 8.8 score is a CISA-ADP contribution displayed in the NVD record, not an NVD- or NIST-authored score.
In the supplied material, NVD had not provided its own CVSS 4.0, CVSS 3.x, or CVSS 2.0 assessment. That does not invalidate the contributed score. It means vulnerability reports, dashboards, and executive summaries should preserve the attribution instead of treating every metric displayed by NVD as an NVD calculation.
The CISA-ADP SSVC assessment records:
- Exploitation: none
- Automatable: no
- Technical impact: total
“Exploitation: none” means the represented assessment did not identify exploitation. It is not proof that exploitation has never happened or cannot be reported later.
“Automatable: no” should likewise be reported as the recorded value. It does not establish that exploit development is impossible or that every attack would require extensive manual effort.
“Technical impact: total” is the value shown in the assessment. Separately, the published CVE outcome is arbitrary code execution inside Chrome’s sandbox. The SSVC value should not be expanded into a claim of total Windows compromise.
A vulnerable version is evidence of exposure, not evidence that the device has been compromised. Incident-response escalation should depend on independent endpoint, network, identity, browser, or forensic indicators rather than the version finding alone.
Verified Public-Record Timeline
The supplied material supports a sequence of public-record activity but does not provide sufficient support here for the previously stated calendar dates or detailed descriptions of every update payload. The defensible sequence is:- The NVD record received the Chrome-originated vulnerability description and affected-version information.
- CISA-ADP contributed a CVSS 3.1 assessment and SSVC decision values.
- NIST added analysis and configuration-related enrichment to the record.
- CISA-ADP later modified its contribution.
The record does not support conclusions about when the corrected Chrome build entered a stable channel, how rapidly it was distributed, which platforms received particular follow-up versions, or when endpoint and vulnerability-management products incorporated the information.
What Is Not Confirmed
The public record provides a useful remediation boundary, but it does not answer every technical or operational question.It does not confirm:
- Active exploitation or a specific attack campaign.
- A Chrome sandbox escape.
- Privilege escalation or automatic compromise of Windows.
- Malware installation, credential theft, persistence, or protected-system changes.
- Delivery through a particular advertisement, website, redirect, email, or campaign.
- The exact V8 operation, object type, allocation sequence, memory layout, or exploit primitive involved.
- A specific release date or rollout duration for the corrected browser.
- A platform-specific follow-up build beyond the documented threshold.
- A corrected-version boundary for Microsoft Edge, Brave, Vivaldi, Opera, or another Chromium-derived browser.
- That the CISA-ADP score was calculated by NVD or NIST.
- That “exploitation: none” guarantees exploitation has never occurred.
- That an installation outside this CVE’s affected range is protected from every other browser vulnerability.
CWE-190 aligns directly with the published integer-overflow description. Further interpretation of either classification would require supporting technical material.
Admin Checklist for Windows Environments
Identification
- Inventory Google Chrome across all in-scope Windows endpoints.
- Record the complete four-part version.
- Flag installations below 150.0.7871.46.
- Treat stale, incomplete, or missing results as unresolved.
- Confirm that each result refers to Google Chrome rather than another Chromium-based browser.
- Identify systems that are offline, rarely connected, or outside normal management coverage.
Remediation
- Deploy an approved Chrome release outside this CVE’s documented affected range.
- Use established browser, endpoint, or software-management controls.
- Relaunch Chrome after the update.
- Do not treat a registry workaround, browser flag, script restriction, or site-blocking rule as an equivalent version-based fix unless separately supported by the vendor.
- Escalate devices that cannot receive the approved release.
Verification
- Collect fresh version evidence after remediation and relaunch.
- Compare all four version components.
- Investigate systems still reporting versions below 150.0.7871.46.
- Keep unknown or non-reporting devices open until current evidence is available.
- Verify a representative sample independently when inventory accuracy is uncertain.
- Close remediation based on the resulting browser version, not merely on deployment-tool success.
Reporting
- Describe the issue as an integer overflow in Chrome’s V8 engine.
- State that crafted HTML can lead to arbitrary code execution inside the Chrome sandbox.
- Attribute the 8.8 High CVSS 3.1 score to CISA-ADP.
- Record the supplied SSVC values without expanding their meaning.
- Avoid describing the CVE as a confirmed sandbox escape or Windows takeover.
- Separate vulnerable-version findings from evidence of actual compromise.
- Note that a version outside this CVE’s range is not a general security guarantee.
Product scope
The supplied record identifies Google Chrome. Other Chromium-derived browsers may share upstream technology, but that fact alone does not establish their affected or corrected versions.Microsoft Edge, Brave, Vivaldi, Opera, and similar products use their own release numbers, update channels, packaging, and vendor advisories. Chrome’s threshold should not be copied into an inventory rule for those browsers.
Updating Microsoft Edge does not verify Google Chrome, and updating Chrome does not verify another installed browser. Windows environments with multiple browsers should inventory and remediate each product independently.
A Concise Notice for Users
Organizations can use the following user-facing notice without adding unsupported attack claims:This notice gives users a concrete task and a measurable completion condition. It does not claim that attacks are active, that vulnerable systems are already compromised, or that the flaw provides unrestricted control of Windows.
The Bottom Line
CVE-2026-14430 has a clear operational response. Google Chrome versions before 150.0.7871.46 are within the documented affected range. The vulnerability is described as an integer overflow in V8 that can allow crafted HTML to execute arbitrary code inside Chrome’s sandbox.CISA-ADP assigned the vulnerability an 8.8 High CVSS 3.1 score. Its SSVC assessment records exploitation as none, automatable as no, and technical impact as total. Those values should retain their attribution and should not be converted into claims of active attacks, impossible exploitation, or complete Windows compromise.
For Windows environments, the remediation standard is compact: collect the full four-part Chrome version, update installations below 150.0.7871.46, relaunch the browser, and collect fresh evidence. Managed devices that cannot update should be escalated through normal administration channels, while other Chromium-based browsers should be checked against their own vendors’ information.
Future advisories or public-record changes may add exploitation evidence, technical analysis, release details, or revised assessments. Until then, defenders can act without speculation: move Google Chrome outside this CVE’s documented affected range and verify the browser version actually running on each device.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:38:17-07:00
NVD - CVE-2026-14430
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:38:17-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: security.snyk.io
External Control of Assumed-Immutable Web Parameter in chromium | CVE-2026-14430 | Snyk
External Control of Assumed-Immutable Web Parameter in chromium | CVE-2026-14430security.snyk.io