Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-21T16:17:25.070Z",
  "pubdate": "2026-09-21T16:17:25.070Z",
  "executiveSummary": "A critical authentication bypass vulnerability exists in Mailu mail server deployments where PROXY_AUTH_WHITELIST is configured but the REAL_IP_HEADER variable remains unset.\nThe vulnerability stems from the improper handling of the X-Forwarded-By header, which the Nginx proxy configuration fails to sanitize or overwrite when receiving incoming requests.\nThis allows an unauthenticated remote attacker to spoof trusted proxy identities, effectively bypassing authentication mechanisms intended to restrict access based on proxy origin.\nThe affected components include Mailu core images from version 2.0 up to 2024.06.55 and Mailu helm-charts versions prior to 2.7.3.\nThe risk is high, as it enables unauthorized access to mail services without valid credentials. Exploitation requires no authentication, relying solely on the ability to manipulate HTTP request headers.\nThe vulnerability is remediated by updating to the fixed versions, which implement proper header management to prevent client-side header injection.",
  "technicalDetails": "The root cause of this vulnerability lies in the Nginx configuration logic located in core/nginx/conf/proxy.conf. While the proxy_hide_header directive is utilized to prevent the leakage of internal headers to upstream responses, it fails to sanitize or overwrite the X-Forwarded-By header within incoming client requests.\nIn deployments where PROXY_AUTH_WHITELIST is enabled, Mailu relies on header-based authentication to identify trusted proxies. However, because the REAL_IP_HEADER directive is not explicitly defined, the system defaults to trusting the user-provided X-Forwarded-By header.\nThe attack flow begins when an attacker sends a malicious HTTP request to the mail server. By manually setting the X-Forwarded-By header in the request packet, the attacker can impersonate a trusted proxy server included in the PROXY_AUTH_WHITELIST. Because the Nginx template does not override this header with the actual connection source, the upstream application perceives the request as originating from a trusted, authorized source.\nConsequently, the application bypasses standard authentication checks, assuming the request has been pre-validated by the trusted proxy. This allows an unauthenticated remote attacker to gain unauthorized access to protected resources that are otherwise restricted by the proxy authentication whitelist.\nThe impact is significant, as the attacker effectively elevates their privilege level to match that of a trusted proxy, potentially leading to unauthorized data access, service manipulation, or complete administrative bypass depending on the services exposed behind the proxy.\nThe vulnerability is present in Mailu versions ranging from 2.0 through 2024.06.55 and Mailu helm-charts prior to 2.7.3. Exploitation is trivial for any remote attacker capable of sending crafted HTTP requests, as there is no requirement for valid credentials or existing session state to inject the spoofed header.\nPost-exploitation, the attacker maintains the ability to interact with internal components as if they were a trusted infrastructure component, potentially allowing for the exploitation of additional internal-only services or APIs that rely on this proxy-based trust model."
}