Mailpit’s HTML‑check API was intended to prevent SSRF by restricting downloads of external CSS, but the patch for GHSA‑6jxm originally tightened the download logic while failing to enable the IP‑filtering dialer used by other SSRF endpoints. In pre‑1.30.0 releases, the client created in internal/htmlcheck/css.go::newSafeHTTPClient resolves and connects to loopback, private, link‑local, or multicast addresses when it receives a response beginning with a text/css header, because the DialContext bypasses the IP allowlist. Because redirects are followed without filtering, an attacker can host a public site that redirects the request into the private network, allowing the Mailpit server to reach internal resources without appearing in the message HTML. The flaw, classified as CWE‑918, involves the omission of address‑range checks during outbound HTTP requests and is only fully fixed in version 1.30.0, which adds an IP‑filtering dialer.

axllent Mailpit releases before version 1.30.0 are vulnerable. The issue exists in all pre‑1.30.0 builds, regardless of whether the HTML‑check feature is currently enabled. The fix was delivered in the 1.30.0 release.

The EPSS score of <1% indicates a low probability of exploitation, and the vulnerability is not listed in the CISA KEV catalog. In a typical deployment where ports 1025/8025 are exposed and authentication is absent, the SSRF is unauthenticated and network‑reachable. An attacker can trigger the flaw by sending an HTML email and then invoking the /api/v1/message/{id}/html-check endpoint, potentially accessing internal resources.