A public proof-of-concept (PoC) exploit has been released for CVE-2026-0073, a critical zero-click vulnerability in Android’s ADB daemon (adbd) that allows any attacker on the same local network to obtain a full shell on a target device — without any interaction from the device owner, without prior pairing, and without triggering any visible alerts on the device.
Google addressed the vulnerability in the Android Security Bulletin for May 2026, released on May 1, 2026. However, the availability of a working public PoC now dramatically raises the urgency for all Android users and administrators of Android device fleets to verify that the May security patch level has been applied.
Background: What Is Android’s ADB Daemon?
The Android Debug Bridge (ADB) is a developer tool that enables communication between a computer and an Android device for debugging, app installation, and shell access. Since Android 11, wireless ADB (over Wi-Fi) has become a standard developer feature, allowing devices to be debugged over the local network using a mutual TLS (mTLS) authentication handshake to ensure only previously paired and trusted hosts can connect.
CVE-2026-0073 breaks this trust model entirely.
The Root Cause: A Cryptographic Logic Error
The vulnerability was discovered by researchers at BARGHEST Security and stems from a critical logic error in the adbd_tls_verify_cert function within Android’s auth.cpp source file.
During the wireless ADB mTLS handshake, the daemon uses the EVP_PKEY_cmp API from OpenSSL to compare the public key in the connecting client’s TLS certificate against the list of previously authorized RSA keys stored on the device. The intended behavior is that only clients whose public key matches a stored authorized key should be granted access.
Here is where the flaw lies: when an attacker presents a TLS certificate carrying a non-RSA public key — such as an EC P-256 or Ed25519 key — the EVP_PKEY_cmp function returns -1 to signal a type mismatch (RSA vs. non-RSA). However, in C and C++, any non-zero integer value evaluates as true in a boolean context. The adbd code incorrectly interprets this -1 return value as a successful match, setting authorized = true and granting the attacker a full ADB shell session.
Attack Scenario: No User Interaction Required
To exploit CVE-2026-0073, an attacker needs to be on the same local network as the target device and the target device must have wireless ADB enabled (port 5555). This is the default state for any Android device with Developer Options and Wireless Debugging enabled — a configuration common among developers, IT administrators managing enterprise device fleets, and technically engaged consumers.
The attacker:
- Connects to the same Wi-Fi network as the target Android device
- Discovers the target’s IP address and ADB port (trivial on most networks)
- Generates or presents a TLS client certificate with an EC or Ed25519 public key (rather than the expected RSA key)
- Initiates the ADB connection — the daemon grants shell access due to the cryptographic comparison bug
- Executes commands on the device with
shelluser privileges
The device owner sees nothing. No pairing dialog appears. No confirmation is requested. The entire attack sequence is silent and zero-click.
Public PoC Now Available
A fully functional Python-based proof-of-concept exploit for CVE-2026-0073 has been published to GitHub by security researcher MartinPSDev under the repository CVE-2026-0073-Android-ADBD-bypass-POC. The PoC demonstrates the EC/Ed25519 key mismatch exploit in a clear and reproducible way, significantly lowering the barrier to exploitation for less skilled attackers.
The availability of working public exploit code means that organizations should assume that opportunistic scanning for exposed ADB ports (TCP/5555) will increase in the coming days, and devices that have not yet received the May 2026 security patch are at real risk.
Affected Android Versions
CVE-2026-0073 affects all major recent Android versions:
- Android 14
- Android 15
- Android 16
- Android 16-QPR2
Google resolved the vulnerability at the 2026-05-01 security patch level. Devices that have applied this or any later patch level are protected.
How to Check and Protect Yourself
- Check your Android security patch level: Navigate to Settings > About Phone > Android Security Update. Ensure the patch level is 2026-05-01 or later.
- Disable Wireless Debugging when not in use: In Developer Options, disable Wireless Debugging if you do not actively need it. This completely removes the attack surface.
- Disable Developer Options entirely on devices not used for development.
- Enterprise MDM policies: Administrators managing Android enterprise fleets should enforce patch level compliance and restrict Developer Options via MDM profile policies.
Conclusion
CVE-2026-0073 is a reminder that even well-established security mechanisms like mutual TLS authentication are only as strong as the correctness of the code that implements them. The combination of a cryptographic logic error in a type comparison, a zero-click exploitation path, and a now-public PoC makes this a high-urgency patch. Android users and enterprise fleet administrators should verify that the May 2026 security update has been deployed without delay.