LOW 3.3

CVE-2026-13942: Chrome ChromeOS UI Spoofing via Video Capture – Low-Risk Local Flaw

A vulnerability in Google Chrome's video capture implementation on ChromeOS allows a local attacker to create fake UI elements through a specially crafted web page. The attacker must already have local access to the device and the user must interact with the malicious page, but the attack only affects the visual presentation of the interface—it cannot steal data or crash the system.

Source data · NVD / CISA · public domain

CVSS
3.1 · 3.3 LOW · CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Weaknesses (CWE)
CWE-20
Affected products
2 configuration(s)
Published / Modified
2026-06-30 / 2026-07-02

NVD description (verbatim)

Inappropriate implementation in Video Capture in Google Chrome on ChromeOS prior to 150.0.7871.47 allowed a local attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)

2 reference(s) · View on NVD →

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

Technical summary

CVE-2026-13942 stems from improper validation in Chrome's Video Capture module on ChromeOS versions before 150.0.7871.47. The flaw enables UI spoofing attacks where a crafted HTML page can deceive users by displaying false interface elements. The attack vector is local and requires user interaction, making it a social engineering vector rather than a remote code execution risk. The underlying issue is categorized as CWE-20 (Improper Input Validation), reflecting inadequate sanitization of rendering inputs in the video capture context.

Business impact

The direct business impact is limited due to the local-only attack vector and reliance on user interaction. However, UI spoofing can facilitate credential harvesting or social engineering if an attacker combines this flaw with phishing tactics to convince users they are interacting with a trusted system dialog. Organizations running ChromeOS in educational, kiosk, or open-access environments should assess whether this attack surface is realistic in their threat model. The integrity impact is confined to visual presentation, reducing risk to data confidentiality and system availability.

Affected systems

Google Chrome and ChromeOS versions prior to 150.0.7871.47 are affected. ChromeOS devices running unpatched Chrome are the primary target, as the vulnerability is specific to ChromeOS's video capture implementation. Organizations using managed ChromeOS fleets should verify their device enrollment and auto-update settings to ensure timely patching.

Exploitability

Exploitability is constrained by three factors: local access requirement, user interaction necessity, and the need for the user to visit a malicious website. An attacker cannot exploit this remotely or without the target user opening a crafted page. The attack does not require elevated privileges, making it accessible to any local user who can direct a target to a webpage. Given these constraints, the overall exploitability is low in most enterprise environments but remains feasible in scenarios where users frequently open untrusted pages or if combined with other social engineering.

Remediation

Update Google Chrome and ChromeOS to version 150.0.7871.47 or later. For organizations managing ChromeOS devices, verify that automatic updates are enabled and that the fleet has received the security patch. Administrators should audit device enrollment status and update deployment timelines to confirm all affected instances are remediated within 30 days.

Patch guidance

Deploy Chrome/ChromeOS version 150.0.7871.47 or later. For managed ChromeOS deployments, use Google Admin Console to verify and force auto-update policies. Manual updates can be triggered through Settings > About Chrome/ChromeOS > Check for updates. Verify patch application by checking the version string in chrome://version or the ChromeOS system settings. No special configuration changes are required post-patch.

Detection guidance

Detection of active exploitation is difficult because the attack relies on user interaction with a malicious webpage and affects only local rendering. Monitor for unusual HTML content in logs from endpoints that access untrusted domains. Browser security tools and content security policy (CSP) violations may flag suspicious scripts attempting to manipulate video capture elements. Endpoint detection and response (EDR) solutions should focus on identifying locally spawned processes attempting to interact with video capture APIs abnormally. User awareness training remains the most practical detection and prevention mechanism.

Why prioritize this

Despite a CVSS score of 3.3, this vulnerability should not command urgent priority in most threat models. The local attack vector, user interaction requirement, and integrity-only impact make it a lower-order risk compared to remote code execution or privilege escalation flaws. However, organizations with high user mobility, open-access kiosks, or frequent external visitor access should elevate priority modestly. Security teams should integrate this into standard patching schedules rather than treating it as an emergency.

Risk score, explained

The CVSS 3.1 score of 3.3 (LOW severity) reflects the constrained attack surface: AV:L (local only), AC:L (low complexity once local access exists), PR:N (no privilege required), UI:R (requires user interaction), and impact limited to integrity (I:L) with no confidentiality or availability effects. The score accurately captures the limited exploitability and harm potential, making it a reasonable benchmark for prioritization within a larger patch portfolio.

Frequently asked questions

Can this vulnerability be exploited remotely over the network?

No. The attack requires local access to the device and user interaction with a malicious HTML page. Remote exploitation is not possible, which significantly reduces the risk profile in most enterprise networks.

What is 'UI spoofing' and why does it matter?

UI spoofing means an attacker can trick users by displaying fake interface elements—for example, a false password prompt or system warning. While this cannot directly steal data, it is effective for social engineering and credential harvesting if combined with phishing or social manipulation tactics.

Do we need to patch immediately, or can this wait for a regular update cycle?

Unless your organization operates open-access ChromeOS kiosks or has users frequently visiting untrusted websites, this can be addressed within standard patching schedules (30 days). Organizations with higher user mobility or public-facing devices should prioritize deployment within 7–14 days.

How can we reduce the risk while waiting for patches?

Enforce browsing restrictions using content filtering and security policies. Educate users on recognizing suspicious popups and pages. Use managed ChromeOS enrollment to ensure automatic updates are enabled. For high-risk environments, consider temporary restrictions on video capture permissions.

This analysis is provided for informational purposes and is based on the published CVE record as of the date specified. Organizations should verify patch availability and applicability in their specific environments against official Google Chrome and ChromeOS security advisories. No exploit code or weaponized proof-of-concept is provided herein. Security teams should conduct their own risk assessments aligned with their threat models and regulatory obligations. Source: NVD (public-domain), retrieved 2026-08-09. Analysis generated by SEC.co (claude-haiku-4-5).