01 · The Real Story
This is a peep-hole inside an app-embedded browser, not a front-door breach
CVE-2026-11278 is a cross-origin data leak in Chrome Custom Tabs on Android affecting Chrome before 149.0.7827.53. Custom Tabs are the browser surfaces Android apps open inside their own UX, so the interesting part is not generic web browsing but app-launched browser sessions that share Chrome state. The stated impact is confidentiality only: a crafted HTML page can leak cross-origin data, with no integrity or availability impact described.
The vendor-style 6.5/MEDIUM baseline overstates enterprise urgency because the decisive prerequisite is hidden in the description: the attacker is local. In practice that means a malicious or already-compromised Android app has to get onto the handset first, then weaponize Custom Tabs to siphon data. That is post-initial-access on a mobile endpoint, not an unauthenticated internet attack path, and there is no KEV listing, no public PoC, and a near-floor EPSS.
"This is a post-install mobile privacy bug, not a fleet-wide emergency."
02 · The Attack Path
4 steps from start to impact.
STEP 01
Land code on the handset
The attacker needs a malicious Android app or control of an existing app on the device. That app is the weaponized delivery vehicle because Custom Tabs are launched by Android apps via Intent flows, not by arbitrary internet hosts acting alone. This turns the CVE into a post-install mobile attack, not a direct browser-drive-by against your fleet.
Conditions required:
- Victim device runs Android with Chrome installed
- Chrome version is earlier than
149.0.7827.53 - Attacker can get a malicious or compromised app onto the device
Where this breaks in practice:
- Enterprise Android fleets often restrict sideloading and unknown sources
- Managed Play allowlisting and Play Protect reduce malicious app placement
- Requiring local code on-device dramatically narrows the exposed population
Detection/coverage: MDM/EMM can usually identify installed Chrome version, but network scanners will not see exploitability. Mobile threat defense or EDR-like telemetry is needed to spot malicious app behavior.
STEP 02
Launch a crafted Custom Tab session
The attacker-controlled app uses Android Intent /
CustomTabsIntent to open a weaponized HTML page inside Chrome Custom Tabs. Because Custom Tabs reuse the browser engine and often the user's browser state, the attacker gains a shot at abusing the flawed origin-handling path within that embedded browsing context.Conditions required:
- The malicious app can invoke Custom Tabs
- The target workflow uses Chrome Custom Tabs rather than a different browser surface
- The victim interacts with or views the crafted content
Where this breaks in practice:
- Not every enterprise app uses Custom Tabs in a reachable way
- User interaction is still required per the CVSS vector
- Some apps use safer auth-specific flows or different browser containers
Detection/coverage: Static SAST on enterprise apps may show Custom Tabs usage; runtime exploitation is hard to confirm because the Chromium bug details are still restricted.
STEP 03
Exploit origin validation weakness
Within the Custom Tabs session, the crafted page abuses the origin validation / cross-origin handling flaw to access data that should stay isolated. The bug is described as a data leak, so the likely outcome is exposure of content or browser state associated with another origin rather than sandbox escape or code execution.
Conditions required:
- The victim has relevant authenticated browser state or accessible cross-origin content
- The vulnerable code path is hit inside Custom Tabs
- The crafted page can reliably trigger the flaw
Where this breaks in practice:
- Impact depends on the victim already having useful browser state
- Bug details remain restricted, limiting exploit reliability information
- Confidentiality-only impact usually yields narrower blast radius than RCE
Detection/coverage: There is no broad scanner signature for this logic flaw. Expect version-based detection only.
STEP 04
Exfiltrate leaked data
The malicious app or page then exfiltrates whatever cross-origin data it can collect to attacker infrastructure. At that point the data theft is real, but the blast radius is still bounded to the specific Android device, app flow, and user session that the attacker already reached.
Conditions required:
- Outbound network access exists for the app or page
- Leaked data is valuable enough to exfiltrate
- The attacker can correlate stolen data to a victim account or session
Where this breaks in practice:
- Per-device scope limits enterprise-wide impact
- Mobile outbound filtering, DNS controls, and MTD can catch suspicious exfil
- No evidence yet of operationalized campaigns using this CVE
Detection/coverage: Mobile threat defense, egress DNS/HTTP telemetry, and app reputation controls are more useful here than classic vulnerability scanners.
03 · Compensating Control
1
Enforce managed app allowlisting — Make malicious app placement harder by restricting installs to Managed Google Play / approved catalogs and blocking unknown sources. For a LOW verdict there is no formal mitigation SLA; treat this as backlog hygiene and verify the policy is in place during the next mobile control review.
2
Disable sideloading where business permits — This CVE gets real only after a local foothold, so cutting off sideloading materially lowers exposure. On managed Android, enforce the restriction through EMM policy and confirm exceptions are documented; for LOW, handle in routine hardening rather than emergency change.
3
Keep Chrome auto-updates enforced — Use EMM compliance to require Chrome for Android
149.0.7827.53+ and auto-update from Play. Because this is LOW, fold it into the normal mobile app update cadence rather than a crash patch window.4
Monitor for risky app behavior — Mobile threat defense, Play Protect telemetry, and app reputation controls can catch the more realistic precursor: a suspicious app invoking browser-like flows or exfiltrating data. Again, no mitigation SLA applies here; prioritize on fleets that store high-value tokens on Android devices.
What doesn't work
- A perimeter WAF does not solve this because the vulnerable boundary is inside an on-device browser component, not your internet edge.
- External attack-surface scanners will not help; there is no internet-facing port or banner to fingerprint.
- Generic desktop Chrome patch dashboards are insufficient if they do not separately track Android app versions.
- Relying only on MFA does not stop data leakage from an already-authenticated browser session on the device.
04 · Intelligence Metadata
The supporting signals.
| In-the-wild status | No confirmed active exploitation found in the sources reviewed, and not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC located on GitHub or in primary-source references during this assessment; Chromium bug details remain restricted. |
| EPSS | 0.00007 (~0.007%) from the user-provided intel. Percentile was not independently confirmed from FIRST in this assessment, but this score sits near the floor of EPSS values. |
| KEV status | No. CISA KEV catalog reviewed on 2026-06-07; CVE-2026-11278 was not present. |
| CVSS vector interpretation | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N means easy trigger conditions *if reachable*, but the narrative description says local attacker, which materially narrows real-world reach versus a true internet-reachable browser bug. |
| Affected versions | Google Chrome on Android prior to 149.0.7827.53. |
| Fixed version | Upgrade to Chrome for Android 149.0.7827.53 or later. No distro-style backport channel was identified; this is primarily a Play Store / managed mobile app update problem. |
| Exposure footprint | There is no meaningful Shodan/Censys/FOFA exposure query because this is not a network service. Exposure is instead the subset of managed Android devices running vulnerable Chrome and using apps that invoke Custom Tabs. |
| Disclosure timing | CVE published by NVD on 2026-06-04 and modified by CISA-ADP on 2026-06-05; Chrome stable 149 shipped on 2026-06-02. |
| Reporter / source | Chrome release notes credit Google and map the underlying issue to Chromium bug 501859865. |
Sources.
- NVD entry for CVE-2026-11278
- Chrome Releases: Stable Channel Update for Desktop (Chrome 149 security fixes)
- Chrome for Developers: Overview of Android Custom Tabs
- Android Open Source Project: Implement Android Custom Tabs for Captive Portal Login
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS API documentation
- Chrome Releases: Chrome for Android Update (Chrome 149 rollout context)
05 · The Call
Final Verdict
↓ DOWNGRADED to LOW (3.4/10)
Why this verdict
- Downward pressure: requires local attacker position — the CVE description itself says *local attacker*, which implies the attacker is already on the Android device or has planted a malicious app there.
- Downward pressure: Android + Custom Tabs only — this is not generic Chrome desktop exposure and not every mobile workflow uses reachable Custom Tabs paths.
- Downward pressure: confidentiality-only impact — there is no code execution, sandbox escape, or persistence; blast radius is typically one user session on one handset.
- Downward pressure: low threat telemetry — no KEV listing, no public PoC located, and user-supplied EPSS is effectively floor-level.
- Residual risk remains — Custom Tabs share real browser state, so a successful exploit can still expose meaningful cross-origin data on devices that already hold corporate sessions.
Why not higher?
If this were a true unauthenticated remote browser bug that any website could hit directly across the open internet, the vendor 6.5 would be defensible. But the local-attacker prerequisite and Android-app delivery requirement compound the friction; most enterprises would already view that as a sign of prior compromise or malicious app installation. That is why this does not belong in HIGH or even a strong MEDIUM bucket.
Why not lower?
It is not IGNORE because Chrome on Android is widely deployed and Custom Tabs often inherit valuable authenticated browser state. If you run managed Android fleets with SSO-heavy mobile apps, a malicious app already on-device could use this bug to turn a foothold into real data exposure. That is enough to keep it above pure paperwork.
06 · Verification
Crowdsourced verification payload.
Run this on an auditor workstation with adb installed, against a connected Android device or emulator with USB debugging/enterprise shell access enabled. Invoke it as ./check_cve_2026_11278.sh <serial> or ./check_cve_2026_11278.sh for the default device; it needs permission to use adb, but no root on the handset.
#!/usr/bin/env bash
# check_cve_2026_11278.sh
# Verify Chrome for Android version for CVE-2026-11278.
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN / error
set -euo pipefail
TARGET_VERSION="149.0.7827.53"
SERIAL="${1:-}"
ADB=(adb)
if [[ -n "$SERIAL" ]]; then
ADB+=( -s "$SERIAL" )
fi
if ! command -v adb >/dev/null 2>&1; then
echo "UNKNOWN - adb not found in PATH"
exit 2
fi
if ! "${ADB[@]}" get-state >/dev/null 2>&1; then
echo "UNKNOWN - no reachable Android device via adb"
exit 2
fi
VERSION="$("${ADB[@]}" shell dumpsys package com.android.chrome 2>/dev/null | tr -d '\r' | awk -F= '/versionName=/{print $2; exit}')"
if [[ -z "$VERSION" ]]; then
echo "UNKNOWN - Chrome package not found or version unreadable"
exit 2
fi
verlte() {
# returns 0 if $1 <= $2 using version sort
[[ "$1" == "$2" ]] && return 0
local first
first="$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)"
[[ "$first" == "$1" ]]
}
if verlte "$VERSION" "$TARGET_VERSION" && [[ "$VERSION" != "$TARGET_VERSION" ]]; then
echo "VULNERABLE - Chrome version $VERSION is earlier than $TARGET_VERSION"
exit 1
fi
if [[ "$VERSION" == "$TARGET_VERSION" ]] || ! verlte "$VERSION" "$TARGET_VERSION"; then
echo "PATCHED - Chrome version $VERSION is $TARGET_VERSION or later"
exit 0
fi
echo "UNKNOWN - unable to determine state"
exit 2