CVE-2026-14150: Chrome Speech UI Spoofing Vulnerability – Patched in v150.0.7871.47

Technical summary

CVE-2026-14150 stems from insufficient input validation (CWE-20) in Chrome's Speech subsystem. The vulnerability allows an attacker with renderer process compromise to craft malicious HTML that bypasses validation checks and triggers UI spoofing. The attack surface is network-facing, requires no special privileges, and user interaction is needed to visit the malicious page. However, the renderer compromise prerequisite means this is a post-exploitation vector rather than a direct initial-access vulnerability. The Chromium project classified this as Low severity internally, though the CVSS 3.1 score of 5.4 (MEDIUM) reflects combined impact on integrity and confidentiality.

Business impact

UI spoofing attacks erode user trust and can be chained with other tactics to facilitate credential theft, malware distribution, or social engineering. In enterprise environments, compromised renderer processes may already indicate a breach, making this vulnerability part of a larger attack chain. The MEDIUM CVSS score and non-critical severity suggest this is not an immediate show-stopper, but it should be factored into patch planning alongside other Chrome updates. Organizations running older Chrome versions face incremental risk as exploit code matures.

Affected systems

Google Chrome versions prior to 150.0.7871.47 are vulnerable. This includes all releases before the patched version across Windows, macOS, and Linux. Enterprise deployments using ESR (Extended Stable Release) tracks should verify their specific update cadence. Chrome update delivery is typically automatic for consumer users but may be delayed in managed environments with custom policies.

Exploitability

Exploitation requires two conditions: the attacker must first compromise the Chrome renderer process (a non-trivial prerequisite), and the victim must then visit a crafted HTML page served or injected by the attacker. The vulnerability itself is likely straightforward to exploit once renderer access is achieved, but the initial compromise is the hard part. This is not a zero-click or drive-by attack; it's a secondary exploitation vector. Public exploit code has not been reported as of the vulnerability publication date, and the issue was not added to the CISA KEV catalog.

Remediation

Update Google Chrome to version 150.0.7871.47 or later as soon as it is available and verified in your environment. Most users will receive automatic updates within days of release. Administrators managing Chrome in enterprise settings should test the update in a staging environment and deploy via their chosen mechanism (GPO, MDM, or Chrome Enterprise policies). No configuration changes or workarounds are needed; patching is the only mitigation.

Patch guidance

Monitor the official Google Chrome release notes and security advisories for confirmation that version 150.0.7871.47 is available. Automatic updates are the default delivery method; monitor the 'About Chrome' page in your browser to confirm the installed version. In managed environments, use your MDM or policy management tool to roll out the update. Test in a pilot group before broad deployment if your organization has strict change management. There are no known blockers or compatibility issues with this update as of the source publication date.

Detection guidance

Look for signs of renderer process compromise as the prerequisite: unusual child processes spawned by the Chrome executable, unexpected network connections from the browser, or crash dumps indicating memory corruption. Monitor web access logs for visits to unknown or suspicious domains that might host exploit payloads. Once patched, the vulnerability cannot be triggered, so validation should focus on the pre-patch window. EDR tools configured to alert on suspicious Chrome behavior and process injection attempts will provide the most actionable signals. Audit older Chrome versions still in use across your fleet and accelerate updates for outdated instances.

Why prioritize this

This vulnerability warrants prioritization because it affects a ubiquitous application (Chrome) and represents a real post-exploitation vector that sophisticated adversaries could leverage. However, the requirement for prior renderer compromise and its non-critical Chromium severity rating mean it is not an emergency. Organizations should treat it as a routine security update, rolling it out within the normal patch cycle (typically 1–2 weeks). Enterprises with mature patch management and high-risk user populations should move faster. The absence of KEV listing and public exploit code means there is no immediate campaign activity to respond to.

Risk score, explained

The CVSS 3.1 score of 5.4 (MEDIUM) reflects low attack complexity and no privilege requirement, balanced against the user interaction and limited scope. Confidentiality and integrity are both impacted but availability is not. The renderer compromise prerequisite is not directly modeled in the base CVSS vector, which assumes network attack surface. In practical risk terms, this is a secondary vulnerability in a multi-stage attack; it becomes high-risk only if renderer compromise is already common in your threat model. For most organizations, a MEDIUM severity patch justifies timely but non-emergency action.

Frequently asked questions