Cross-App OTP / Credential Leak

← Insecure Authentication / Authorization

cross_app_otp_credential_leak   MEDIUM

Description

A co-resident malicious app can read OTP codes / auth deep links from this app via an unprotected exported component, broadcast, or shared clipboard (Authenticator CVE-2026-26123 class).

How it works

A 2FA authenticator publishes the current OTP and an auth deep link (myauth://login?otp=…&token=…) to an unprotected cross-app surface. Because that surface has no access control, any co-resident app can harvest the second factor, the Authenticator CVE-2026-26123 class. On Android this is an unprotected broadcast the companion com.dvma.attacker app receives; the iOS peer is a shared pasteboard, custom URL scheme, or App Group. A secure design gates delivery behind a signature-level permission (or a private, per-recipient channel) so an arbitrary app gets nothing.

How to exercise it. DVMA is the harness - open this module from the home index and tap the demo action. The screen ships the malicious input and simulates the attacker (e.g. the companion app, crafted intent, or scanned payload) in-process, and the evidence panel prints the proof. The Tools (optional) and Attack inputs below are only needed to reproduce the exploit end-to-end on a real device.

Real cross-app demo (not a simulation). On Android this fires an unprotected broadcast from DVMA’s native MethodChannel, and a separate, unprivileged app (com.dvma.attacker - its own package/UID/signing key) harvests the OTP + auth deep link across the process boundary. The permission-scoped button gates delivery behind a signature-level permission, so the differently-signed attacker gets nothing.

One-command demo (from the repo root):

1	automation/scripts/demo.sh otp

Watch the attacker harvest it: adb logcat -s DVMA-ATTACKER:* (or the pulled file attacker_captures.txt). CI-grade regression: DvmaCrossAppOtpLeakTest. See companion/dvma-attacker/README.md.

Exploit steps

1. Set up. Build DVMA with a flavor that enables the Insecure Authentication / Authorization category (e.g. --dart-define-from-file=config/flavors/dev.json) and run on an emulator/simulator you control. The demo needs no external tooling; for the optional on-device reproduction the relevant tools are: Android: jadx, adb, drozer · iOS: idevicesyslog, idb.
2. Locate the target. From the home index, open Cross-App OTP / Credential Leak (cross_app_otp_credential_leak). The How it works section above describes this module’s specific weakness; the screen states the intended-secure behavior and exposes the vulnerable action.
3. Exploit. Drive the authentication/authorization path, capture the token / assertion / decision, then replay or tamper with it (mitmproxy, a WebAuthn test harness, or by editing the value) and confirm the server-side check accepts the manipulated request.
4. Observe the evidence. Trigger the vulnerable action and read the evidence panel - it prints the concrete proof (leaked value, accepted replay, executed payload, or unauthorized result).
5. Contrast with the secure path. Run the module’s secure/hardened action (where provided) and confirm the same attack is rejected - this is what a correct implementation should do.
6. Map it back. Cross-reference the MASTG v2 test(s) MASTG-TEST-0366, MASTG-TEST-0364, MASTG-TEST-0374 for the canonical procedure and remediation.

Tools (optional)

Android

• jadx
• adb
• drozer

iOS

• idevicesyslog
• idb

Attack inputs

Payloads/artifacts you author for the on-device attack. The demo already ships and simulates these in-process (e.g. the malicious companion app / crafted intent is emulated inside the screen), so you only need to craft them to reproduce the exploit on a real device:

• malicious companion app