CVE-2026-85751 in Mailu
Summary
by MITRE • 09/21/2026
Mailu is a mail server distributed as a set of Docker images. From Mailu 2.0 until 2024.06.55 and prior to Mailu helm-charts 2.7.3, deployments with PROXY_AUTH_WHITELIST configured but REAL_IP_HEADER unset trusted a client-controlled X-Forwarded-By header for header-based proxy authentication. The proxy_hide_header directive in the nginx template at core/nginx/conf/proxy.conf hid the header from upstream responses but did not overwrite the incoming request value in this configuration. An unauthenticated remote attacker could therefore spoof the trusted proxy identity and bypass authentication. This issue is fixed in Mailu 2024.06.55 and Mailu helm-charts 2.7.3.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified within the Mailu mail server infrastructure represents a critical failure in header-based proxy authentication logic, specifically affecting deployments configured with PROXY_AUTH_WHITELIST while leaving REAL_IP_HEADER unset. This configuration scenario exposes the system to an unauthenticated remote attacker capable of spoofing trusted proxy identities and bypassing intended access controls. The root cause lies in the interaction between Nginx's request processing directives and the application-level authentication mechanisms, where a specific header used for identifying proxied clients is not properly sanitized or overwritten during the reverse proxy operation. This flaw allows an external actor to inject malicious headers that mimic those of trusted internal proxies, thereby tricking the Mailu service into granting unauthorized access as if the request originated from a legitimate source within the protected network perimeter.
Technically, the issue stems from how Nginx handles header manipulation in its configuration templates for proxy environments. In the affected versions ranging from Mailu 2.0 up to version 2024.06.55 and Helm charts prior to 2.7.3, the setup utilizes a PROXY_AUTH_WHITELIST mechanism that relies on specific headers to determine if an incoming request should be considered as coming from a trusted proxy. The Nginx configuration includes a directive intended to hide certain headers from upstream responses using proxy_hide_header. However, this directive only affects outgoing response headers and does not overwrite or strip the corresponding incoming request header values when REAL_IP_HEADER is not explicitly defined. Consequently, if an attacker sends a request containing an X-Forwarded-By header that matches one of the whitelisted trusted proxies, Nginx passes this unmodified header to the backend Mailu application. The application then interprets this spoofed header as valid proof of proxy authentication, effectively bypassing the login requirements and granting the attacker direct access to mail services without credentials.
The operational impact of this vulnerability is severe, as it allows for complete authentication bypass in environments where reverse proxies are used to terminate SSL or manage traffic before reaching the Mailu backend. An unauthenticated remote attacker can exploit this flaw by crafting HTTP requests with forged X-Forwarded-By headers that correspond to IP addresses listed in the PROXY_AUTH_WHITELIST configuration. This leads to unauthorized access to sensitive email data, including personal communications, corporate secrets, and potentially credentials stored within emails or associated accounts. Furthermore, because Mailu is often deployed as part of a larger infrastructure using Docker containers and Helm charts for orchestration, this vulnerability could be leveraged in conjunction with other network-level attacks to pivot through the internal network if the compromised mail server provides access to additional services or databases. The lack of proper header sanitization means that even sophisticated security controls like Web Application Firewalls might not detect the attack if they rely on standard proxy headers for trust decisions, making this a stealthy and high-impact vulnerability.
From a classification perspective, this flaw aligns with CWE-287, which describes Improper Authentication, specifically involving the misidentification of an entity or failure to properly verify identity claims via external inputs like HTTP headers. It also relates to CWE-94, Code Injection, insofar as it involves the injection of untrusted data into a security decision process without proper validation. In terms of attack vectors and tactics, this vulnerability maps directly to MITRE ATT&CK technique T1621, Multi-Factor Authentication Bypass, although more accurately it fits under T1078, Valid Accounts, as the attacker is bypassing authentication entirely rather than breaking a specific factor. It also touches upon T1590, Gather Victim Network Information, by allowing reconnaissance of internal network structures through trusted proxy headers if those proxies are part of an internal trust chain. The exploitation requires no prior access or credentials, classifying it as a remote code execution vector in the context of authentication bypass, which significantly lowers the barrier for entry for malicious actors targeting mail infrastructure.
To mitigate this vulnerability and prevent similar issues in future deployments, administrators must ensure that they are running Mailu version 2024.06.55 or later, along with Helm charts version 2.7.3 or newer, where the underlying Nginx configuration has been corrected to properly handle header overwriting. For environments unable to upgrade immediately, a manual workaround involves explicitly setting the REAL_IP_HEADER directive in the Nginx configuration to ensure that only specific, expected headers are used for proxy identification and that other potentially spoofable headers like X-Forwarded-By are either stripped or ignored during the authentication check process. Additionally, organizations should review their PROXY_AUTH_WHITELIST configurations to ensure they do not rely solely on header values without supplementary verification methods such as mutual TLS or IP-based restrictions at the network layer rather than just application-level proxy headers. Regular auditing of reverse proxy configurations against industry standards like CIS Benchmarks for Nginx can help identify similar misconfigurations where trust boundaries are incorrectly defined based on mutable HTTP headers that do not reflect true client identity.