Android’s proposed ADB fix could break the tools that make Android usable without root
A Google ADB maintainer floated binding the debugging daemon only to Wi-Fi after a wireless-debugging flaw. That would also cut off the loopback connection used by Shizuku, Termux workflows, and a small ecosystem of rootless Android tools.
The proposed ADB change answers a real security concern, but it treats on-device debugging as collateral damage. The author argues that an app cannot silently create the necessary ADB session: the user must already enable debugging and complete pairing or approve a prompt.
HN split between people who see a long-overdue hardening and people who see another capability disappearing from a nominally open OS.
A security fix with a large blast radius
An ongoing Android IssueTracker discussion concerns where adbd, Android’s debugging daemon, listens. The immediate context is CVE-2026-0073, a flaw that could bypass Wireless ADB authentication. The proposed interface-selection feature is sensible; the more consequential suggestion is to bind only to the Wi-Fi interface.
That would rule out loopback ADB: a client such as Termux running on the same phone connects to adbd at 127.0.0.1. It is the mechanism behind Shizuku and other rootless tools that can perform carefully granted system-level tasks. The post’s important distinction is between disabling that path by default and removing it permanently.
The author walks through the preconditions: ADB must already be enabled, and Wireless Debugging requires a pairing code while legacy TCP/IP still asks for authorization. That does not make the attack surface imaginary, but it makes a blanket claim that ordinary malicious apps can simply seize it incomplete.
The thread argues over whose threat model counts
A commenter who favors the hardening says that a self-connection is itself a design smell: the capabilities should be deliberately granted to an app or blocked. Another reader points to a different risk model—an unlocked phone in the hands of a border officer, teacher, or other temporary custodian—where a low-friction local attack can be automated.
"This attack vector requires both that the user enabled developer settings and that they have remote adb enabled." — an engineer weighing the prerequisites
The useful policy question is narrower than ‘security versus openness’: can Android ship loopback ADB off by default, retain a persistent opt-in, and keep third-party apps from detecting or exploiting that choice? If it cannot, a fix for one vulnerability becomes a product decision about which advanced users may still own their devices.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
Open-weight AI needs more than weights to get its Kubernetes moment
The Kubernetes analogy is attractive: a portable model can attract runtimes, fine-tunes, evaluation tools, and vendors around it. But models remain expensive to run and lack the neutral governance that made Kubernetes a shared substrate.