CVSS 8.8, vector AV:A is one of those cases whenthe adjacent-network RCE in Android receives Critical status fromGoogle. And you know what's the worst thing? The root cause is oneline of the code. CVE-2026-0073- logical error in the function adbd_tls_verify_cert:EC certificate instead of RSA, non-zero return value fromEVP_PKEY_cmp()It is treated as “verification is passed.” No click, no exercise,without application installation - shell from uid=2000 on Android 14,15, 16 and 16-QPR2. When playing in laba, the path from mDNSdetection to interactive shell takes minutes, not a clock. Below -full analysis CVE-2026-0073,root cause, the operation vector ADB daemon, reproduction andcheating checklist.
Before you get into the code - why attacking ADB-shell on someoneelse's Android? Shell user (uid=2000) is not root, but it is beyondthe application sandbox. According to Penligent, from SELinux-contextu:r:shell:s0 are available: system logs,packet status, command execution through pm,am, settings,run-as, creating screenshots andinteraction with system services. For the attacker, it is theextraction of corporate data, VPN accounting, MDM configurations andthe use of the device as a pyot-point for the lateral movement
Targetscenarios for Android zero-click attacks:
NVDcategorizes the vulnerability of ADB Android 2026 as CWE-303(Increct implementation of Authentication Algorithm) Behind thisnumber is an engineering defect that fits in one line.Literally.
Wireless ADB in Android 11+ uses TLS mutualauthentication: when connecting the host presents a certificate, andadbd checksthat the public key from the certificate coincides with the key savedduring pairing. Function adbd_tls_verify_certin auth.cppcalls the OpenSSL functionEVP_PKEY_cmp()(https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_html)to compare the stored RSA key with the key from the client TLScertificate.
According to the PT Security description,EVP_PKEY_cmp()Returns:
And now the most interesting thing.Code in auth.cpp checks the result as aboolean: non-zero meaning is treated as "verification passed".The attacker presents a certificate with an EC P-256 or Ed2519 keyinstead of the expected RSA. EVP_PKEY_cmp()returns a negative value (types incompatible) is not zero, and thecode interprets it as a successful verification.
C:
int result = EVP_PKEY_cmp(stored_rsa_key, client_cert_key);
if (result)
This countice bug class – type when interpreting return value –is documented and met in other projects. I’ve seen something likethis in the TLS generic processing code at least twice in the lastfew years, and each time I wonder how this is the revue. adbdincluded in Project Mainline as APEX module com.android.adbd(Android 11+), which allows Google to deliver a patch through GooglePlay system updates, bypassing OEM certification. This significantlyreduced the vulnerability window compared to the standard updateprocess through vendors.
An additional vector fixed by PTSecurity: in addition to the authentication bypass, there areseparate information about the memory corruption in the logic ofparsing packages during mDNS / SSD detection - integer underflow inchecking the boundaries of service packages can lead to heap-basedbuffer overflow and remote execution of Android code. This is aseparate problem from the main bypass of authentication, but itexpands the attack surface.
For a penesster, it is critical to understand at what level of theprotocol ADB exploit occurs. Wireless debugging in Android 11+ - not"ADB on TCP 5555" from the era of Android 4, where therewas no authentication at all (and yes, those times are rememberedwith nostalgia). The modern protocol adds a full-fledged TLS layer:
CVE-2026-0073Breaks step 5. After bypassing the verification, ADB behaves as if anauthorized developer is connected - no additional checks, nonotifications to the user. Unlike USB connection, where anauthorization dialog appears, wireless ADB does not generate visualindicators after TLS-authenification. The owner of the device doesnot see anything and can not deviate the connection - zero-click inits pure form.
The Old Regime adbtcpip 5555 (without authentication) is still found on customfirmware and Android-based: TVs, smart speakers, industrial panels.According to Penligent, Android-based appliances is often morevulnerable than phones - updates come late or do not come at all.
Thevulnerability fits into the kill chain of the Android mobile pentest.Here is what it looks like in practice:
InitialAccess - ExternalRemote Services (T1133): Connecting to the ADB port from theadjacent network. For devices with permanent Wi-Fi - alsopersistence. Also applicable Exploitationof Remote Services (T1210) with pivot through a compromiseddevice.
Execution- UnixShell (T1059.004): interactive shell after bypassingauthentication. NativeAPI (T1106): system APIs are available through ADB to installpackages, process and services management.
Discovery- SystemInformation Discovery (T1082): getprop,dumpsys, pmlist packages give a complete picture ofthe device - the OS version, patch-leavil, list of applications,network configuration.
PrivilegeEscalation - Exploitationfor Privilege Escalation (T1068): shell-access (uid=2000) opensthe way to local privesc through kernel-vulnerability ormisconfiguration.
What precedes: network reconnaissance -nmap/masscanTCP 5555 and high port range, mDNS-browse for detecting wirelessdebugging. What should be done: install backdoor APK via adbinstall -r,retrieval of data, pivot tothe corporate network through VPN configurations or corporatecertificates available from the shell-context.
This Android zero-click RCE vulnerability is not a magic buttonfor any device. Here are the specific boundaries.
Worksif:
Does not work if:
CISAclassifies decision as Track marked by expendable: none automatable:no. No mass exploitation was recorded at the time of the assessment.But a few PoCs have already been published on GitHub:SectestAnnaQuinn/CVE-2026-0073-Android-add-aventication-bypass-POC(79 stars), adityatelage/poc-CVE-2026-0073(51 stars), MartinPSDev/CVE-2026-0073-Android-ADBD-bypass-POC(18 stars) - the last description of the type through EC/Ed25519keys. Public PoCs with a detailed description of the vector lower theentry threshold, so "exploitation: none" is a matter oftime.
Wireless ADB announces itself via mDNS.Detection - via mDNS-browse or direct scanning of TCP ports. Modernwireless debugging uses a random port from a high range, but the goodold 5555 is still found on devices with adbtcpip.
Bash:
avahi-browse -r _adb-tls-connect._tcp
nmap -sV -p 5555,37000-44000 --open 192.168.1.0/24
The essence of the operation of ADB daemon is to present acertificate with an EC key instead of the RSA. The self-signed ECP-256 certificate is generated by standard OpenSSL means. Public PoCs(adityatelange/poc-CVE-2026-0073,MartinPSDev/CVE-2026-0073-Android-ADDB-bypass-POC) automate theentire process: key generation -> TCP-connection -> STLS ->TLS handshake with EC certificate -> ADB shell.
PoC installs a TCP connection with the detected port, performsSTLS-negotiation, presents an EC certificate. Defective checking inadbd_tls_verify_cert returns a non-zerovalue - and PoC receives a full-fledged authorized ADB-session. Themagic is that -1 ! = 0, which means if (result)works.
Bash:
id
uid=2000(shell) gid=2000(shell) context=u:r:shell:s0
getprop ro.build.version.security_patch
pm list packages -3
After receiving shell from the context uid=2000 available: flipsystem properties, pack analysis, screenshots through screencap.Installation of APK without promotions to the user. For thetransition to privilege escalation - analysis of the kernel andsystem components for additional vulnerabilities through run-asfor debuggable applications.
The TLS tunnel hides the contents of the ADB-session from networkIDS - detection is possible only by metadata: the fact of TLShandshake on the ADB port, the type of key in the client certificate(if TLS inspection), the anomalous duration of the session. At theendpoint level, Android does not generate a push notification whenconnected via wireless ADB (unlike USB debugging). This is the systemrestriction of the detect on the side of the device, and nothing hasyet been done with it.
Business logic of attack: why shell on Android via Wi-Fi
Before you get into the code - why attacking ADB-shell on someoneelse's Android? Shell user (uid=2000) is not root, but it is beyondthe application sandbox. According to Penligent, from SELinux-contextu:r:shell:s0 are available: system logs,packet status, command execution through pm,am, settings,run-as, creating screenshots andinteraction with system services. For the attacker, it is theextraction of corporate data, VPN accounting, MDM configurations andthe use of the device as a pyot-point for the lateral movement
Targetscenarios for Android zero-click attacks:
- Corporate office, conference, hotel - attacker connects to common Wi-Fi, detects devices with wireless debugging through mDNS, operates CVE-2026-0073 and receives a springboard inside the perimeter
- Android devices in kiosk mode - POS-terminals, digital signs, field tablets. According to DecryptionDigest, these devices often operate in fixed networks with predictable addresses and included diagnostic services
- BYOD is a personal Android device for employees in corporate Wi-Fi, where updates lag behind the bulletin for weeks or months. According to the IBM X-Force Threat Intelligence Index 2025, the average time between the publication of CVE and the elimination of 29 months in organizations
Root Cause CVE-2026-0073: type in EVP_PKEY_cmp
NVDcategorizes the vulnerability of ADB Android 2026 as CWE-303(Increct implementation of Authentication Algorithm) Behind thisnumber is an engineering defect that fits in one line.Literally.
Wireless ADB in Android 11+ uses TLS mutualauthentication: when connecting the host presents a certificate, andadbd checksthat the public key from the certificate coincides with the key savedduring pairing. Function adbd_tls_verify_certin auth.cppcalls the OpenSSL functionEVP_PKEY_cmp()(https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_html)to compare the stored RSA key with the key from the client TLScertificate.
According to the PT Security description,EVP_PKEY_cmp()Returns:
- 1- the keys coincide
- 0- the keys do not match
- Negative value (-1 or -2) - error or incompatible key types
And now the most interesting thing.Code in auth.cpp checks the result as aboolean: non-zero meaning is treated as "verification passed".The attacker presents a certificate with an EC P-256 or Ed2519 keyinstead of the expected RSA. EVP_PKEY_cmp()returns a negative value (types incompatible) is not zero, and thecode interprets it as a successful verification.
C:
int result = EVP_PKEY_cmp(stored_rsa_key, client_cert_key);
if (result)
This countice bug class – type when interpreting return value –is documented and met in other projects. I’ve seen something likethis in the TLS generic processing code at least twice in the lastfew years, and each time I wonder how this is the revue. adbdincluded in Project Mainline as APEX module com.android.adbd(Android 11+), which allows Google to deliver a patch through GooglePlay system updates, bypassing OEM certification. This significantlyreduced the vulnerability window compared to the standard updateprocess through vendors.
An additional vector fixed by PTSecurity: in addition to the authentication bypass, there areseparate information about the memory corruption in the logic ofparsing packages during mDNS / SSD detection - integer underflow inchecking the boundaries of service packages can lead to heap-basedbuffer overflow and remote execution of Android code. This is aseparate problem from the main bypass of authentication, but itexpands the attack surface.
Wireless ADB protocol and point of authentication failure
For a penesster, it is critical to understand at what level of theprotocol ADB exploit occurs. Wireless debugging in Android 11+ - not"ADB on TCP 5555" from the era of Android 4, where therewas no authentication at all (and yes, those times are rememberedwith nostalgia). The modern protocol adds a full-fledged TLS layer:
- Device with an included wireless debugging listens to a randomly assigned TCP port and declares itself through mDNS (_adb-tls-connect._tcp)
- Host installs TCP connection to the discovered port
- STLS-negotiation - upgrade connection to TLS
- Host presents a client TLS certificate
- adbd_tls_verify_certcompares the key from the certificate with the repository of trusted keys - here CVE-2026-0073
- When "success" - within the TLS tunnel begins a standard ADB-frimming
- The attacker opens the shell-service and receives uid=2000
CVE-2026-0073Breaks step 5. After bypassing the verification, ADB behaves as if anauthorized developer is connected - no additional checks, nonotifications to the user. Unlike USB connection, where anauthorization dialog appears, wireless ADB does not generate visualindicators after TLS-authenification. The owner of the device doesnot see anything and can not deviate the connection - zero-click inits pure form.
The Old Regime adbtcpip 5555 (without authentication) is still found on customfirmware and Android-based: TVs, smart speakers, industrial panels.According to Penligent, Android-based appliances is often morevulnerable than phones - updates come late or do not come at all.
The place CVE-2026-0073 in the attack chain
Thevulnerability fits into the kill chain of the Android mobile pentest.Here is what it looks like in practice:
InitialAccess - ExternalRemote Services (T1133): Connecting to the ADB port from theadjacent network. For devices with permanent Wi-Fi - alsopersistence. Also applicable Exploitationof Remote Services (T1210) with pivot through a compromiseddevice.
Execution- UnixShell (T1059.004): interactive shell after bypassingauthentication. NativeAPI (T1106): system APIs are available through ADB to installpackages, process and services management.
Discovery- SystemInformation Discovery (T1082): getprop,dumpsys, pmlist packages give a complete picture ofthe device - the OS version, patch-leavil, list of applications,network configuration.
PrivilegeEscalation - Exploitationfor Privilege Escalation (T1068): shell-access (uid=2000) opensthe way to local privesc through kernel-vulnerability ormisconfiguration.
What precedes: network reconnaissance -nmap/masscanTCP 5555 and high port range, mDNS-browse for detecting wirelessdebugging. What should be done: install backdoor APK via adbinstall -r,retrieval of data, pivot tothe corporate network through VPN configurations or corporatecertificates available from the shell-context.
Preconditions and Restrictions on ADB Daemon
This Android zero-click RCE vulnerability is not a magic buttonfor any device. Here are the specific boundaries.
Worksif:
- Android 14, 15, 16 or 16-QPR2 without security patch level 2026-05-01
- Wireless debugging included in Developer Options
- Attacking in the same L2-net (Wi-Fi, Ethernet bridge) or within wireless reach
- ADB TCP Port Not Blocked by MDM Policy or Firewall
Does not work if:
- Wireless debugging is off (by default disable on consumer devices - and this saves most)
- Client isolation is active on Wi-Fi AP (blocks L2-interaction)
- Device updated to patch level 2026-05-01 or newer
- Developer options disabled via EMM-policy
- Device for NAT without direct L2-access to the port
CISAclassifies decision as Track marked by expendable: none automatable:no. No mass exploitation was recorded at the time of the assessment.But a few PoCs have already been published on GitHub:SectestAnnaQuinn/CVE-2026-0073-Android-add-aventication-bypass-POC(79 stars), adityatelage/poc-CVE-2026-0073(51 stars), MartinPSDev/CVE-2026-0073-Android-ADBD-bypass-POC(18 stars) - the last description of the type through EC/Ed25519keys. Public PoCs with a detailed description of the vector lower theentry threshold, so "exploitation: none" is a matter oftime.
Android zero-click attack in the laboratory
Adjustmentsto the environment
- Target device: Android 14+ with wireless debugging (physical device or AOSP-emulator)
- Attacker Host: GNU/Linux (Kali/Ubuntu 22.04+), packages adb, nmap, openssl, Python 3.8+
- RAM: 8 GB minimum when using emulator, 4 GB - for working with a physical device
- Network: Both devices in one L2-subnet. Recommended separate Wi-Fi AP without access to the Internet for complete isolation
- Legal context: only own devices in an isolated laboratory environment
Step1: Detection of Targets
Wireless ADB announces itself via mDNS.Detection - via mDNS-browse or direct scanning of TCP ports. Modernwireless debugging uses a random port from a high range, but the goodold 5555 is still found on devices with adbtcpip.
Bash:
avahi-browse -r _adb-tls-connect._tcp
nmap -sV -p 5555,37000-44000 --open 192.168.1.0/24
Step 2: preparationof an EC certificate
The essence of the operation of ADB daemon is to present acertificate with an EC key instead of the RSA. The self-signed ECP-256 certificate is generated by standard OpenSSL means. Public PoCs(adityatelange/poc-CVE-2026-0073,MartinPSDev/CVE-2026-0073-Android-ADDB-bypass-POC) automate theentire process: key generation -> TCP-connection -> STLS ->TLS handshake with EC certificate -> ADB shell.
Step 3:Operation
PoC installs a TCP connection with the detected port, performsSTLS-negotiation, presents an EC certificate. Defective checking inadbd_tls_verify_cert returns a non-zerovalue - and PoC receives a full-fledged authorized ADB-session. Themagic is that -1 ! = 0, which means if (result)works.
Step 4:Validation of access
Bash:
id
uid=2000(shell) gid=2000(shell) context=u:r:shell:s0
getprop ro.build.version.security_patch
pm list packages -3
After receiving shell from the context uid=2000 available: flipsystem properties, pack analysis, screenshots through screencap.Installation of APK without promotions to the user. For thetransition to privilege escalation - analysis of the kernel andsystem components for additional vulnerabilities through run-asfor debuggable applications.
Detection of operation and hardening ADB daemon
Networksignals for SOC
- TCP-connections to wireless ADB ports from subnets without legitimate dev-stez.
- mDNS-queries to _adb-tls-connect._tcpfrom the user VLAN - red flag
- On the device: logcatFixes ADB-connections. Connections from unauthorized MAC/IP in the absence of a pairing record - a compromise indicator
- For SIEM-correlation: new ADB-connection + TLS client certificate with EC/Ed25519 instead of RSA + no pairing recording in device logs
- Suricata/Zeek: ADB-protocol detect (signature CNXNafter TLS handshake) on non-standard ports
Restrictionsof detection
The TLS tunnel hides the contents of the ADB-session from networkIDS - detection is possible only by metadata: the fact of TLShandshake on the ADB port, the type of key in the client certificate(if TLS inspection), the anomalous duration of the session. At theendpoint level, Android does not generate a push notification whenconnected via wireless ADB (unlike USB debugging). This is the systemrestriction of the detect on the side of the device, and nothing hasyet been done with it.
