CVE-2026-67446 in Mailpit
Summary
by MITRE • 08/21/2026
Mailpit is an email testing tool and API for developers. Prior to 1.30.4, Mailpit decodes attacker-supplied image attachments into a full raster before checking decoded dimensions, pixel count, or memory use in the GET /api/v1/message/{id}/part/{partID}/thumb endpoint. The Thumbnail handler in server/apiv1/thumbnails.go obtains attachment bytes through storage.GetAttachmentPart(), accepts image/* content, and calls imaging.Decode() with AutoOrientation before imaging.Fill() scales the image to 180 by 120 pixels. A compact image declaring very large dimensions can therefore consume disproportionately large memory and CPU, and opening the message UI can trigger the same endpoint through server/ui-src/components/message/MessageAttachments.vue. This can degrade availability when an unauthenticated client can store the crafted attachment and reach the web API. This issue is fixed in version 1.30.4.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/21/2026
Mailpit serves as a specialized email testing tool and application programming interface designed for developers to inspect and debug incoming messages. A critical vulnerability exists within versions prior to 1.30.4, specifically affecting the thumbnail generation mechanism exposed through the GET /api/v1/message/{id}/part/{partID}/thumb endpoint. This flaw represents a significant resource exhaustion risk that can be exploited by unauthenticated attackers who have previously stored malicious attachments in the system. The core of the issue lies in the order of operations performed during image processing, where the application prioritizes rendering over validation, leading to disproportionate consumption of server resources and potential denial of service conditions for legitimate users.
The technical flaw originates in the Thumbnail handler located within the server/apiv1/thumbnails.go module. When a request is made to generate a thumbnail for an email attachment with an image content type, the system retrieves the raw bytes via storage.GetAttachmentPart(). Instead of performing preliminary checks on the metadata or structural integrity of the image file before processing it, the application immediately invokes imaging.Decode() with AutoOrientation enabled. This function attempts to decode the entire image into a full raster format in memory. Only after this computationally expensive and memory-intensive operation is complete does the system proceed to check decoded dimensions, pixel count, or estimated memory usage. Subsequently, imaging.Fill() scales the fully decoded image down to 180 by 120 pixels for display purposes. This sequence creates a window of vulnerability where an attacker can supply a file that appears small in size but declares extremely large width and height values in its header metadata.
This specific attack vector relies on what is commonly known as a "billion laughs" or image bomb scenario, adapted for raster graphics processing. By crafting an image with compact binary data but declaring massive dimensions, such as millions of pixels wide and high, the imaging library allocates memory proportional to the declared pixel count rather than the actual file size. For instance, an image claiming one billion pixels could require several gigabytes of RAM to decode into a raster format. Since this endpoint is accessible via standard HTTP requests, any user with access to the Mailpit interface can trigger this process. Furthermore, the vulnerability is exacerbated by client-side behavior; opening the message UI in server/ui-src/components/message/MessageAttachments.vue automatically triggers calls to this thumbnail generation endpoint for all attached images. Consequently, a single malicious attachment stored in an email can cause severe degradation of availability when viewed through the web interface or accessed directly via the API.
From a security classification perspective, this vulnerability aligns with CWE-400: Uncontrolled Resource Consumption and CWE-789: Memory Allocation with Unlimited Input. The failure to validate input dimensions prior to resource allocation is a classic example of improper check before expected action. In terms of attack tactics, this corresponds to the ATT&CK technique T1496: Resource Hijacking, where an attacker consumes computational resources to degrade service availability for other users. While Mailpit is primarily intended as a development tool and may not always be exposed to untrusted networks, it is frequently deployed in environments where multiple developers or services interact with email data. An unauthenticated actor who has managed to store a crafted attachment can exploit this flaw without needing valid credentials, making the risk profile higher than initially apparent for an internal testing utility.
The operational impact of this vulnerability includes severe performance degradation and potential service crashes due to out-of-memory errors on the server hosting Mailpit. Because the resource exhaustion occurs during the decoding phase, it consumes both CPU cycles for image processing and significant amounts of RAM for storing the raster data. This can lead to a denial of service condition where legitimate users are unable to access email messages or view thumbnails. In containerized environments common in modern development workflows, such memory spikes could trigger automatic restarts of the Mailpit pod or container, disrupting ongoing debugging sessions and potentially causing loss of transient test data if not persisted externally.
To mitigate this vulnerability, organizations running versions prior to 1.30.4 must upgrade immediately to version 1.30.4, which implements proper validation logic before image decoding occurs. Until the update is applied, administrators should restrict network access to the Mailpit interface to trusted internal networks only and ensure that no untrusted users can store attachments within the system. Additionally, implementing rate limiting on the thumbnail generation endpoint can help mitigate the impact of repeated exploitation attempts. For development environments where exposure cannot be fully restricted, deploying a reverse proxy with strict request size limits and timeout configurations may provide an additional layer of defense against resource exhaustion attacks targeting image processing endpoints.