Proof-of-concept published for CVE-2026-0073 Android ADB authentication bypass

Android’s ADB daemon is supposed to be a developer tool. It gives a trusted computer deep control over a phone for testing, debugging, and maintenance. But CVE-2026-0073 breaks the trust check in a very specific corner of that system — and now there are public proof-of-concept tools showing how to turn that bug into shell access on vulnerable devices. Google shipped a fix in the May 2026 Android Security Bulletin, but the publication of working PoCs changes the risk immediately. ### What part of Android is this about? This is about `adbd`, the Android Debug Bridge daemon — the service that listens for ADB connections. On modern Android, wireless debugging lets a computer connect over the local network instead of a USB cable. That connection is supposed to be protected by pairing and mutual TLS authentication, so only an approved host can talk to the device like a debugger. (source.android.com) ### What actually broke? The bug sits in certificate verification. Android stores paired ADB host keys as RSA public keys, then compares them with the public key from the client certificate presented during the TLS handshake. The catch is that the comparison function, `EVP_PKEY_cmp`, does not behave like a simple true-or-false match. It returns `1` for a real match, `0` for a same-type mismatch, and negative values for errors or unsupported comparisons — including key-type mismatch. (barghest.asia) Vulnerable code treated any nonzero value as success. ### Why does that become a bypass? Because an attacker can present a non-RSA certificate — like EC P-256 or Ed25519 — against a stored RSA ADB key. That cross-algorithm comparison returns a negative value, and the vulnerable code reads that as “matched.” Basically, Android confuses “these keys are not even comparable” with “this host is trusted.” Once that happens, the attacker gets treated like an authorized ADB client. (barghest.asia) ### What can the attacker get? Not full kernel compromise — but ADB shell is still serious. Google describes the impact as remote code execution in the System component as the shell user, with no user interaction needed, assuming the relevant development-oriented protections are enabled or bypassed. Public PoC authors show commands like `id`, `whoami`, and `getprop` running successfully, which confirms practical shell access. From there, an attacker can inspect logs and properties, interact with packages, and potentially pivot into debuggable apps or other follow-on abuse. (barghest.asia) ### Does every Android phone have this problem? No — and that matters. The attack needs the ADB TCP path to be reachable. In practice that usually means wireless debugging or ADB-over-TCP is enabled, the attacker is on the same network or otherwise adjacent, and the device has an eligible paired-host key state. This is not a drive-by internet bug for ordinary phones sitting untouched in pockets. It is much more relevant to developers, test devices, enterprise labs, shared Wi‑Fi environments, and any fleet where debugging gets left on. (source.android.com) ### What changed this week? The fix was already in Google’s May 2026 bulletin, but public exploit code is now easy to find on GitHub. One PoC walks through the whole flow — connect to the target ADB service, negotiate `STLS`, present a non-RSA client cert, then open a shell service and run a command. Another repo adds a scanner, which is the part defenders hate, because it lowers the skill needed to find and test exposed devices. (barghest.asia) ### What should defenders do now? Patch first — devices with the 2026-05-01 Android security patch level or later include the fix. Then turn off wireless debugging anywhere it is not actively needed, and check for devices exposing ADB over TCP on local networks. This is one of those bugs where the exploit idea is subtle, but the mitigation is boring and direct — update, reduce exposure, and stop leaving dev pathways open on production devices. (github.com) ### Bottom line The big news is not just that CVE-2026-0073 exists. It’s that the bug has moved from bulletin text to copyable exploit code. That shrinks the gap between “interesting vulnerability” and “real operational problem” — especially for Android devices used by developers, testers, and enterprise admins. (source.android.com)