Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact In mitmproxy 12.2.1 and below, the builtin LDAP proxy authentication does not correctly sanitize the username when querying the LDAP server. This allows a malicious client to bypass authentication. Only mitmproxy instances using the proxyauth option with LDAP are affected. This option is not enabled by default. Patches The vulnerability has been fixed in mitmproxy 12.2.2 and above. Acknowledgements We thank Yue (Knox) Liu (@yueyueL) for responsibly disclosing this vulnerability to the mitmproxy team. Timeline - 2025-12-08: Received initial report. - 2025-12-09: Verified report and confirmed receipt. - 2026-01-02: Informed researcher that patch will be part of the next regular patch release. - 2026-04-12: Published patch release and advisory.
Recommended action: Upgrade to 12.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
mitmproxy 12.1.1 and below embed python-hyper/h2 ≤ v4.2.0, which has a gap in its HTTP/2 header validation. This enables request smuggling attacks when mitmproxy is in a configuration where it translates HTTP/2 to HTTP/1. For example, this affects reverse proxies to http:// backends. It does not affect mitmproxy's regular mode. All users are encouraged to upgrade to mitmproxy 12.1.2, which includes a fixed version of h2. More details about the vulnerability itself can be found at https://github.com/python-hyper/h2/security/advisories/GHSA-847f-9342-265h.
Recommended action: Upgrade to 12.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In mitmweb 11.1.0 and below, a malicious client can use mitmweb's proxy server (bound to :8080 by default) to access mitmweb's internal API (bound to 127.0.0.1:8081 by default). In other words, while the client cannot access the API directly (good), they can access the API through the proxy (bad). An attacker may be able to escalate this SSRF-style access to remote code execution. The mitmproxy and mitmdump tools are unaffected. Only mitmweb is affected. The blockglobal option, which is enabled by default, blocks connections originating from publicly-routable IP addresses in the proxy. The attacker needs to be in the same local network. Patches The vulnerability has been fixed in mitmproxy 11.1.2 and above. Acknowledgements We thank Stefan Grönke (@gronke) for reporting this vulnerability as part of a security audit by Radically Open Security. This audit was supported by the NGI0 Entrust fund established by NLnet. Timeline - 2025-01-14: Received initial report. - 2025-01-14:…
Recommended action: Upgrade to 11.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In mitmproxy 7.0.4 and below, a malicious client or server is able to perform HTTP request smuggling attacks through mitmproxy. This means that a malicious client/server could smuggle a request/response through mitmproxy as part of another request/response's HTTP message body. While mitmproxy would only see one request, the target server would see multiple requests. A smuggled request is still captured as part of another request's body, but it does not appear in the request list and does not go through the usual mitmproxy event hooks, where users may have implemented custom access control checks or input sanitization. Unless you use mitmproxy to protect an HTTP/1 service, no action is required. Patches The vulnerability has been fixed in mitmproxy 8.0.0 and above. Acknowledgements We thank Zeyu Zhang (@zeyu2001) for responsibly disclosing this vulnerability to the mitmproxy team. Timeline - 2022-03-15: Received initial report. - 2022-03-15: Verified report and confirmed…
Recommended action: Upgrade to 8.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In mitmproxy 7.0.2 and below, a malicious client or server is able to perform HTTP request smuggling attacks through mitmproxy. This means that a malicious client/server could smuggle a request/response through mitmproxy as part of another request/response's HTTP message body. While mitmproxy would only see one request, the target server would see multiple requests. A smuggled request is still captured as part of another request's body, but it does not appear in the request list and does not go through the usual mitmproxy event hooks, where users may have implemented custom access control checks or input sanitization. Unless you use mitmproxy to protect an HTTP/1 service, no action is required. Patches The vulnerability has been fixed in mitmproxy 7.0.3 and above. Acknowledgements We thank João Sobral (@chinchila) for responsibly disclosing this vulnerability to the mitmproxy team. Timeline - 2021-09-08: Received initial report for mitmproxy <= 6.0.2. - 2021-09-08: Requested…
Recommended action: Upgrade to 7.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
mitmweb in mitmproxy before v4.0.4 allows DNS Rebinding attacks, related to tools/web/app.py.
Recommended action: Upgrade to 4.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.