SEC.co
Emergency
MEDIUM 4.2

CVE-2026-14133: UI Spoofing in Google Chrome History Embeddings—Patch Guide

A race condition in Google Chrome's history embeddings feature could allow an attacker to trick users into seeing fake browser UI elements through a specially crafted webpage. The vulnerability requires user interaction and is difficult to exploit reliably, but successful exploitation could lead to minor information disclosure or allow the attacker to manipulate what the user sees on screen. Chrome versions before 150.0.7871.47 are affected.

Source data · NVD / CISA · public domain

CVSS
3.1 · 4.2 MEDIUM · CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N
Weaknesses (CWE)
CWE-362
Affected products
1 configuration(s)
Published / Modified
2026-06-30 / 2026-07-01

NVD description (verbatim)

Race in History Embeddings in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-14133 is a race condition (CWE-362) in the history embeddings subsystem of Chromium. The flaw permits a remote attacker to perform UI spoofing—displaying forged browser interface elements—by serving a crafted HTML page to a user. The vulnerability window is narrow due to timing requirements and user interaction constraints. While Chromium rates this as low severity, the CVSS 3.1 score of 4.2 reflects the requirement for user action, high attack complexity, and limited impact scope (confidentiality and integrity only, no availability impact).

Business impact

The primary risk is user deception. An attacker could spoof address bars, warnings, or permission dialogs to trick users into revealing sensitive information or approving malicious actions they believe are legitimate browser functions. This is particularly concerning for phishing campaigns or social engineering attacks that leverage false trust in the browser UI. The impact is typically individual-user focused rather than organizational-wide compromise, but repeated exploitation could erode user confidence in browser security.

Affected systems

Google Chrome releases prior to version 150.0.7871.47 are vulnerable across all platforms where Chrome runs (Windows, macOS, Linux, Android, iOS). Users on automatic update channels will receive the patch automatically; those on manual or delayed update schedules remain at risk until they upgrade.

Exploitability

Exploitation requires high attack complexity and user interaction—specifically, a user must visit an attacker-controlled or compromised webpage. The race condition nature means timing is critical and reliability may vary across system configurations and browser states. Real-world exploitation is possible but requires sophistication beyond typical drive-by attacks. No public exploit code or KEV inclusion indicates active exploitation in the wild is not yet documented.

Remediation

Upgrade Google Chrome to version 150.0.7871.47 or later. Most users will receive this update automatically through Chrome's background update mechanism; verify your version via chrome://settings/help. Organizations managing Chrome deployments should push the update to ensure coverage of all devices.

Patch guidance

Check your Chrome version by navigating to chrome://settings/help or chrome://about. If your version is below 150.0.7871.47, Chrome will automatically download and apply the patch; you may need to restart the browser to complete installation. For managed deployments, consult your organization's Chrome update policy and deployment tools (e.g., Google Admin Console) to ensure timely rollout. Verify successful patching by confirming the version number matches 150.0.7871.47 or later.

Detection guidance

Monitor Chrome version compliance across endpoints using asset management or MDM tools. Network-based detection of the specific HTML payload is challenging due to the race condition's timing requirements, but monitoring for unusual iframe nesting patterns or history API manipulation in real-time web traffic could provide signals. At the host level, logs from Chrome crash reporting or sandbox violation attempts may indicate exploitation attempts. User reports of suspicious UI behavior (misaligned or fake address bars) warrant investigation.

Why prioritize this

While the CVSS score is moderate and Chromium's official severity is low, this vulnerability merits timely patching because UI spoofing directly undermines user trust and can enable credential theft or social engineering at scale. The low barrier to distribution (simply hosting a malicious page) and the high likelihood that users will click through legitimate-looking spoofed UI make this a practical threat despite technical difficulty. Prioritize patching systems used by high-value targets, customer-facing staff, or users handling sensitive authentication flows.

Risk score, explained

The CVSS 3.1 score of 4.2 (Medium severity) reflects: Network accessibility (AV:N) with high attack complexity (AC:H) due to race condition timing; requirement for user interaction (UI:R); unchanged scope (S:U); and limited impact to confidentiality and integrity (C:L, I:L) with no availability impact (A:N). The score appropriately captures the gap between technical difficulty and practical exploitability. Organizations should treat this as medium-priority rather than critical, but not defer indefinitely.

Frequently asked questions

What does 'race condition in history embeddings' mean?

History embeddings are Chrome's internal feature for caching and displaying page history visually. A race condition occurs when the timing of two operations is critical—in this case, the attacker exploits a narrow window where the embeddings system is updating its state to insert forged UI elements. The 'race' metaphor refers to the attacker racing against the browser's own cleanup or validation logic.

Can an attacker exploit this without my knowledge?

Partially. The attacker must lure you to a malicious webpage, but once you're there, the exploit runs without additional prompts—you won't see a suspicious dialog or warning. However, the race condition means the attack may fail silently, and successful exploitation only creates visual spoofing; it doesn't immediately steal credentials or install malware. Your awareness of the spoofed UI is the attacker's next hurdle.

Is this vulnerability actively being exploited?

Not documented in the wild. The vulnerability is not listed on CISA's Known Exploited Vulnerabilities (KEV) catalog, meaning no confirmed active exploitation has been reported as of the publication date. This does not guarantee future safety, but it suggests the threat is theoretical rather than immediately active.

Do I need to patch immediately or can I wait?

Patch within your normal update cycle—typically within 1-2 weeks for most organizations. This is not a critical zero-day with active exploits, but the ease of delivery and social engineering risk warrant treating it as higher priority than minor bug fixes. Do not defer indefinitely; aim for 30 days maximum.

This analysis is based on publicly available vulnerability data current as of the publication date. Exploit details and active exploitation status may change; consult CISA's KEV catalog and official Chrome release notes for the latest information. Organizations should verify patch applicability within their own environment and perform testing before broad deployment. This explainer does not constitute professional security advice; engage qualified security personnel for threat assessment specific to your organization. Source: NVD (public-domain), retrieved 2026-08-09. Analysis generated by SEC.co (claude-haiku-4-5).

Affected vendors

google

Weaknesses (CWE)

CWE-362

Related vulnerabilities