CVE-2026-67447 in Mailpit
Summary
by MITRE • 08/21/2026
Mailpit is an email testing tool and API for developers. From 1.30.0 until 1.30.5, Mailpit's internal/smtpd/smtpd.go readData() function calls bufio.Reader.ReadBytes before applying the len(data)+len(line) size check to the completed SMTP DATA line against Server.MaxSize. An unauthenticated SMTP client can send a single line larger than the configured MaxMessageSize, causing the full line to be allocated before Mailpit returns the 552 5.3.4 rejection. This post-fix gap remains after normal multi-line DATA accumulation was bounded, and concurrent oversized lines can create substantial memory pressure beyond the configured message-size cap. This issue is fixed in version 1.30.5.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified within Mailpit versions ranging from 1.30.0 to 1.30.5 represents a critical resource exhaustion flaw rooted in improper input validation and memory allocation sequencing during the SMTP DATA command processing phase. As an email testing tool designed for developers, Mailpit operates as an SMTP server that must handle incoming message data streams. The core technical defect resides within the internal/smtpd/smtpd.go module, specifically inside the readData function which is responsible for parsing the content of emails sent by clients. In a secure implementation, size constraints should be enforced before any significant memory allocation occurs to prevent attackers from triggering excessive resource consumption. However, in this vulnerable version, the application logic dictates that bufio.Reader.ReadBytes is invoked to consume and store the incoming data line into memory prior to evaluating whether the cumulative length of the data plus the current line exceeds the Server.MaxSize configuration limit. This inversion of operations creates a window where an unauthenticated attacker can exploit the system by sending a single SMTP DATA line that surpasses the configured MaxMessageSize threshold.
From a technical perspective, this flaw allows for a denial-of-service attack through memory exhaustion. When an unauthenticated client submits a message with a data line larger than the allowed limit, the server does not reject the request immediately upon detecting the size violation. Instead, it proceeds to allocate heap memory sufficient to hold the entire oversized line via the ReadBytes operation. Only after this allocation is complete does Mailpit evaluate the length and return an error code 552 with a status of 5.3.4 indicating that the message was too large. While single instances of this behavior result in isolated memory spikes, the vulnerability becomes significantly more dangerous under concurrent load conditions. Multiple simultaneous connections from unauthenticated clients can each trigger these oversized allocations concurrently. This leads to substantial memory pressure on the server host, potentially causing the Mailpit process to crash due to out-of-memory errors or degrading performance for other legitimate users sharing the same infrastructure resources. The issue persists even though normal multi-line DATA accumulation was previously bounded, highlighting that this specific gap in single-line handling remained unaddressed until the patch release.
This vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-787: Out-of-bounds Write and more specifically CWE-400: Uncontrolled Resource Consumption. The failure to validate input size before resource allocation is a classic pattern leading to denial of service conditions, often categorized under the MITRE ATT&CK technique T1496: Resource Hijacking or potentially T1498: Network Denial of Service depending on the broader impact on network availability. By allowing unauthenticated actors to force large memory allocations without prior validation, Mailpit exposes itself to abuse that can disrupt service continuity. The operational impact is primarily a denial-of-service condition where the integrity and availability of the email testing environment are compromised by resource starvation rather than data exfiltration or code execution.
The recommended mitigation for this vulnerability is straightforward: upgrade the Mailpit installation to version 1.30.5 or later, which contains the fix that corrects the ordering of size checks relative to memory allocation. For organizations unable to immediately patch their environments due to operational constraints, temporary mitigations should focus on network-level controls. Deploying a reverse proxy such as Nginx or HAProxy in front of Mailpit can enforce strict limits on request body sizes and connection rates. Configuring these proxies to reject SMTP DATA commands that exceed specific byte thresholds before they reach the Mailpit application will effectively neutralize this vulnerability by preventing the oversized payloads from ever triggering the flawed internal logic. Additionally, implementing rate limiting for unauthenticated connections can further reduce the risk of concurrent exploitation attempts leading to resource exhaustion.