CVE-2026-45713 Overview
Mailpit is an email testing tool and API used by developers to capture and inspect outbound mail. Versions prior to 1.30.0 fail to enforce a maximum message size on both the SMTP server and the HTTP /api/v1/send endpoint. The Server.MaxSize field remains at Go's zero value, which the runtime interprets as unlimited. Default listeners bind [::]:1025 for SMTP and [::]:8025 for HTTP without authentication. Any network-reachable attacker can submit an arbitrarily large message and trigger memory amplification of roughly seven to ten times the input size. This vulnerability is tracked under [CWE-400] Uncontrolled Resource Consumption.
Critical Impact
A single unauthenticated attacker can drive the Mailpit process to an out-of-memory kill by submitting oversized SMTP or HTTP payloads, disrupting developer email testing infrastructure.
Affected Products
- Mailpit versions prior to 1.30.0
- Mailpit SMTP server component (default port 1025)
- Mailpit HTTP API /api/v1/send endpoint (default port 8025)
Discovery Timeline
- 2026-07-20 - CVE-2026-45713 published to NVD
- 2026-07-21 - Last updated in NVD database
Technical Details for CVE-2026-45713
Vulnerability Analysis
The vulnerability stems from missing size enforcement on two ingestion paths in Mailpit. On the SMTP path, the Server.MaxSize integer field is declared to bound the DATA payload but is never assigned outside test code. Go initializes unset integer fields to zero, which Mailpit treats as "no limit." On the HTTP path, the /api/v1/send handler decodes request bodies with json.NewDecoder(r.Body) and does not wrap the reader with http.MaxBytesReader.
When a message arrives, Mailpit expands the raw frame through multiple in-memory stages: the enmime envelope tree, a search-text index, and a zstd-encoded write to SQLite. Each stage retains copies or derived representations, producing an amplification factor of approximately seven to ten times the input. Repeated or concurrent submissions accumulate resident memory until the kernel issues an OOM-kill against the process.
Root Cause
The root cause is missing input validation on message size at both network entry points. Mailpit relies on a configurable ceiling that was never wired into the SMTP server initialization path, and it omits the standard http.MaxBytesReader guard on the JSON send endpoint. Both listeners default to binding all interfaces with no authentication, expanding the reachable attack surface.
Attack Vector
An unauthenticated attacker with network access to Mailpit sends a single large SMTP DATA payload or a large JSON body to /api/v1/send. Because no upper bound exists, the server accepts the payload and begins parsing and indexing it in memory. Running the request concurrently from multiple connections accelerates memory exhaustion and terminates the process.
See the GitHub Security Advisory GHSA-fpxj-m5q8-fphw for the vendor's technical description.
Detection Methods for CVE-2026-45713
Indicators of Compromise
- Sudden RAM growth on hosts running Mailpit, followed by process termination and OOM entries in dmesg or journalctl.
- Inbound SMTP sessions to port 1025 or HTTP requests to /api/v1/send on port 8025 with Content-Length values in the tens or hundreds of megabytes.
- Repeated Mailpit restarts logged by the service manager without a clean shutdown reason.
Detection Strategies
- Monitor process resident set size (RSS) for Mailpit and alert when growth exceeds a baseline threshold within a short window.
- Inspect reverse proxy or load balancer logs for unusually large POST bodies targeting /api/v1/send.
- Correlate SMTP session byte counts on port 1025 against expected developer test message sizes.
Monitoring Recommendations
- Enable host-level memory and OOM-kill telemetry forwarded to a central SIEM or data lake for correlation.
- Capture network flow records for the Mailpit ports and alert on outlier byte volumes per source address.
- Track Mailpit service restart counts as a leading indicator of resource exhaustion attempts.
How to Mitigate CVE-2026-45713
Immediate Actions Required
- Upgrade Mailpit to version 1.30.0 or later, which enforces size limits on both SMTP and HTTP ingestion paths.
- Restrict network access to ports 1025 and 8025 so only trusted developer workstations or CI runners can reach them.
- Place Mailpit behind a reverse proxy that enforces a maximum request body size for /api/v1/send.
Patch Information
The fix is included in Mailpit 1.30.0. Details are available in the GitHub Mailpit Release v1.30.0 notes and the GitHub Security Advisory GHSA-fpxj-m5q8-fphw.
Workarounds
- Bind Mailpit listeners to 127.0.0.1 instead of [::] to eliminate remote exposure until patching completes.
- Front the HTTP API with a reverse proxy such as nginx or Caddy configured with client_max_body_size set to a low value.
- Apply firewall rules or container network policies that block external connections to ports 1025 and 8025.
- Enforce cgroup memory limits on the Mailpit process so a single instance cannot consume host memory beyond a defined ceiling.
# Configuration example: nginx reverse proxy limiting body size to 5 MB
server {
listen 8025;
client_max_body_size 5m;
location / {
proxy_pass http://127.0.0.1:8025;
proxy_set_header Host $host;
}
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

