Servers running Exim versions between 4.88 and 4.99.3 leak uninitialized stack memory straight into SMTP banners when processing malformed proxy headers. Attackers can grab those raw bytes to map out system memory layouts and bypass modern address space randomization protections. Rolling out version 4.99.4 adds strict length checks that reject the bad frames before they touch sensitive data, while clearing the hosts_proxy directive disables the feature entirely until patches propagate. Mail admins should treat this as a high priority since leaving an unpatched relay open to the internet basically hands attackers a free memory map.

Fixing The Exim PROXY-protocol Vulnerability Before It Leaks Server Memory

Servers running Exim versions between 4.88 and 4.99.3 sit on a memory leak that spills uninitialized stack data straight into SMTP banners. The issue stems from how the mail transfer agent handles PROXYv2 frames when address family checks fall short of basic length validation. Upgrading to version 4.99.4 closes the gap before attackers can use those leaked bytes to map out system memory layouts.

How The Exim PROXY-protocol Vulnerability Actually Works

The flaw lives inside the proxy_protocol() function when it processes incoming connection headers from load balancers or reverse proxies. When a client sends a PROXYv2 frame with an address family of TCPv6 and a length field set to zero, Exim skips the actual data copy but still moves forward into the IPv6 handling block. That block blindly copies sixteen bytes from an uninitialized stack union into a temporary variable. The same pattern repeats for TCPv4 frames when the length falls below twelve bytes, leaking four bytes instead. Those empty slots happen to hold whatever garbage was sitting on the stack during daemon startup, which frequently includes live virtual memory pointers. Exim then formats those raw bytes as an IPv6 address and prints them in the greeting banner. Anyone watching that initial handshake can now piece together ASLR entropy across multiple restarts without even trying.

Checking If The Mail Server Is Actually Affected

Not every Exim installation runs into this problem because the exploit requires specific configuration flags to trigger. The mail server needs to be compiled with SUPPORT_PROXY enabled, which is standard on Debian, Ubuntu, and RHEL distributions. More importantly, the hosts_proxy directive must point to a non-empty value in the main configuration file. If that setting stays blank or gets commented out, Exim ignores PROXY headers entirely and the vulnerable code path never executes. Administrators should also verify whether the server accepts connections from untrusted networks on ports expecting proxy headers. Attackers need their source IP to match the hosts_proxy list or route through a trusted intermediary before they can trigger the memory leak.

Applying The Exim PROXY-protocol Vulnerability Fix

Rolling out version 4.99.4 resolves the stack handling issue by adding strict minimum length checks before any union access occurs. TCPv4 frames now require at least twelve bytes while TCPv6 demands thirty-six bytes, and anything shorter gets rejected with a proxyfail response. The patch sits on the exim-4.99+fixes branch under tag exim-4.99.4 and carries a verified signature from Heiko Schlittermann. Distribution maintainers typically push updates through standard package repositories within forty eight hours of public release, so checking for available upgrades should take priority over manual compilation. Systems that rely on custom proxy configurations can also disable the feature entirely by clearing the hosts_proxy value until patches propagate across all nodes.