CVE-2026-84697 in Mailpit
Summary
by MITRE • 09/02/2026
Mailpit's IsInternalIP deny list function fails to block the Azure WireServer address 168.63.129.16 and the RFC 2765/6145 IPv4-translated IPv6 prefix, allowing server-side request forgery to internal destinations. Attackers can supply hostnames resolving to these addresses in message content to reach the link check API and proxy endpoint for accessing internal resources.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in Mailpit represents a critical failure in input validation within its IsInternalIP deny list function, which is designed to prevent server-side request forgery attacks against internal network resources. This security flaw specifically stems from the application's inability to correctly identify and block two distinct categories of IP addresses that are commonly used for accessing cloud infrastructure metadata services and legacy IPv6 transition mechanisms. The first category involves the Azure WireServer address 168.63.129.16, which is a special-purpose IP address reserved by Microsoft Azure for its instance metadata service. This endpoint allows virtual machines to retrieve configuration data, security tokens, and other sensitive information about their own environment without requiring authentication from within the network perimeter. The second category encompasses addresses falling under the RFC 2765 and RFC 6145 specifications, which define the IPv4-translated IPv6 prefix range of ::ffff:0:0/96. This mechanism is used for translating between IPv4 and IPv6 networks, meaning that an attacker can encode standard private or internal IPv4 addresses into this IPv6 format to bypass simple string-based IP checks that do not perform proper protocol-level normalization.
The operational impact of this vulnerability allows attackers to exploit the link check API and proxy endpoint functionality within Mailpit to reach internal destinations that should be inaccessible from external contexts. By supplying hostnames in message content that resolve to either the Azure WireServer address or addresses translated via the IPv4-mapped IPv6 prefix, an attacker can force the server to make outbound HTTP requests to these restricted endpoints. This constitutes a classic Server-Side Request Forgery scenario where the application acts as a proxy for malicious actors. The consequences of such exploitation are severe in cloud environments, particularly those utilizing Microsoft Azure. An adversary could potentially extract sensitive metadata from the WireServer, including access keys, identity tokens, and network configuration details that facilitate further lateral movement within the compromised infrastructure. Additionally, if internal services behind firewalls or security groups rely on IP-based restrictions rather than robust authentication mechanisms, they may be inadvertently accessed through this proxy channel, leading to unauthorized data exposure or manipulation of internal systems.
From a technical classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically highlighting the sub-category related to insufficient validation of user-supplied input against known dangerous IP ranges. The failure also reflects weaknesses in how applications handle network protocol translations and cloud-specific metadata endpoints, which are often overlooked during standard penetration testing unless specific knowledge of Azure infrastructure is applied. In terms of the MITRE ATT&CK framework, this exploit maps directly to T1598 Phishing for Information from Cloud Infrastructure Services, as it involves leveraging legitimate application features to harvest sensitive data from cloud provider APIs. It also relates to T1046 Network Service Discovery if used to map internal network topology by probing various internal endpoints through the proxy mechanism. The root cause lies in a logic error where the deny list implementation does not account for all possible representations of restricted IP addresses, particularly those involving protocol translation layers or cloud-specific reserved ranges that are not part of standard private address blocks like 10.0.0.0/8 or 192.168.0.0/16.
Mitigation strategies must focus on hardening the input validation logic to ensure comprehensive coverage of all potential IP representations. Developers should implement a robust allow-list approach rather than relying solely on deny lists, as deny lists are inherently prone to missing edge cases like IPv4-mapped IPv6 addresses or cloud-specific metadata IPs. It is essential to resolve hostnames to their final IP addresses before performing validation checks and to normalize these addresses into a single format for comparison against the restricted list. For Azure environments specifically, explicit blocking of 168.63.129.16 at both the application level and network perimeter firewalls provides defense in depth. Additionally, restricting outbound traffic from Mailpit servers using egress filtering rules can prevent connections to known metadata service IPs regardless of application-level flaws. Regular security audits should include testing for SSRF vulnerabilities that exploit protocol translation mechanisms and cloud-specific endpoints to ensure that internal resources remain isolated from external manipulation through proxy features.