## https://sploitus.com/exploit?id=D14903B5-B80C-5ED0-8E9E-075DDE968863
# ADB TLS Auth Bypass Exploit (CVE-2026-0073)
An automated network scanner and exploitation tool for **CVE-2026-0073**, a vulnerability in the Android Debug Bridge daemon (`adbd`) that allows unauthenticated Remote Code Execution (RCE) and interactive shell access via Wireless Debugging.
This tool is specifically optimized for modern Android devices (Android 13+), featuring **mDNS auto-discovery** to locate randomized ADB ports and a **fully interactive raw PTY shell**.
๐จ Vulnerability Summary (Android Security Bulletin)
CVE ID: CVE-2026-0073
Android Issue ID: A-469080888
Impact: RCE (Remote Code Execution)
Severity: Critical
Officially Affected Versions: Android 14, 15, 16, 16-qpr2 ........ some claimed some android 13 devices are vulnerable
โ ๏ธ **Disclaimer:** *This tool is provided for educational and authorized security research purposes only. Do not use this against networks or devices you do not own or have explicit permission to test.*
---
## ๐ Background & References
Modern Android devices use TLS mutual authentication for Wireless Debugging to prevent unauthorized connections. However, CVE-2026-0073 exposes a cryptographic flaw: when `adbd` processes a client certificate utilizing non-RSA keys (such as Elliptic Curve `ec` or `ed25519`), the internal OpenSSL `EVP_PKEY_cmp` function returns an error code that is improperly handled, effectively **bypassing the authentication check entirely**.
For further reading and deep technical analysis of this vulnerability, check out the following resources:
* **Vulnerability Deep Dive:** [Barghest - CVE-2026-0073 ADB TLS Auth Bypass](https://barghest.asia/blog/cve-2026-0073-adb-tls-auth-bypass/)
* **Real-World Exploitation:** [Mobile Hacker - Android RCE via Wireless Debugging: From Network Access to Shell](https://www.mobile-hacker.com/2026/05/12/android-rce-via-wireless-debugging-from-network-access-to-shell/)
> **Note on Device Susceptibility:** While this bug is generally documented for specific Android versions, real-world testing has shown surprising results across various OEM implementations. As the author of the Mobile Hacker blog noted:
> *"During my test, for some reason, I was able to exploit Android 13 as well, see Figure 1. Specifically Oppo Reno5 Z."*
---
## โ๏ธ Prerequisites
1. **Python 3.7+**
2. **OpenSSL** installed and available in your system's `PATH`.
3. The `zeroconf` Python library (for network scanning).
```bash
# Install the required Python package
pip install zeroconf
```
---
## ๐ Usage
### 1. Automatic Mode (Recommended)
Simply run the script without any arguments. It will listen to the local network for 4 seconds, catch the mDNS broadcasts of any Android devices with Wireless Debugging enabled, and present you with a menu.
```bash
python3 adb_tls_exploit.py
```
**Example Output:**
```text
[*] Scanning local network for Android 13+ devices for 4 seconds...
[+] Found active Android devices:
[1] 192.168.1.15 : 43881 | Pixel 7
[2] 192.168.1.42 : 39105 | Oppo Reno5 Z
Select a device to target [1-2]: 2
============================================================
ADB TLS Auth Bypass -> Interactive Shell
============================================================
[*] Target : 192.168.1.42:39105
[*] Key type : ec
[*] Generating ec self-signed certificate via openssl...
[+] Server requested STLS. Upgrading to TLS...
[+] TLS handshake accepted โ mutual authentication bypassed!
[*] Authenticated! Opening interactive shell service...
[+] Shell obtained! (Press Ctrl+D to exit)
Reno5Z:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb)...
```
### 2. Manual Mode
If you already know the target IP and the randomized port (or if you are targeting a legacy device on port `5555` patched to require TLS), you can bypass the scanner:
```bash
python3 adb_tls_exploit.py [--key ec|ed25519] [--verbose]
# Example
python3 adb_tls_exploit.py 192.168.1.50 42069 --key ec
```
---
## ๐ ๏ธ How it Works (Under the Hood)
1. **mDNS Reconnaissance Phase:** The script utilizes the `zeroconf` library to passively listen for `_adb-tls-connect._tcp.local.` services. This allows it to instantly map targets without noisy or slow TCP port sweeping.
2. **Plaintext Handshake:** The script connects to the target port and sends a standard ADB `CNXN` packet advertising TLS support (`tls_auth`).
3. **STLS Upgrade:** The Android device responds with `STLS`, mandating a secure connection.
4. **The Exploit (TLS Handshake):** The script wraps the socket in TLS and presents a freshly generated, self-signed certificate using an Elliptic Curve (`ec`) or `ed25519` key.
5. **Auth Bypass:** `adbd` attempts to verify the key. Because the key is not RSA, `EVP_PKEY_cmp` returns `-1` or `-2`. The vulnerable code inside Android misinterprets this non-zero return value as a successful cryptographic match.
6. **Stream Multiplexing:** Once the TLS tunnel is established, the tool sends an `OPEN` packet with the `shell\x00` destination, and wires standard input/output streams to your terminal, giving you a full, unprivileged shell (`uid=2000`).
---
## โ ๏ธ Troubleshooting
* **"[-] TLS Handshake rejected" or "certificate_unknown" alert:**
* The device may be patched against CVE-2026-0073 (Security Patch level >= May 2026).
* The device has *never* been paired with an authorized PC before, meaning its `/data/misc/adb/adb_keys` file is completely empty. The exploit requires at least one existing (even unrelated) key in the keystore to trigger the faulty loop comparison.
* **"OpenSSL failed" / "Ensure 'openssl' is installed":**
* You need the OpenSSL binaries installed on your host system (e.g., `apt install openssl`, `brew install openssl`, or installing it via Windows binaries).
* **Scanner finds nothing:**
* Ensure the attacker machine and the Android device are on the exact same Wi-Fi network subnet and AP isolation is disabled.