MEDIUM 6.5

CVE-2026-10981: Chrome Cross-Origin Data Leak via Video Codec Flaw

CVE-2026-10981 is a cross-origin data leak vulnerability in Google Chrome's video codec handling. An attacker who has already compromised Chrome's renderer process can craft a malicious video file to exfiltrate sensitive data from other websites the user is visiting. The vulnerability requires user interaction (opening or playing a video file) and relies on prior compromise of the rendering engine, limiting the attack surface but creating risk for users who already have malware or who visit compromised sites.

Source data · NVD / CISA · public domain

CVSS
3.1 · 6.5 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Weaknesses (CWE)
CWE-20
Affected products
1 configuration(s)
Published / Modified
2026-06-04 / 2026-06-17

NVD description (verbatim)

Insufficient validation of untrusted input in Codecs in Google Chrome prior to 149.0.7827.53 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted video file. (Chromium security severity: High)

2 reference(s) · View on NVD →

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

Technical summary

The vulnerability stems from insufficient input validation in Chrome's codec libraries prior to version 149.0.7827.53. When processing untrusted video files, the codec implementation fails to properly validate input, allowing a compromised renderer process to read memory contents that should be protected by cross-origin boundaries. The CVSS 3.1 score of 6.5 (MEDIUM) reflects high confidentiality impact but no integrity or availability risk, and acknowledges that user interaction and prior renderer compromise are prerequisites. Chromium classifies this as High severity due to the nature of data exposure.

Business impact

For enterprise environments, this vulnerability is relevant primarily to organizations with restrictive browser policies or where sensitive information is accessed through web applications. The data leak potential means that users visiting sites hosting malicious videos—or whose systems are already compromised—face risk of credential theft, session hijacking, or exposure of confidential data viewed in other tabs. However, the requirement for renderer compromise reduces the likelihood of widespread exploitation compared to direct-trigger vulnerabilities. Organizations should weigh this against the generally low attack probability outside targeted scenarios.

Affected systems

Google Chrome versions prior to 149.0.7827.53 are affected. This includes stable, beta, dev, and canary release channels. The vulnerability affects all desktop platforms where Chrome is deployed (Windows, macOS, Linux). Mobile Chrome versions built from the same Chromium codebase prior to the fix are also potentially affected; verify exact version numbers for Chromium-based browsers like Edge, Brave, Opera, and other Chromium derivatives against their respective vendor advisories.

Exploitability

Exploitation requires two conditions: (1) the renderer process must already be compromised or under attacker control, and (2) the user must interact with a crafted video file. This is not an unauthenticated remote code execution. An attacker might chain this with a separate renderer-process exploit, or deploy the malicious video through a compromised web server, watering-hole attack, or supply-chain compromise. As a solo vulnerability, the bar for exploitation is elevated, but the data exposure severity justifies attention.

Remediation

Upgrade Google Chrome to version 149.0.7827.53 or later. Chrome's auto-update mechanism will push this update to most users automatically, though verification of installed versions is recommended in managed environments. For organizations using Chromium-based browsers other than Chrome, check the respective vendor advisories for patched versions. No workarounds are available beyond upgrading.

Patch guidance

Deploy Chrome version 149.0.7827.53 or later across managed systems. Most end-user systems will auto-update within days of release; however, organizations with update management policies should verify completion. Prioritize systems where users frequently handle video files from untrusted sources (e.g., email attachments, public downloads) or where sensitive data is regularly accessed in browser sessions. For enterprises using managed Chrome deployments (e.g., via AD or MDM), test the patch in a non-production environment first to rule out compatibility issues, then roll out gradually.

Detection guidance

Endpoint detection should verify Chrome versions via patch management tools or EDR agents that report installed software versions. Monitor for Chrome crashes or unexpected memory access patterns if available through browser telemetry. Network-level detection of this flaw is difficult; focus on ensuring patch compliance. If forensic analysis is needed post-incident, examine Chrome renderer process memory dumps for evidence of cross-origin data access, though such analysis typically requires specialized tools and incident response expertise.

Why prioritize this

Although the CVSS score is MEDIUM (6.5) and the vulnerability is not currently tracked in CISA's Known Exploited Vulnerabilities catalog, prioritize patching for business-critical or high-security systems within 30 days. The confidentiality impact (high) and the codec attack surface (frequently overlooked during security assessments) warrant attention. Deprioritize only in environments where Chrome is restricted or not used for sensitive work. This is not an emergency but should not be deferred indefinitely.

Risk score, explained

The CVSS 3.1 score of 6.5 (MEDIUM severity) reflects: high confidentiality impact (C:H) due to cross-origin data exposure, no integrity or availability impact (I:N, A:N), network-based attack vector (AV:N), low attack complexity (AC:L), no privilege requirement (PR:N), and required user interaction (UI:R). The score appropriately penalizes the vulnerability for requiring user interaction and prior renderer compromise, preventing a higher score. However, Chromium's internal assessment of High severity signals that the real-world risk may be elevated in targeted attack scenarios.

Frequently asked questions

Do I need to take immediate action, or can this wait?

This is not a zero-day or actively exploited vulnerability (it is not on CISA's KEV list), so immediate emergency response is not required. However, plan to patch within 30 days, especially for systems handling video files or accessing sensitive web applications. If your organization frequently processes video from external sources, accelerate the timeline.

What if I use a Chromium-based browser like Edge or Brave instead of Chrome?

Check your browser vendor's security advisory for the equivalent patch version. Edge, Brave, Opera, and other Chromium derivatives will have their own version numbers for the fix. Do not assume Chrome's version number applies directly. Most will auto-update similarly to Chrome, but verify in your environment.

Can an attacker exploit this without already compromising the renderer process?

No. This vulnerability requires a prior compromise or attacker control of Chrome's renderer process. It cannot be exploited by simply sending a malicious video to a user. That said, an attacker might chain this with a separate renderer-process exploit to amplify impact—the vulnerability should not be ignored, but the attack chain is multi-stage.

What data can be leaked?

Any data in the renderer process's memory can potentially be leaked, including data from open web pages, cached credentials, session tokens, and local storage. However, memory layout randomization and sandboxing limits what an attacker can reliably extract. The practical impact depends on what sensitive information is present in RAM at the time of exploitation.

This analysis is provided for informational purposes and reflects publicly available information as of the publication date. Patch versions, KEV status, and vendor details are sourced from official advisories and should be verified against Google's Chrome security page and respective vendor advisories before deployment. SEC.co makes no warranty regarding completeness or real-world applicability. Organizations must conduct their own risk assessments based on their environment, compliance requirements, and threat landscape. Proof-of-concept code or weaponization details are not included in this summary; refer to official sources for technical deep-dives and responsible disclosure practices. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).