CVE-2026-0073: EVP_PKEY_cmp misuse in Wireless ADB gives adjacent attackers shell RCE on Android 14–16

TL;DR

Impact Wireless ADB on Android 14, 15, 16, and 16-qpr2. CVSS 3.1 score 8.8 HIGH

Fix Android security patch level 2026-05-01 or later, or the corresponding Google Play system update

Interim Turn off Wireless Debugging until patched. Audit your network for exposed ADB endpoints, especially on dev devices, office Wi-Fi, and shared test labs

Android’s May 2026 security bulletin disclosed CVE-2026-0073, a Wireless ADB authentication bypass affecting Android 14, 15, 16, and 16-qpr2.
An attacker on an adjacent network can reach shell-user RCE without any user interaction.

Wireless ADB is a developer feature, so everyday phone usage has limited exposure.
But dev devices, QA phones on office Wi-Fi, always-on Android TV boxes, and emulator-plus-device mixed networks are a different story.
I previously wrote about automating emulator tests via an Android MCP server, where ADB was a core dependency. This CVE hits exactly that wireless ADB connection layer.

EVP_PKEY_cmp return value treated as boolean

The bulletin lists this as a Critical RCE in the System component.
The description is terse: a logic error in adbd_tls_verify_cert that bypasses Wireless ADB mutual authentication.
The Project Mainline subcomponent is adbd.

The AOSP fix makes the root cause obvious.
In daemon/auth.cpp, the code fed EVP_PKEY_cmp() directly into an if statement:

-        if (EVP_PKEY_cmp(known_evp.get(), evp_pkey.get())) {
+        int cmp_result = EVP_PKEY_cmp(known_evp.get(), evp_pkey.get());
+        if (cmp_result == 1) {

The commit message reads Fix EVP_PKEY_cmp usage.
The next line explains why: non-zero does not always mean success.

OpenSSL and BoringSSL comparison APIs are not simple boolean functions. EVP_PKEY_cmp returns 1 for a match, 0 for mismatch, and negative values for errors or unsupported key types.
The old code treated any non-zero return as a match. That means -1 (error) and -2 (unsupported operation) both fell through as “keys match.”

Wireless ADB mutual authentication breaks open

Wireless ADB lets you connect to an Android device over local Wi-Fi without a USB cable. You get shell access, app installs, logcat, and file transfers.
The connection is not to an app but to adbd itself, so authenticating the connecting host is the security boundary for the device.

This CVE breaks that boundary.
The certificate comparison that checks “is this host a known ADB client?” accepted non-match return values as matches.
The result: an attacker bypasses Wireless ADB mutual authentication and executes commands as the shell user.

shell is not root, but on Android it is quite powerful.
It covers logcat, debug shell, app data access, and device state queries. Even without root, that is enough to be painful on dev or corporate devices.

Adjacent network as the attack vector

NVD’s CISA-ADP assessment scores this at CVSS 3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, 8.8 HIGH.
AV:A means Adjacent: not reachable from anywhere on the internet, but from the same local network or a directly connected network segment.

Reading this as “remote RCE against all Android phones on the internet” overshoots. But it is not low-risk either.
Office Wi-Fi, conference or event shared Wi-Fi, home LANs, and test lab segments all count as adjacent.
Developers who use ADB tend to leave Wireless Debugging on, which is the uncomfortable part.

runZero has documented network scanning for ADB exposure using queries like protocol:=adb AND os:Android.
On enterprise networks, inventorying ADB-visible Android devices is a faster first step than running a vulnerability scan.

Patch level is 2026-05-01

The bulletin FAQ states that security patch level 2026-05-01 or later includes the fix.
For Android 10 and above, the Google Play system update date may correspond to the same patch level.

Check ro.build.version.security_patch on the device. In the UI this shows as the “Android security update” or “Google Play system update” date.
OEM rollout timelines vary; the AOSP fix being merged does not mean the patch has reached a given device.

If the update is available, apply it.
If not, turn off Wireless Debugging in Developer Options.
For devices that need ADB for testing, isolate them on a dedicated development network away from shared Wi-Fi.