CVE-2026-45713 in mailpit
Summary
by MITRE • 07/20/2026
Mailpit is an email testing tool and API for developers. Prior to version 1.30.0, 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. Version 1.30.0 contains a patch.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/20/2026
The vulnerability in Mailpit versions prior to 1.30.0 represents a critical resource exhaustion flaw that stems from improper configuration of size limits within the SMTP and HTTP server components. The core issue manifests through two distinct but related pathways that together create a severe denial-of-service condition. The Server.MaxSize field, intended to control maximum DATA payload size in the SMTP server, remains unassigned outside of test scenarios, defaulting to Go's zero value of 0 which translates to "no limit" in the application context. This configuration creates an implicit vulnerability where malicious actors can submit arbitrarily large email messages without restriction, directly impacting system memory management and resource allocation.
The HTTP endpoint at /api/v1/send presents a complementary weakness that compounds the problem through the lack of request body size limitation during JSON decoding operations. The implementation relies on json.NewDecoder(r.Body) without wrapping it with http.MaxBytesReader to enforce size constraints, allowing attackers to submit massive JSON payloads that exceed normal processing boundaries. This dual vulnerability creates a particularly dangerous scenario because Mailpit's default configuration binds listeners to all interfaces [::]:1025 for SMTP and [::]:8025 for HTTP, with no authentication requirements for either service. When combined with the absence of size limits in both protocols, this configuration exposes the application to network-reachable attackers who can exploit these weaknesses without any authorization barriers.
The operational impact of this vulnerability reaches severe levels through memory consumption amplification factors that can exceed 7-10 times the original payload size. The processing pipeline for incoming messages creates substantial memory overhead as raw email frames are transformed into enmime envelope trees, followed by search-text indexing operations, and finally compressed writes to SQLite databases using zstd encoding. This multi-stage processing creates a cascading effect where each incoming message consumes exponentially more memory than its transmitted size, making even moderately sized attacks capable of overwhelming system resources. The amplification factor combined with the lack of authentication requirements means that attackers can repeatedly target the service or execute concurrent attacks across multiple connections to drive processes into out-of-memory conditions that result in system termination.
This vulnerability aligns with CWE-400, which covers "Uncontrolled Resource Consumption," specifically addressing unlimited resource consumption through improper input validation and lack of size limits. The attack vector also maps to ATT&CK technique T1499.001, which describes "Network Denial of Service" through resource exhaustion attacks that target application memory or processing capabilities. The combination of these factors creates a straightforward yet highly effective means of causing system instability and service disruption for any Mailpit instance running vulnerable versions. The patch implemented in version 1.30.0 addresses both the SMTP server MaxSize field assignment issue and introduces proper request body size limitations for HTTP endpoints, effectively closing this resource exhaustion attack surface.
The security implications extend beyond simple denial-of-service conditions to include potential data integrity concerns when systems are repeatedly subjected to memory pressure attacks that could cause database corruption or inconsistent state conditions. Organizations deploying Mailpit in production environments without proper network segmentation or authentication controls face significant risk from these vulnerabilities. The default configuration of binding to all interfaces with no authentication creates an inherently insecure baseline that makes the vulnerability exploitable by any attacker with network access to the service. System administrators should immediately upgrade to version 1.30.0 or later while also implementing appropriate network controls and authentication mechanisms to prevent unauthorized access to these services in environments where they are deployed without proper security boundaries.