CVE-2026-48840: 
Exim vulnerability analysis and mitigation

CVE-2026-48840 is a pre-authentication information disclosure vulnerability in Exim affecting versions 4.88 through 4.99.3, corrected in Exim 4.99.4. The flaw causes uninitialized stack memory to be disclosed to remote clients via the PROXY protocol in certain proxy configurations. It was reported by Warisjeet Singh (sin99xx) on 2026-05-19, with CVE assignment on 2026-05-25 and public disclosure on 2026-05-29. It carries a CVSS v3.1 base score of 5.3 (Medium) (oss-security, GitHub Advisory).

The root cause is classified as CWE-839 (Numeric Range Comparison Without Minimum Check). In proxy_protocol(), the hdr union is declared as an uninitialized stack variable. For PROXYv2 frames, only an upper-bound length check is enforced — no minimum length is validated. An attacker can send a PROXYv2 frame with address family 0x21 (TCPv6) and len=0, causing the read loop to copy zero bytes into the union; the TCPv6 dispatch arm then unconditionally calls memmove() to copy 16 uninitialized stack bytes into a temporary IPv6 address buffer, which inet_ntop() formats and emits in the SMTP greeting banner (e.g., 250 hostname Hello probe [::68ef:38ad:ffff:0]). The same defect affects family 0x11 (TCPv4) with len < 12, leaking 4 bytes. Exploitation requires that the attacker's source IP matches the hosts_proxy ACL, or that the attacker can reach the PROXY-protocol listener through an already-trusted host (oss-security).

Successful exploitation leaks uninitialized stack memory — confirmed to contain live userspace virtual address pointers — to an unauthenticated remote attacker via the SMTP greeting banner. Up to 16 bytes (TCPv6) or 4 bytes (TCPv4) of stack data are exposed per connection, and because the leaked values track ASLR entropy across daemon restarts, this vulnerability functions as an ASLR-defeat primitive that could be chained with a separate memory-corruption vulnerability to achieve code execution. There is no integrity or availability impact; the confidentiality impact is limited but strategically significant as a chain component (oss-security, GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.027% (0.000270), placing it in the 21st percentile for exploitation likelihood. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is constrained by the requirement that the attacker's source IP must match the hosts_proxy configuration or be routable through a trusted proxy host, limiting the attack surface to misconfigured or broadly scoped deployments (GitHub Advisory, oss-security).

1. Reconnaissance: Identify Exim mail servers (versions 4.88–4.99.3) compiled with SUPPORT_PROXY (default in Debian, Ubuntu, RHEL/Fedora packages) using banner grabbing tools such as nmap or telnet on port 25/587. Check if the server responds to PROXY protocol headers.
2. Assess proxy configuration: Determine whether hosts_proxy is set to a broad CIDR range or includes the attacker's IP. This may be inferred by sending a valid PROXYv2 header and observing whether the server processes it.
3. Craft malicious PROXYv2 frame: Construct a PROXYv2 frame with address family 0x21 (TCPv6) and length field len=0 (or address family 0x11/TCPv4 with len < 12). This bypasses the upper-bound check while triggering the uninitialized memory read path.
4. Send frame and capture response: Transmit the crafted frame to the Exim SMTP port. The server will emit the SMTP greeting banner containing the leaked stack bytes formatted as an IPv6 address (e.g., 250 hostname Hello probe [::68ef:38ad:ffff:0]).
5. Extract ASLR entropy: Parse the leaked address from the banner. Repeat across daemon restarts to confirm the leaked values are live VA pointers, enabling ASLR bypass for use in a subsequent memory-corruption exploit chain (oss-security).

• Network: Repeated inbound SMTP connections sending malformed PROXYv2 frames with len=0 or len < 12 for TCPv4/TCPv6 address families; connections from IPs not matching legitimate load-balancer infrastructure but matching hosts_proxy ranges.
• Logs: Exim mainlog entries showing proxyfail rejections (after patching) or unusual SMTP greeting banners containing IPv6-formatted addresses with unexpected hex values (e.g., Hello probe [::68ef:38ad:ffff:0]) from non-standard source IPs.
• Network: SMTP banner responses containing bracketed IPv6-format strings that do not correspond to valid client addresses, observable via network traffic inspection on port 25/587 (oss-security).

The definitive fix is to upgrade Exim to version 4.99.4, which adds minimum-length checks per address family (12 bytes for TCPv4/0x11, 36 bytes for TCPv6/0x21) before the union is accessed; malformed frames are rejected with proxyfail. If immediate upgrade is not possible, two configuration-based workarounds are available: (1) narrow hosts_proxy to the exact IP addresses of trusted load balancers rather than broad CIDR ranges, and (2) unset hosts_proxy entirely to disable PROXY-protocol parsing on the affected listener. Packages for Debian, Ubuntu, RHEL/Fedora, and other distributions have been updated (oss-security, Exim Advisory).

The vulnerability was disclosed publicly by Exim maintainer Heiko Schlittermann via the oss-security mailing list on 2026-05-29, with coordinated advance notice sent to Linux distribution maintainers on 2026-05-26. The disclosure generated moderate community discussion on Reddit (r/mxroute) and social media platforms including Bluesky, with users noting the ASLR-defeat potential as the most significant aspect of an otherwise medium-severity finding. Security blogs such as Infinit Security published technical write-ups shortly after disclosure. Nessus and Qualys detection plugins were released promptly, and multiple Linux distributions including Debian, Ubuntu, and Fedora issued updated packages within days (oss-security, GitHub Advisory).