MobSF CVE-2026-68927

Exploitation requires a high-privilege authenticated MobSF account with APK upload and analysis permissions - CVSS PR:H confirms this; unauthenticated exploitation is not possible. The attacker must control a domain's authoritative DNS server and be able to configure a very low TTL, enabling DNS rebinding between the valid_host() lookup and the subsequent requests.get() call; without attacker-controlled DNS infrastructure, the SSRF is constrained to public IPs and provides no internal access. The Android manifest must include a browsable App Link <data> element with android:host and android:port as separate attributes - this is a standard manifest construct but requires a crafted or malicious APK. The following factors limit exploitation scope: (1) the request path is fixed to /.well-known/assetlinks.json - arbitrary endpoint targeting is not possible; (2) HTTP redirects are disabled (allow_redirects=False), preventing redirect-based path escape; (3) DNS rebinding adds meaningful operational complexity (AC:H); (4) only the HTTP response is returned to MobSF's analysis logic, not directly to the attacker - data exfiltration depends on how MobSF surfaces or logs that response.

The CVSS 3.1 score of 3.0 with vector AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:N accurately captures the constrained risk profile. PR:H is the primary limiting factor - exploitation requires a high-privilege authenticated MobSF account, ruling out external unauthenticated attackers entirely. AC:H reflects the DNS rebinding requirement, which demands that the attacker control both a domain's authoritative DNS server and can force TTL expiry between the valid_host() validation call and the subsequent requests.get() connection - a non-trivial operational prerequisite. S:C (Scope Changed) is justified because a successful exploit affects services outside MobSF's own security boundary, such as internal microservices or metadata endpoints. C:L is appropriate because the fixed /.well-known/assetlinks.json path and disabled redirects constrain the attacker to reading a single, specific endpoint on an internal host - precluding arbitrary data exfiltration. EPSS data was not supplied; exploitation probability is unknown. The vulnerability is absent from CISA KEV, and no public exploit code has been identified. Real-world risk is meaningful primarily in multi-user MobSF deployments where insider threat or compromised admin credentials are plausible; single-analyst installations with tightly controlled access are at substantially lower risk.

An authenticated MobSF administrator crafts an Android APK containing a manifest <data> element with android:host set to an attacker-controlled domain (e.g., evil.example.com) with a very low DNS TTL, and android:port set to an internal service port such as 8080. During manifest analysis, valid_host() resolves evil.example.com to a legitimate public IP and passes validation; the attacker then rebinds the DNS record to an internal address (e.g., 10.0.0.50) before requests.get() is called. MobSF fetches http://10.0.0.50:8080/.well-known/assetlinks.json, and any response from that internal service is processed by MobSF - exposing internal service behavior. No public proof-of-concept exploit code has been identified at time of analysis, though the vendor advisory provides a detailed reproduction recipe.