HIGH 8.8

CVE-2026-11670: Google Chrome PDF Use-After-Free Remote Code Execution

A use-after-free vulnerability in Google Chrome's PDF renderer allows attackers to run malicious code within the browser's sandbox by crafting a specially designed PDF file. The attack requires user interaction—specifically, opening a malicious PDF—but once triggered, it can lead to complete compromise of the affected browser process. This affects Chrome versions prior to 149.0.7827.103 across Windows, macOS, and Linux systems.

Source data · NVD / CISA · public domain

CVSS
3.1 · 8.8 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-416
Affected products
4 configuration(s)
Published / Modified
2026-06-09 / 2026-06-17

NVD description (verbatim)

Use after free in PDF in Google Chrome prior to 149.0.7827.103 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted PDF file. (Chromium security severity: High)

2 reference(s) · View on NVD →

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

Technical summary

CVE-2026-11670 is a use-after-free memory corruption bug (CWE-416) in Chrome's PDF handling component. When a malicious PDF is processed, the renderer fails to properly manage object lifetime, allowing freed memory to be accessed and controlled by an attacker. This memory safety flaw enables arbitrary code execution within the browser's sandbox environment. The vulnerability was assigned a CVSS 3.1 score of 8.8 (High severity) with a network attack vector, low attack complexity, and no privilege requirements—meaning any attacker can exploit it if they can deliver the malicious PDF to a user.

Business impact

Organizations relying on Chrome for business operations face potential data exfiltration, credential theft, and lateral movement if employees open untrusted PDF documents. While the sandbox limits direct OS-level impact, attackers gaining code execution can steal browser session data, access cloud accounts, or pivot to internal systems. For organizations handling sensitive documents or those where users frequently receive PDFs from external sources, this represents a material risk that demands rapid patching.

Affected systems

Google Chrome on Windows, macOS, and Linux operating systems running versions prior to 149.0.7827.103 are vulnerable. Chromium-based browsers that incorporate the affected PDF rendering code may also be at risk depending on their own version and patch status; verification against each vendor's specific advisory is essential. Android and iOS Chrome versions should be checked separately against their respective release notes.

Exploitability

Exploitation requires social engineering: the attacker must convince a user to open a crafted PDF file. This is a moderate barrier compared to zero-click attacks, but PDF documents are ubiquitous in business communication, making successful delivery realistic. Once opened, the exploit triggers automatically without additional user action. No special browser configuration or user privileges are needed. The lack of evidence of active exploitation in the wild (KEV status: not listed) suggests this is still early in the disclosure cycle, but exploitability is straightforward.

Remediation

Immediately update Google Chrome to version 149.0.7827.103 or later. Verify that any derivative Chromium-based products used in your environment receive corresponding patches from their respective vendors. For users unable to update immediately, consider disabling PDF preview in Chrome (force downloads instead) or blocking external PDF delivery at the email gateway level as a temporary mitigating control.

Patch guidance

Google Chrome will automatically update to 149.0.7827.103 for most users, but verify completion via chrome://version/. Enterprise deployments using Google Chrome Enterprise should consult their admin console for managed rollout policies and confirm patch deployment across all managed devices. For organizations using alternative Chromium derivatives (Edge, Brave, Vivaldi, etc.), check the respective vendor's security advisories and apply patches independently, as release schedules vary. Document patch application dates for compliance records.

Detection guidance

Monitor for anomalous Chrome process behavior following PDF opens (unexpected child processes, network connections, or file access). Endpoint Detection and Response (EDR) tools should flag uses of unusual APIs post-PDF rendering, particularly memory access anomalies or shellcode execution patterns. At the network level, watch for lateral movement or exfiltration immediately following timestamps when users accessed PDF attachments. Web proxy logs can reveal which external PDFs users downloaded. Correlate PDF opens with subsequent credential theft or unusual account activity as indicators of successful exploitation.

Why prioritize this

An 8.8 CVSS score combined with user-initiated but easy-to-execute attack surface makes this a high-priority patch. The lack of KEV listing and apparent lack of widespread active exploitation suggest a narrow window before adversaries weaponize this—prioritize patching to maintain that advantage. Organizations where employees regularly receive PDFs from external parties should treat this as critical. The sandbox containment provides some defense-in-depth, but it is not a substitute for patching.

Risk score, explained

The CVSS 8.8 reflects the network attack vector (attacker can send a PDF remotely), low attack complexity (no special conditions needed), no privilege requirements, and severe impact (confidentiality, integrity, and availability all compromised at the sandbox level). The requirement for user interaction (opening a PDF) prevents a perfect 9.0+ score, but the confluence of ease of delivery, obviousness of exploitation, and severity of impact once triggered justifies the high classification.

Frequently asked questions

Can a user open a malicious PDF without knowing they are at risk?

Yes. A PDF looks like any other document; there is no visual indicator that it contains an exploit. If an attacker crafts the malicious PDF to appear to be a legitimate business document (invoice, contract, report), users are unlikely to suspect danger. This is why this vulnerability is particularly concerning in environments with high PDF traffic.

Does the Chrome sandbox prevent data theft if this vulnerability is exploited?

The sandbox does limit the attacker's ability to directly access the operating system or other applications. However, an attacker gaining code execution within the sandbox can steal data accessible to the browser process itself: session cookies, cached credentials, browsing history, and locally stored web application data. They can also exfiltrate documents or data that the user has access to through web applications. The sandbox provides a layer of defense, but it is not a complete barrier.

Do I need to patch if users only open PDFs from trusted internal sources?

Patching is still essential, because 'trusted' is relative. Phishing campaigns often spoof internal email addresses, and compromised internal systems can send malicious PDFs from legitimate-looking internal addresses. Additionally, supply-chain compromises could inject malicious PDFs into otherwise trusted document repositories. Patching removes the vulnerability entirely rather than relying on trust boundaries.

What should I do if I cannot update Chrome immediately due to compatibility issues?

In the short term, disable or restrict PDF preview: configure Chrome to download PDFs rather than open them in-browser, allowing time for security review before opening. Implement email gateway rules to strip or quarantine PDF attachments from external senders, or redirect them to a sandboxed preview service. Monitor user activity closely for signs of compromise. However, these are interim measures—prioritize resolving compatibility issues and applying the patch as soon as possible.

This analysis is based on the CVE record and Chromium security advisories current as of the published date. Security details may be refined as vendors release more complete patch notes and security guidance. Patch version numbers and affected product lists should be verified against official vendor advisories before deployment. No exploit code or detailed technical proof-of-concept is provided in this document. Organizations should conduct their own risk assessment based on their environment, user behavior, and threat landscape. SEC.co does not guarantee patch availability or deployment timelines for derivative or third-party Chromium products; vendors are responsible for releasing their own updates. Source: NVD (public-domain), retrieved 2026-07-15. Analysis generated by SEC.co (claude-haiku-4-5).