CVE-2025-31116 is a Medium severity (CVSS 4.4) server side request forgery in Mobile Security Framework (MobSF). The fix for an earlier issue checked hostnames in a way that DNS rebinding can defeat. It is fixed in MobSF 4.3.2, so upgrade any instance older than that.
What's affected
MobSF is an open source tool for static and dynamic analysis of mobile apps. According to the GitHub advisory, this issue affects versions before 4.3.2 and is fixed in 4.3.2.
The cause is in a function called valid_host(), which was the mitigation for the earlier CVE-2024-29190. It used socket.gethostbyname() to resolve a hostname and decide whether it was safe. The advisory explains that this is vulnerable to the DNS rebinding technique: a hostname can resolve to a harmless address the first time and to an internal address the next time.
The CVSS vector is CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:L. High privileges are required, the attack complexity is high, and the impact is limited, which keeps the score at Medium. The record does not list the CVE in CISA KEV.
How to check if you're exposed
Find out how your team runs MobSF and what version it is. If you use the official Docker image, list local images and their tags:
docker images | grep -i mobsf
The MobSF web interface also shows its version in the About section. If you run from a source checkout, check the tag or commit:
git describe --tags
Anything below 4.3.2 is affected. Also ask where MobSF is hosted. An instance on a developer laptop is less exposed than one on a shared CI server that can reach internal services.
Because the flaw needs a user with high privileges, the practical question is who can log in to your MobSF instance and what internal addresses the host can reach.
What to do now
- Upgrade MobSF to 4.3.2 or later. For Docker, pull the latest image and recreate the container.
- Limit who has access to the MobSF web interface and API key, and keep it off the public internet.
- Run MobSF on a host with network egress rules that block access to internal admin services and cloud metadata addresses.
- Review any scans or API calls that supplied external URLs, and check whether the host made requests to internal addresses.
- Add MobSF to your tool inventory, since security tooling is software that also needs patching.
Why it matters
Server side request forgery is a flaw where an application can be made to send requests to a destination the user chose. The weakness is CWE-918. The danger is that the server often sits inside a network that outsiders cannot reach, so it can contact internal services on behalf of a user who cannot.
The fix for the first bug resolved a hostname once, checked the address, and then let the actual request resolve the name again. Between the two lookups, an attacker controlling the DNS server can change the answer. This is called a time of check to time of use problem. A stronger approach is to resolve the name once, validate that exact address and connect to it directly. It is a good reminder that a mitigation can have its own bug, and that your own tools need patching like any other dependency.
Quick check
Is MobSF only a risk to the person who runs it?
The scoring shows limited impact and a high privilege requirement. But a shared MobSF server can reach internal systems, so the host's network position matters.
Why was the first fix not enough?
It resolved the hostname to check it, but DNS rebinding lets the answer change on the next lookup, so the checked address is not necessarily the one later used.
Sources
Last reviewed: 19 October 2026.
