Skip to content

CVE-2026-45709

Server-Side Request Forgery (SSRF): Is CVE-2026-45709 real, exploitable, or a false positive? Here's the community verdict.

signals

public sources

Exploited in wild
Not listed
CISA KEV
Public exploit
None known
Metasploit/EDB/PoC
Base severity
5.8 Medium
CVSS
Exploitation prob.
n/a
FIRST EPSS
Weakness
CWE-918 · Server-Side Request Forgery (SSRF)
CWE

Moderate signals. Triage by your actual exposure and reachability.

baseline read

auto · not a community verdict

Low signal — verdict needed

Few public signals point to active risk. Whether a scanner hit here is a true or false positive depends on your version and config — community verdicts decide.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N

Mailpit is an email testing tool and API for developers. The fix for GHSA-6jxm-fv7w-rw5j (CVE-2026-23845, "Server-Side Request Forgery (SSRF) via HTML Check API"), shipped in mailpit `v1.28.3`, hardened `internal/htmlcheck/css.go::downloadCSSToBytes` with a 5MB size cap, a `text/css` content-type check, login-info stripping in `isValidURL`, and an opt-in `--block-remote-css-and-fonts` config flag — but did not add the IP-filtering dialer that the same codebase already uses on the two sister SSRF endpoints (the proxy handler and link-check). Prior to version 1.30.0, `internal/htmlcheck/css.go::newSafeHTTPClient` is mis-named — it builds an `http.Client` whose `Transport.DialContext` calls `net.Dialer.DialContext` directly with no IP allowlisting. As a result, the SSRF originally reported by Bao Anh Phan still permits the server to dial loopback, private, link-local, and any other reserved/multicast range, provided the target replies with `HTTP/200` and a content-type beginning with `text/css`. With redirect-following (`CheckRedirect` allows redirects to any `isValidURL` URL with no IP filter), an attacker-controlled public site can redirect mailpit's request into the private network without ever appearing in the email's HTML. In the default mailpit deploy (no UI auth, no SMTP auth, port 1025/8025 exposed), this is an unauthenticated, network-reachable SSRF triggered by sending an HTML email and then issuing one HTTP `GET` to `/api/v1/message/{id}/html-check`. Version 1.30.0 contains an updated fix.

Published

Embed this verdict
TruePositive verdict for CVE-2026-45709
Markdown
[![TruePositive verdict](https://www.truepositive.app/cve/CVE-2026-45709/badge.svg)](https://www.truepositive.app/cve/CVE-2026-45709)
HTML
<a href="https://www.truepositive.app/cve/CVE-2026-45709"><img src="https://www.truepositive.app/cve/CVE-2026-45709/badge.svg" alt="TruePositive verdict for CVE-2026-45709"></a>

Live badge that updates automatically as the community verdict changes.

Community ground truth

Be the first practitioner to weigh in

So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.

🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.

In your experience, is this finding real and exploitable?

awaiting field verdicts
Real, but not a risk here
Not a real issue

Curated baseline: A curated baseline from public sources, shown separately from community verdicts.

No account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.

Field notes & remediation

Verdicts are the quick signal. Notes are the evidence and fixes behind them.

  • 0
    Field note · TruePositive EditorialCurated

    No confirmed in-the-wild exploitation or public exploit was found for this yet.

Add a field note or remediationoptional
Note type

What are you adding?

Markdown supported · minimum 20 characters.

Same weakness: CWE-918 · Server-Side Request Forgery (SSRF).