CVE-2026-11012: Chrome Android Use-After-Free Sandbox Escape Vulnerability
A use-after-free vulnerability exists in Google Chrome's Serial API on Android devices running versions before 149.0.7827.53. An attacker who has already compromised Chrome's renderer process can exploit this flaw by serving a specially crafted HTML page to achieve a sandbox escape—breaking out of Chrome's security isolation layer. While the underlying Chromium issue is rated Medium severity by Google, the CVSS 3.1 score of 8.3 reflects the HIGH impact potential when combined with renderer compromise.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 8.3 HIGH · CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
- Weaknesses (CWE)
- CWE-416
- Affected products
- 2 configuration(s)
- Published / Modified
- 2026-06-04 / 2026-06-17
NVD description (verbatim)
Use after free in Serial in Google Chrome on Android prior to 149.0.7827.53 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape 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-11012 is a use-after-free vulnerability (CWE-416) in the Serial API implementation within Google Chrome and Android's Chromium-derived browser. The flaw resides in memory management of the Serial interface; when objects are freed but subsequently accessed by crafted JavaScript in a malicious HTML page, heap corruption can occur. An attacker must first compromise the renderer process—typically through a separate vulnerability or social engineering—to reach the attack surface. Once in-renderer, a carefully constructed HTML payload can trigger the use-after-free condition, allowing escape from the renderer sandbox and execution with higher privileges. This is a two-stage attack requiring initial renderer compromise as a prerequisite.
Business impact
For organizations managing Android devices where Chrome is the primary browser, this vulnerability creates a two-tier risk: standard phishing or credential-harvesting attacks become more dangerous if they can deliver payloads to a compromised renderer, and any existing renderer vulnerabilities become more valuable as stepping stones to full device compromise. Financial institutions, healthcare providers, and enterprises with sensitive mobile workflows should assess their Chrome version distribution on Android. The HIGH CVSS score reflects potential for data theft, malware installation, or lateral movement within enterprise networks if devices are compromised. However, real-world impact depends on the prevalence of prior renderer exploits in the threat ecosystem.
Affected systems
Google Chrome on Android versions prior to 149.0.7827.53 are vulnerable. This includes all stable and extended-support releases below that version. The vulnerability does not affect Chrome on Windows, macOS, Linux, or iOS. Desktop Chrome users are not impacted. Organizations should verify their Android device Chrome version via Settings > About Chrome and confirm automatic updates are enabled.
Exploitability
Exploitation requires a two-step attack chain: first, a renderer process compromise (from a separate vulnerability, malware, or social engineering), then delivery of malicious HTML to trigger the use-after-free. The CVSS vector reflects high impact (C:H/I:H/A:H) but high complexity (AC:H) and the need for user interaction (UI:R). As of the vulnerability publication date, this issue is not listed in CISA's KEV catalog, suggesting active exploitation in the wild is not yet documented at scale. However, the attack pattern—sandbox escape via heap corruption—is well-understood in Chrome security research, making proof-of-concept development feasible once renderer access is achieved.
Remediation
Organizations must upgrade Chrome on Android devices to version 149.0.7827.53 or later. Enable automatic updates through Play Store settings to ensure devices patch without manual intervention. For enterprises managing devices via Mobile Device Management (MDM) solutions, enforce a minimum Chrome version requirement in compliance policies. Monitor Chrome version compliance through device inventory tools; prioritize patching for high-risk user segments (finance, HR, executive roles). As a defense-in-depth measure, educate users to avoid clicking suspicious links or downloading files from untrusted sources—this reduces the initial renderer compromise risk that makes this vulnerability exploitable.
Patch guidance
Update Chrome to version 149.0.7827.53 or later. On Android, patches are typically delivered via Google Play. Users can manually check for updates in Settings > Apps > Chrome > Update, or enable auto-update via Play Store settings (default for most users). Enterprise administrators using managed Play Store accounts can push the update fleet-wide. Note that devices must have functioning Play Store access and sufficient free storage; establish pre-update communication to ensure compliance. Verify post-update by checking Settings > About Chrome, which will display the running version number.
Detection guidance
Monitor Chrome version numbers across your Android device fleet using MDM or SIEM integration with mobile device telemetry. Alert on devices running Chrome versions below 149.0.7827.53. If using Android Enterprise or Knox-enabled Samsung devices, check Mobile Threat Defense logs for suspicious Serial API activity or unexpected privilege escalation attempts. Behavioral indicators include abnormal inter-process communication (IPC) from Chrome and unexpected native code execution on the device. Examine Play Store install logs for any suspicious apps installed immediately after a Chrome exploit; this may indicate post-breach lateral movement.
Why prioritize this
Despite HIGH CVSS (8.3) and broad Chrome exposure on Android, real-world urgency is tempered by: (1) KEV non-inclusion suggests limited documented wild exploitation, (2) two-stage attack requirement reduces casual exploitation risk, (3) many enterprise Android devices run older Chrome versions not yet at scale, and (4) sandbox escape impact is severe but localized to the device. Prioritize for organizations with high-risk mobile user bases, financial/healthcare sectors, or BYOD programs. For general enterprises, standard patching cycles within 60 days are appropriate; expedite if renderer-exploit campaigns emerge.
Risk score, explained
The CVSS 3.1 score of 8.3 (HIGH) results from: maximum impact potential (confidentiality, integrity, and availability all high due to sandbox escape), but mitigated by attack complexity requiring prior compromise (AC:H) and user interaction (UI:R). The scope change (S:C) indicates the vulnerability can affect resources beyond the vulnerable component—i.e., other device processes and data once sandbox is breached. The score appropriately reflects that a sandbox escape is a critical capability, but only in the hands of attackers who have already achieved renderer process access. This is not a one-click remote code execution vulnerability, but a high-value second stage in a multi-stage attack.
Frequently asked questions
Do I need to patch immediately, or can I schedule this for a standard maintenance window?
If your Android device fleet is not currently exposed to active renderer exploits (no documented campaigns targeting your organization), a 60-day patch cycle is reasonable. However, if you operate in a high-risk sector (finance, healthcare, critical infrastructure) or have evidence of suspicious app installations, expedite to 2–4 weeks. Monitor CISA KEV and security news for any escalation to active exploitation.
Does this affect Chrome on iOS or desktop browsers?
No. This vulnerability is specific to Chrome on Android and does not impact Chrome on Windows, macOS, Linux, or iOS. Desktop users and iOS users are not affected and do not require this specific patch.
What is a 'use-after-free' and why is it dangerous?
A use-after-free occurs when code accesses memory that has already been freed, leading to unpredictable behavior. In this case, it allows an attacker to corrupt heap memory and potentially execute arbitrary code. When that code runs in Chrome's renderer process, breaking out of the sandbox (a sandbox escape) becomes possible, granting access to the entire device.
If I have automatic updates enabled, am I protected?
Yes, as long as automatic updates are genuinely enabled and your device has regular internet access and storage space. You can verify in Play Store settings; most Android users have auto-update on by default. If you are concerned, manually check Settings > About Chrome to confirm you are running version 149.0.7827.53 or later.
This analysis is based on publicly available vulnerability data as of June 2026 and reflects threat modeling at publication. Actual exploitability and impact may vary depending on device configuration, Android version, additional mitigations, and the presence of upstream renderer vulnerabilities in your threat landscape. Patch version numbers and affected product versions reference the official CVE description; verify against Google's official security advisory for the most current information. This document does not constitute legal advice or guarantee of security. Organizations should conduct their own risk assessment and consult with their security and legal teams before making remediation decisions. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-10000HIGHChrome Sandbox Escape via Use-After-Free in Password Handling
- CVE-2026-10001HIGHChrome Sandbox Escape via PerformanceManager Use-After-Free
- CVE-2026-10002HIGHGoogle Chrome PDFium Use-After-Free Vulnerability (CVSS 8.8)
- CVE-2026-10003HIGHChrome Use-After-Free Code Execution Vulnerability Analysis
- CVE-2026-10005HIGHChrome macOS Use-After-Free RCE Vulnerability (7.5 CVSS)
- CVE-2026-10007HIGHChrome Use-After-Free in SVG Arbitrary Code Execution (CVSS 8.8)
- CVE-2026-10012HIGHChrome Skia Use-After-Free Sandbox Escape (v148.0.7778.216)
- CVE-2026-10013HIGHUse-After-Free in Chrome WebCodecs – Patch Guide & Risk Assessment