Independent Replication of CVE‑2026‑0073: A Study in ADB Protocol Authentication Bypass

Abstract

This report documents the independent re‑implementation of an exploit for CVE‑2026‑0073, a critical authentication bypass in the Android Debug Bridge daemon (adbd). The vulnerability arises from a type‑confusion error in the comparison of TLS client certificate public keys, enabling an unauthenticated network peer to obtain an ADB shell. The goal of this work was not to produce a novel attack, but to achieve a deep, practical understanding of the vulnerability through hands‑on reproduction on a physical device. We describe the ADB‑over‑TLS protocol, the logical defect in adbd_tls_verify_cert(), and the practical challenges encountered when targeting a Samsung Galaxy A22 (SM‑A225F). My experience highlights the gap between theoretical vulnerability descriptions and the engineering demands of real‑world exploit development, underscoring the value of independent replication in security research.

1. Introduction

On 5 May 2026, the Android Security Bulletin disclosed CVE‑2026‑0073, a critical‑severity vulnerability in the ADB daemon’s TLS authentication path. The flaw permits a remote, unauthenticated attacker on the local network to bypass ADB host verification and execute arbitrary commands as the shell user. The original discovery and detailed analysis were published by BARGHEST, whose work provided both a lucid explanation of the bug and a functional proof‑of‑concept.

While the public availability of an exploit makes the vulnerability accessible, the educational value of reconstructing such an exploit from first principles is substantial. This report presents our independent effort to replicate the attack against a Samsung Galaxy A22, a mid‑range device running Android 13. We emphasize that no new vulnerability is claimed; rather, we document the protocol intricacies, implementation obstacles, and lessons learned during the replication process. All findings are consistent with the public advisory, and no unpatched devices beyond the tested unit were targeted.

2. Background

2.1 ADB Wireless Debugging

Modern Android devices support wireless debugging, which exposes the ADB service over TCP. The connection process involves several phases:

1. Plaintext ADB handshake: The client sends a CNXN packet advertising supported features, including tls_auth. The device responds with an STLS packet, indicating that the transport must be upgraded to TLS.

2. TLS 1.3 mutual authentication: The client initiates a TLS 1.3 handshake and presents a client certificate. The server (adbd) verifies this certificate against the set of authorized host keys stored in /data/misc/adb/adb_keys.

3. Post‑TLS ADB exchange: Upon successful verification, normal ADB packets flow inside the encrypted tunnel, allowing the client to open service streams (e.g., a shell).

The critical security property is that only a host possessing the private key corresponding to a previously paired RSA public key should be able to complete the TLS handshake.

2.2 The Vulnerability (CVE‑2026‑0073)

The vulnerability resides in the function adbd_tls_verify_cert() within the ADB module’s auth.cpp. The relevant code fragment (prior to patching) is:

c

if (EVP_PKEY_cmp(known_evp.get(), evp_pkey.get())) {
    VLOG(AUTH) << "Matched auth_key=" << public_key;
    verified = true;
}

EVP_PKEY_cmp() returns an integer with the following semantics:

• 1 – keys are equal

• 0 – keys of the same type differ

• -1 – key types differ

• -2 – operation not supported

In C, any non‑zero value evaluates to true in a conditional context. Therefore, when the function returns -1 (indicating different key types), the condition if (EVP_PKEY_cmp(...)) still succeeds—because -1 is truthy. This allows an attacker who presents a certificate with a non‑RSA key (e.g., EC or Ed25519) against a stored RSA key to satisfy the check and be incorrectly authorized. The fix, distributed in the May 2026 security patch, changes the condition to EVP_PKEY_cmp(...) == 1, so that only an exact match grants access.

3. Methodology

We undertook a from‑scratch implementation of the exploit in Python, using only the cryptography library for certificate generation and Python’s standard ssl module for the TLS handshake. The target device was a Samsung Galaxy A22 (SM‑A225F) running Android 13 with security patch level prior to May 2026. The device had previously been paired via USB, ensuring at least one RSA key in the trust store.

The implementation was broken into three phases:

1. ADB transport emulation: Implementing the packet framing, checksums, and the CNXN/STLS exchange.

2. TLS handshake with a cross‑type certificate: Generating a self‑signed EC P‑256 certificate and integrating it into a TLS 1.3 client context.

3. Post‑TLS service access: Opening a shell stream and reading command output.

4. Implementation Challenges

Despite the conceptual simplicity of the bug, practical exploitation demanded careful attention to protocol details and device‑specific behaviour.

4.1 TLS Version Requirements

The initial development environment utilized the system Python, which was linked against LibreSSL 2.8.3. This library does not support TLS 1.3, which the target device required. The problem was resolved by creating a virtual environment that used a Homebrew‑installed OpenSSL 3.6.2, which provides full TLS 1.3 support.

4.2 Samsung‑Specific STLS Flooding

The most significant obstacle emerged after the TLS handshake. The Samsung A22 emitted a continuous stream of STLS packets before sending the expected CNXN banner. In a naïve implementation, the main thread blocked while waiting for CNXN, causing timeouts. Experiments with background draining threads and manual pre‑drains did not fully resolve the issue.

The key insight came from observing that the device would accept a service OPEN request even before sending its own CNXN. By transmitting the OPEN shell:<command> packet immediately after the TLS handshake—without waiting for any device‑initiated messages—the host elicited both the CNXN (confirming authentication bypass) and an OKAY for the shell in immediate succession. This ordering inverted the intuitive “receive then send” sequence and circumvented the STLS flood entirely.

4.3 Stream Management

Once the shell stream was established, standard ADB flow control was required: acknowledging WRTE packets with OKAY and terminating on CLSE. Stray STLS packets continued to appear during the session, necessitating a filtering loop that discarded them silently. With these final adjustments, command execution became reliable.

5. Results

The final implementation consistently demonstrated the authentication bypass and obtained command execution on the Samsung A22. The following is sample output:

The exploit achieved remote code execution as the shell user in the u:r:shell:s0 SELinux context, consistent with the impact described in the original advisory.

I built out the PoC with a few variations to see the impact and here you can see that I was able to launch chrome and open a link to my website at thejasongardner.com.

6. Discussion

The replication effort illuminated several important aspects of vulnerability research:

• Protocol state machines are fragile. The ADB‑over‑TLS handshake is not purely linear; implementations may interleave STLS notifications, requiring adaptive message ordering.

• Library dependency management is critical. A mismatch between development and target environments (LibreSSL vs. OpenSSL) can stall progress, underscoring the importance of reproducible build configurations.

• Independent replication is a powerful learning tool. While the vulnerability itself is well‑understood, the engineering process of reconstructing the exploit deepened our understanding of both the bug and the Android ADB architecture.

It is noteworthy that the Samsung A22 exhibited the STLS flooding behavior, which was not detailed in public write‑ups. This device‑specific quirk does not constitute a new vulnerability, but it illustrates the diversity of real‑world implementations and the challenge of creating universally robust exploits.

7. Conclusion

We have successfully replicated CVE‑2026‑0073 on a Samsung Galaxy A22, confirming the vulnerability’s exploitability under the documented pre‑conditions. The project served as an educational exercise in protocol analysis, cryptographic API pitfalls, and the practical art of exploit development. All credit for the original discovery belongs to BARGHEST and the Android security team; this work is merely a reconstruction that validates and learns from their findings.

Acknowledgements

The authors thank BARGHEST for their detailed public analysis of CVE‑2026‑0073 which helped with my analysis.

---

Disclaimer: No novel vulnerabilities are disclosed in this report. The described exploit relies on a publicly known, patched issue. The author does not distribute exploit code and does not encourage unauthorized access to devices. Author encourages users to update to the latest security patch as per Android "Security patch levels of 2026-05-01 or later address all issues associated with the 2026-05-01 security patch level". https://source.android.com/docs/security/bulletin/2026/2026-05-01