In May 2026, Google disclosed CVE‑2026‑0073 as a Critical vulnerability in the Android System component, specifically the adbd subcomponent (part of the ADB stack). The bulletin states it could lead to remote (proximal) code execution as the shell user with no user interaction required.

At the same time, BARGHEST researchers who discovered it published writeup explaining the root cause.

I have spent some time on this and in this post explain:

• Understand CVE‑2026‑0073,
• testing published PoC exploit,
• who is realistically targeted,
• non-phone targets,
• impact, and
• mitigations.

On top of what will be discussed here, I recorded video with demo tests of published exploit, feel free to take a look how to spot it in the wild.

What is ADB — and what is “Wireless ADB”?

ADB (Android Debug Bridge) is the developer tool that lets a computer communicate with an Android device for debugging: installing apps, running shell commands, reading logs, and more. It’s extremely powerful by design — which is why ADB is normally gated behind explicit developer settings and pairing/authorization.

Wireless ADB / Wireless debugging (introduced in modern Android versions) allows ADB to work over Wi‑Fi using encryption and mutual authentication, instead of the older “open TCP port” approach. In theory, it’s safer and more convenient: you pair once, then connect securely over the local network.

So Wireless ADB is meant to be ADB convenience, without turning your phone into an unauthenticated network service.

CVE‑2026‑0073 breaks part of that promise — under specific conditions.

What is CVE‑2026‑0073?

Wireless debugging is supposed to only allow connections from computers that were previously “paired” (trusted). CVE‑2026‑0073 is a bug where the device’s ADB daemon can mistakenly accept a connection as trusted even when it shouldn’t.

In the most accurate terms, CVE‑2026‑0073 is an authentication bypass in adbd’s TLS certificate verification path (adbd_tls_verify_cert). It can allow an adjacent attacker to be treated as an authorized ADB host and obtain a remote shell as the Android shell user.

Google summarizes the security impact as remote (proximal/adjacent) code execution with no user interaction, that the attacker must be on the same network.

I was able to test this exploit even using rooted Android smartphone running NetHunter and uConsole.

Affected versions

Android Security Bulletin lists CVE‑2026‑0073 as Critical, affecting Android 14, 15, 16, and 16‑qpr2 (System component; adbd subcomponent). Devices with security patch level 2026‑05‑01 or later are addressed.

During my test, for some reason, I was able to exploit Android 13 as well, see Figure 1. Specifically Oppo Reno5 Z.

Not only smartphones

Anything that runs a vulnerable Android build and exposes Wireless debugging/ADB-over-TCP can be potentially in scope.

I was able to successfully pwn my Android tablet, smartwatches and Google Chromecast TV.

Non‑phone Android devices can be affected if they run a vulnerable Android build and have Wireless debugging enabled and reachable — which is more common in dev/test and enthusiast setups than in typical consumer use.

The PoC exploit is public

The PoC exploit is available on GitHub and allows to achieve a shell on targeted device, if all the prerequisites are fulfilled.

Prerequisites for successful exploitation

This is where the “who is at risk” becomes clearer. Across Google’s bulletin, the detailed writeup, and PoC descriptions, the key prerequisites are:

1. Network access
   The attacker must be on the same local network as the device.
2. Wireless debugging / ADB-over-network must be enabled and reachable
   The vulnerable path is in ADB-over-TCP/Wireless debugging.
3. A paired in the past. Device needs to have been paired before with any device (not attacker device).

4. The device must be on a vulnerable build (unpatched)
   Patch level before 2026‑05‑01.

Why “not standard Android users” are the main concern

Most users never:

• enable Developer Options, or
• turn on Wireless debugging.

The vulnerable can be associated with developer workflows and test/repair environments. The PoC explicitly frames the scenario as “device with dev tools and wireless debugging or ADB-over-TCP enabled.”

That’s why the practical target set is usually:

• Android developers and QA engineers
• device farms/test labs
• repair/refurb environments
• security researchers / enthusiasts who keep debugging enabled

This is also why, in enterprise settings, CVE‑2026‑0073 is a bigger deal for BYOD dev populations and engineering device fleets than for the average consumer phone.

Attack scenario

Imagine a co-working space or enterprise office where developers test Android builds.

• A developer enables Wireless debugging to avoid cables.
• The device is on the same Wi‑Fi as other clients (or on a dev VLAN).
• An attacker already on that local network can attempt to establish an ADB session without needing the user to tap “Allow.”
• If the device is vulnerable, the attacker can end up with a remote shell as shell.

This is why “adjacent network” matters: coffee shops, conferences, shared Wi‑Fi, and flat corporate WLANs are exactly where “proximity” becomes realistic.

Impact

Successful exploitation can end up with remote code execution as the shell user with no user interaction.

What that means in practice:

• Install any application without user knowledge
• Escalate privileges to installed apps by enabling Accessibility Services and Notification Access
• Access contact list
• Access SMS
• Call logs
• List of installed apps
• Etc.

Google Pixel devices

I have tested this PoC against three unpatched Pixel devices (4, 8, 10) but I wasn’t able to successfully exploit them.

Mitigations

For individuals (especially developers)

1. Patch to Android security level 2026‑05‑01 or later.
2. Turn off Wireless debugging when not using it.
3. Avoid enabling Wireless debugging on untrusted networks.
4. Protect your Wi-Fi network.

Conclusion

CVE‑2026‑0073 is a reminder that the dangerous vulnerabilities aren’t always exotic memory corruptions — sometimes they’re one-line logic mistakes inside the security boundary of a powerful system tool. In this case, Android’s Wireless debugging trust model can be undermined by a subtle key comparison error, potentially allowing an adjacent attacker to obtain a remote shell session with no user interaction under exposed conditions.

For most people, the practical risk is low because they don’t run ADB over Wi‑Fi. For developers, labs, repair environments, and organizations with debug-enabled devices, the risk can be real.