CVE-2026-68927 in MobSF
Summary
by MITRE • 08/18/2026
MobSF is a mobile application security testing tool used. Prior to 4.5.1, get_browsable_activities in mobsf/StaticAnalyzer/views/android/manifest_analysis.py validates only an Android manifest android:host value with valid_host before appending a separately supplied android:port to the URL fetched by _check_url, allowing an authenticated user to upload a crafted APK that makes requests to an attacker-selected nonstandard port at /.well-known/assetlinks.json. With an attacker-controlled hostname and DNS rebinding between validation and the requests.get connection, the request can reach an internal service, although redirects remain disabled and the path is fixed. This issue is fixed in version 4.5.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Mobile Security Framework (MobSF) prior to version 4.5.1 represents a significant server-side request forgery risk stemming from inadequate input validation within the Android manifest analysis module. MobSF is widely utilized by security professionals and developers for static and dynamic analysis of mobile applications, making it a critical tool in many enterprise security workflows. The specific flaw resides in the get_browsable_activities function located in mobsf/StaticAnalyzer/views/android/manifest_analysis.py. This component is responsible for parsing Android manifest files to identify activities that can be launched via implicit intents or web links, which often involves constructing URLs based on attributes such as android:host and android:port found within the APK metadata.
The core technical deficiency lies in how these URL components are validated before being used in network requests. The function performs a validation check solely against the android:host attribute using a valid_host filter to ensure it resembles a legitimate domain name. However, it fails to apply similar rigorous validation or sanitization logic to the android:port value provided separately by the APK manifest data. Instead of validating the port as part of a complete URL structure or restricting it to standard web ports, the code directly appends this unvalidated port number to the host string before passing the resulting composite URL to the _check_url function for fetching resources like /.well-known/assetlinks.json. This architectural oversight creates an opportunity for manipulation by malicious actors who can control both the hostname and the port through a crafted APK file uploaded during analysis.
An authenticated user with upload privileges can exploit this flaw by submitting a specially constructed Android Package Kit that specifies a non-standard or internal IP address as the host and a specific internal service port, such as 8080 or 445, in the manifest attributes. While the initial validation ensures the hostname appears syntactically valid, it does not prevent resolution to private network ranges if DNS rebinding techniques are employed. By leveraging DNS rebinding, an attacker can manipulate the Domain Name System responses so that the initially validated public domain resolves to a local internal IP address at the moment of execution. This allows the MobSF server to make HTTP requests to internal services that would otherwise be inaccessible from the external network or protected by perimeter firewalls. The attack vector specifically targets resources accessible via GET requests, such as asset link verification files, which are commonly used for app association and security policy enforcement in Android ecosystems.
The operational impact of this vulnerability is substantial within environments where MobSF is deployed on internal networks to analyze third-party applications. An attacker could potentially enumerate internal services, extract sensitive configuration data from unprotected endpoints, or probe for vulnerabilities in backend systems that trust requests originating from the analysis server. Although the implementation disables HTTP redirects and fixes the request path to /.well-known/assetlinks.json, limiting some aspects of exploitation, the ability to reach arbitrary ports on internal hosts remains a critical security breach. This capability undermines the isolation between the scanning infrastructure and the protected network segments, potentially leading to further lateral movement or data exfiltration depending on what services are exposed on those non-standard ports.
To mitigate this risk, organizations must immediately upgrade MobSF to version 4.5.1 or later, where the developers have implemented stricter validation for port numbers and likely enhanced host resolution checks to prevent DNS rebinding attacks. In addition to upgrading, administrators should ensure that the server running MobSF is not directly exposed to untrusted networks without proper network segmentation controls. Implementing egress filtering rules on the firewall surrounding the analysis environment can further restrict outbound connections to only necessary external domains and standard ports, thereby neutralizing the impact even if a vulnerability were present in future versions. Regularly updating security testing tools is essential as they often become targets for exploitation due to their privileged access and network capabilities within an organization's infrastructure.
This incident aligns with Common Weakness Enumeration CWE-918 regarding Server-Side Request Forgery, specifically highlighting the failure to validate user-supplied input that influences server-side requests. It also relates to CWE-20 Improper Input Validation, as the application failed to adequately sanitize or verify critical components of a URL constructed from external data sources. From an ATT&CK perspective, this vulnerability facilitates Initial Access and potentially Lateral Movement if internal services are compromised through forged requests. Security teams should treat such vulnerabilities in analysis tools with high priority due to their potential to bypass traditional network security controls by leveraging the trusted status of the scanning server itself.