GHSA-527g-3w9m-29hv: LDAP Injection in mitmproxy proxyauth Addon

The mitmproxy application provides an interception proxy utilized heavily by security researchers and developers for analyzing HTTP/HTTPS traffic. To restrict access to the proxy itself, administrators can enable the proxyauth addon. This addon supports multiple authentication backends, including an LDAP backend configured via the --proxyauth "ldap:..." command-line flag.

In mitmproxy versions 12.2.1 and earlier, the LDAP authentication mechanism fails to safely process user-supplied credentials before utilizing them in backend directory queries. Specifically, the application exhibits an Improper Neutralization of Special Elements used in an LDAP Query vulnerability, tracked as CWE-90.

Because the LDAP integration is not enabled by default, the vulnerability only affects instances where administrators have explicitly configured mitmproxy to authenticate users against a remote LDAP or Active Directory server. When this configuration is active, the proxy exposes an attack surface that processes unauthenticated external input directly into directory searches.

The vulnerability stems from the method mitmproxy uses to construct LDAP search filters within the mitmproxy/addons/proxyauth.py module. When an incoming HTTP request triggers proxy authentication, the application extracts the username from the Proxy-Authorization header and incorporates it into an LDAP search query to locate the corresponding user record.

The application code directly interpolates the user-controlled username string into the LDAP filter template without applying appropriate escaping mechanisms. RFC 4515 defines specific control characters used in LDAP string representations of search filters, including parentheses (), asterisks *, ampersands &, and vertical bars |.

By lacking a sanitization step using a standard LDAP escaping function (such as replacing ( with \28), the application permits these control characters to retain their syntactic meaning in the backend query. This allows an attacker to prematurely terminate the intended username attribute assertion and append arbitrary logical conditions to the broader search filter.

The vulnerability manifests in the Python code responsible for executing the LDAP bind and search operations. In the vulnerable implementation, the application relies on standard Python string formatting techniques to dynamically build the query string.

# Vulnerable pattern within proxyauth.py
# The username is directly interpolated without escaping
search_filter = "(&(uid={}))".format(username)

Pull Request #6428 resolves this weakness by implementing proper input parameterization and escaping for the LDAP search filter key. The patched version invokes a dedicated escaping routine prior to query construction.

# Patched implementation using proper escaping (PR #6428)
from ldap3.utils.conv import escape_filter_chars
 
# Neutralize RFC 4515 control characters
safe_username = escape_filter_chars(username)
search_filter = "(&(uid={}))".format(safe_username)

This remediation ensures that any special characters injected by the user are transformed into their corresponding hexadecimal escape sequences. Consequently, the LDAP server interprets the input strictly as literal string data for the target attribute, preventing modifications to the underlying boolean logic of the query.

Exploitation requires network access to the mitmproxy listener and the proxy authentication feature to be configured with the LDAP backend. The attacker initiates the exploit by sending an HTTP request containing a crafted Proxy-Authorization header. The payload targets the username field and leverages standard LDAP injection syntax.

Consider an application that constructs the following filter structure: (&(uid=USER_INPUT)(objectClass=person)). An attacker submits the username payload admin)(|(password=*. The application interpolates this payload, resulting in the expanded query: (&(uid=admin)(|(password=*)(objectClass=person))).

This manipulated query evaluates to true if the record with uid=admin exists, or if any record with a password attribute and objectClass=person exists. Depending on the backend LDAP server's handling of anonymous binds or default directory access controls, this boolean manipulation often results in a successful search response, thereby bypassing the proxy's authentication requirement.

The primary impact of this vulnerability is authentication bypass. An attacker successfully exploiting the LDAP injection flaw can route arbitrary HTTP/HTTPS traffic through the mitmproxy instance without possessing valid credentials. This undermines the intended access controls and exposes internal network segments if the proxy has routing access to private infrastructure.

Beyond simple bypass, the vulnerability presents a risk of unauthorized access via identity spoofing. If the attacker crafts an injection payload that forces the LDAP server to return a specific, highly privileged user record (e.g., an administrator account), the application may authenticate the session under that elevated identity.

Additionally, the injection point facilitates boolean inference attacks against the backend directory. An attacker can systematically extract information regarding the directory structure, valid usernames, and other attributes by submitting conditional payloads and observing whether the proxy grants or denies access based on the query's boolean result.

The definitive remediation for this vulnerability is updating mitmproxy to version 12.2.2 or higher. The release of version 12.2.2 on April 12, 2026, incorporates the fixes from PR #6428, ensuring all user input is strictly validated and escaped before interacting with the LDAP backend.

For environments unable to immediately deploy the patch, administrators must apply configuration-based workarounds. The most effective mitigation is disabling the proxyauth LDAP module entirely, transitioning to a local password file or an alternative, securely implemented authentication backend.

If the LDAP integration must remain active on a vulnerable version, network-level restrictions must be strictly enforced. Administrators should isolate the mitmproxy instance, ensuring that only trusted, internal IP addresses can reach the proxy listener. Additionally, monitoring LDAP server logs for queries containing unauthorized logical operators (*, (, ), &, |) can provide detective capabilities against active exploitation attempts.