Android May Restrict Local ADB and Cripple Shizuku

Kitsumed, the developer behind the ShizuCallRecorder app, drew attention to a discussion on the Google IssueTracker, where a Google engineer who maintains ADB floated the idea of restricting local connections to the debug bridge in order to guard against “attackers.” There's no official announcement — it's merely a comment in an open bug tracker — but the potential consequences are significant.

What's being proposed

The trigger was CVE-2026-0073, a vulnerability that allowed wireless ADB authentication to be bypassed entirely. The initial request seemed reasonable: let developers choose which network interface the ADBD daemon listens on, instead of opening up to all networks at once. However, in his reply the Google employee proposed something more drastic — binding ADBD only to the Wi-Fi interface (wlan0), citing the fact that apps had also tried to escalate privileges through the local socket.

That is exactly what raised alarms. Binding solely to wlan0 would break not just “local” ADB, but also operation over VPN, Ethernet and a host of non-standard scenarios.

Why it matters

ADB was designed to link two devices: a phone running the daemon and a separate computer running the client. But not every developer has a second machine. That's how “on-device ADB” came about: you run the client right on the phone (for example, via Termux) and connect to the local daemon at 127.0.0.1. An entire open ecosystem grew out of this trick — libadb-android, App Manager, Canta, aShell and, of course, the popular Shizuku, which grants apps privileged functionality without root.

The author himself uses this mechanism for call recording — a feature Android never got officially and one that helps people with disabilities in particular.

How real is the threat

Kitsumed works through several scenarios and shows that a malicious app cannot bring up an ADB connection on its own. The ADBD daemon isn't running until the user manually enables USB debugging; wireless mode requires a one-time code from the settings, and connecting over TCP/IP puts a confirmation prompt on the screen. In other words, exploitation always requires action from a live human.

The author isn't opposed to having local connections disabled by default, but he objects to banning them outright. He proposes a compromise: a reboot-persistent toggle that third-party apps can't read — otherwise banking apps and games would start blocking devices where on-device ADB is available.

He closes by wryly recalling an old joke of his own — that one day Google would ban local ADB and require a Google account — and admits he nearly called it. The author asks people not to spam the bug tracker: a flood of complaints would only push the developers to close the discussion.

Source: Hacker News