TargetHandlerAndroid::TargetHandlerAndroid(protocol::UberDispatcher* dispatcher,
                                           bool is_trusted,
                                           bool may_read_local_files) {
  protocol::Target::Dispatcher::wire(dispatcher, this);
  // is_trusted and may_read_local_files are accepted but not stored.
  // No member fields exist for them. No later check on them in CreateTarget.
}

chrome/browser/devtools/protocol/target_handler_android.cc:38-77 — CreateTarget accepts the renderer-supplied url
and passes it straight through:

WebContents* web_contents =
    tab_model->CreateNewTabForDevTools(GURL(url), new_window.value_or(false));

No scheme check anywhere in the function.

Compare to the desktop handler (already fixed)

chrome/browser/devtools/protocol/target_handler.cc:168-178, added by 28c26ea20357f:

if (!is_trusted_ && (inner_url.SchemeIs(content::kChromeUIUntrustedScheme) ||
                     inner_url.SchemeIs(content::kChromeDevToolsScheme))) {
  return protocol::Response::ServerError(
      "Navigating to a URL with a privileged scheme is not allowed");
}
if (!may_read_local_files_ && inner_url.SchemeIsFile()) {
  return protocol::Response::ServerError(
      "Creating a target with a local URL is not allowed");
}

The Android port was authored in 2025 with the same constructor signature (suggesting intent to apply the same
check) but the function body forgot to store or consume the parameters.

Live PoC evidence (Chrome 148.0.7778.120 stable on Android 11)

End-to-end repro against shipping Chrome stable. All three privileged URLs are accepted by Target.createTarget;
the desktop handler rejects all three:

URL: devtools://settings
Android (target_handler_android.cc, current): result.targetId = … (accepted)
Desktop (target_handler.cc, fixed): error: "Navigating to a URL with a privileged scheme is not allowed"
────────────────────────────────────────
URL: chrome-untrusted://feedback
Android (target_handler_android.cc, current): result.targetId = … (accepted)
Desktop (target_handler.cc, fixed): error: "Navigating to a URL with a privileged scheme is not allowed"
────────────────────────────────────────
URL: file:///sdcard/Documents/
Android (target_handler_android.cc, current): result.targetId = … (accepted)
Desktop (target_handler.cc, fixed): error: "Creating a target with a local URL is not allowed"

The created tabs are real type:"page" entries in /json, each with its own per-target WebSocket debugger and
attachable from an untrusted CDP client.

Practical content render on Android Chrome 148 stable (verified via Runtime.evaluate of location.href and
document.body.innerText against each new target):

- file:///sdcard/Documents/ → renders Chrome's built-in directory-listing page (location.href =
file:///sdcard/Documents/, title = "Index of /sdcard/Documents/"). Attacker scrapes the listing via
Runtime.evaluate document.documentElement.outerHTML and enumerates every file name + size + timestamp visible to
the Chrome process. Page.captureScreenshot also returns the rendered listing as a PNG. Wire-confirmed.
- devtools://settings → location.href redirects to chrome-error://chromewebdata/, body reads "This site can't be
reached … ERR_INVALID_URL". The Android Chrome stable build does not register a devtools://settings WebUI host, so
 the renderer's URL validator rejects the URL after the CDP layer has already accepted it.
- chrome-untrusted://feedback → same chrome-error://chromewebdata/ redirect with ERR_INVALID_URL. Android does not
 register this chrome-untrusted:// host either.
- Individual file:// file content read via direct navigation (e.g., file:///sdcard/Documents/poc09_sentinel.txt) →
 renderer denies with ERR_ACCESS_DENIED (separate defense-in-depth, holds regardless of the CDP gap).

Conclusion on practical impact: the CDP-layer trust-check gap is real, and the rendering-side outcome on shipping
Chrome 148 stable is bounded by Chrome's renderer mitigations. The load-bearing exploitable capability today is
file:// directory enumeration. The protocol-layer fix is still required because (a) the desktop posture treats
devtools:// and chrome-untrusted:// rejection as a protocol-layer responsibility, and (b) any future Android
Chrome that adds new chrome-untrusted://... or devtools://... WebUI hosts becomes immediately exploitable without
this fix — the renderer's URL-validator-as-mitigation is brittle.

Threat model

- Caller: untrusted CDP client connected via adb forward from a desktop. The standard chrome://inspect developer
flow on Chrome for Android.
- Activation prereq on non-rooted device (honestly disclosed): the abstract socket chrome_devtools_remote requires
 the user to have enabled chrome://flags/#enable-command-line-on-non-rooted-devices and written
--enable-remote-debugging to /data/local/tmp/chrome-command-line. This is the standard developer flow per
https://developer.chrome.com/docs/devtools/remote-debugging.
- Capability obtained: an untrusted CDP client can call Target.createTarget with a privileged-scheme or file://
URL and get back a targetId plus a per-target WebSocket. The new tab is attachable; the renderer renders content
for the file:// case and falls back to chrome-error://chromewebdata/ for the chrome-untrusted:// / devtools://
cases on current Android Chrome stable.
- Realistic attack scenarios: a user enables USB debugging for legitimate development/testing/screen-recording
reasons and runs an attacker-controlled tool on their desktop that uses the remote-debugging port; or another app
on the same machine reuses the chrome_devtools_remote abstract socket.

Suggested patch

Mirror the desktop handler's storage + check:

// target_handler_android.h — add member fields:
private:
  bool is_trusted_ = false;
  bool may_read_local_files_ = false;

// target_handler_android.cc — store in constructor and apply in CreateTarget:
TargetHandlerAndroid::TargetHandlerAndroid(
    protocol::UberDispatcher* dispatcher,
    bool is_trusted,
    bool may_read_local_files)
    : is_trusted_(is_trusted), may_read_local_files_(may_read_local_files) {
  protocol::Target::Dispatcher::wire(dispatcher, this);
}

// In CreateTarget, before CreateNewTabForDevTools:
GURL gurl(url);
if (gurl.is_empty()) {
  gurl = GURL(url::kAboutBlankURL);
}
GURL inner_url = gurl;
if (gurl.SchemeIs(content::kViewSourceScheme)) {
  inner_url = GURL(gurl.GetContent());
}
if (!is_trusted_ && (inner_url.SchemeIs(content::kChromeUIUntrustedScheme) ||
                     inner_url.SchemeIs(content::kChromeDevToolsScheme))) {
  return protocol::Response::ServerError(
      "Navigating to a URL with a privileged scheme is not allowed");
}
if (!may_read_local_files_ && inner_url.SchemeIsFile()) {
  return protocol::Response::ServerError(
      "Creating a target with a local URL is not allowed");
}

Cross-reference

Sister-gap of:

- Bug 503197481 ("Disallow Target.createTarget to devtools:// URLs from untrusted clients") — commit 28c26ea20357f,
2026-04-22, with M138 / M142 / M143 LTS backports on the desktop handler.

The Android port of the same handler was authored in 2025 with a constructor signature accepting both is_trusted and
may_read_local_files — suggesting the author intended to apply the desktop check — but the function body never stores
or consumes either parameter. Pure forgotten-port shape.


#### Impact analysis

## Who can exploit

An **untrusted CDP client** connected via `adb forward` from a desktop to Chrome for Android's
`chrome_devtools_remote` abstract socket — the standard `chrome://inspect` developer flow. Examples:

- An attacker-controlled CLI that a user runs on their desktop while a Chrome-for-Android device is plugged in and
USB-debugging is enabled (a state developers, QA testers, and screen-recording users routinely have).
- Another app on the same desktop that reuses the `chrome_devtools_remote` abstract socket.

Untrusted-client reachability is confirmed by `IsDomainAvailableToUntrustedClient<TargetHandlerAndroid>()` returning
`true` (`chrome_devtools_session_android.cc:17`). The desktop fix (`28c26ea20357f`) treats exactly this caller as the
threat model.

## What they gain

### Protocol-layer (the bug)

`Target.createTarget` returns a real `targetId` for `devtools://`, `chrome-untrusted://`, and `file://` URLs that the
desktop handler now rejects. The new tab is a `type:"page"` entry in `/json` with its own per-target WebSocket
debugger, attachable by the same untrusted client. The CDP-layer trust check the desktop fix added is simply absent on
 Android.

### Practical content render on Android Chrome 148 stable

Bounded by Chrome's renderer-side mitigations on the current build:

- **`file://` directory enumeration** — full DOM scrape of Chrome's built-in directory-listing page. Attacker reads
every file name + size + timestamp visible to the Chrome process via `Runtime.evaluate
document.documentElement.outerHTML`, and screenshots the listing via `Page.captureScreenshot`. Wire-confirmed.
- **`devtools://` / `chrome-untrusted://` content render** — renderer redirects to `chrome-error://chromewebdata/`
with `ERR_INVALID_URL` (those WebUI hosts aren't registered on Android stable). The renderer's URL validator
accidentally mitigates this half of the impact today.
- **Individual `file://` content read** — denied by renderer with `ERR_ACCESS_DENIED` (separate DiD).

### Forward-looking risk

Any future Android Chrome that registers additional `chrome-untrusted://...` or `devtools://...` WebUI hosts becomes
**immediately exploitable** without this fix. Chrome ships new internal pages every milestone; the renderer
URL-validator-as-mitigation is brittle. The protocol-layer fix is the correct posture and matches what the desktop fix
 already established.


---

### The cause


#### What version of Chrome have you found the security issue in?

148.0.7778.120 stable (Chrome for Android, com.android.chrome)


#### Is the security issue related to a crash?

No, it is not related to a crash.


#### Choose the type of vulnerability

Privilege Escalation 


#### How would you like to be publicly acknowledged for your report?

LegioSec