CVE-2026-67446

Mailpit's thumbnail endpoint (GET /api/v1/message/{id}/part/{partID}/thumb) decodes attacker-supplied image attachments into a full raster before any dimension, pixel-count, or memory check, so a small encoded image can expand to tens or hundreds of MiB of decoded pixels before being scaled to a fixed 180x120 thumbnail. A remote client that can store a message and reach the web API can trigger the decode directly, and the web UI automatically requests these thumbnails via <img src> when a message with image attachments is opened. The result is a memory/CPU amplification denial of service: per the proof-of-value, a ~65 KB PNG decodes to ~64 MiB of RGBA data before scaling, and concurrent requests can exhaust host resources with availability impact only (no confidentiality or integrity loss). Any deployment running Mailpit with the API/UI reachable by untrusted clients is affected, including internet-exposed instances and shared dev/CI mail-catchers, while localhost-only installs are minimally exposed. Exploitation is not currently observed: EPSS is 0.4%, the flaw is not in CISA KEV, and no public PoC is known.

What to do: Upgrade Mailpit to the patched release once the vendor publishes it (no fixed version number is given in the available data) and verify the fix bounds decoded image dimensions/pixels before scaling. Until then, restrict the web UI/API to trusted networks or authenticated users, avoid exposing Mailpit directly to the internet, and limit untrusted message attachments or request rates. Note that the web UI auto-fetches thumbnails for image attachments, so even authenticated viewers of attacker-sent messages can trigger the amplification.