Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
15 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Mailpit's SMTP server reads each command line with an unbounded bufio.Reader.ReadString('\n') before parsing the command or enforcing any protocol length limit. A remote SMTP client can send an oversized single command line and force Mailpit to allocate attacker-controlled memory before the server returns a syntax error or times out, even though RFC 5321 limits SMTP command lines to 512 octets including CRLF. Technical Details Mailpit enables SMTP by default. config/config.go sets SMTPListen = "[::]:1025", and cmd/root.go calls smtpd.Listen() during normal startup. The SMTP server configures recipient and message DATA size limits in internal/smtpd/main.go, including the default 50 MiB MaxMessageSize, but those limits do not apply to command lines. The vulnerable path is in the SMTP command loop. internal/smtpd/smtpd.go calls s.readLine() for every command before parsing the verb or arguments: readLine() then buffers until newline without a maximum length: This violates the…
Recommended action: Upgrade to 1.30.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Mailpit's thumbnail endpoint decodes attacker-supplied image attachments into a full raster before checking any decoded-pixel, dimension, or memory budget. A remote client that can store an email and reach the default web API can supply a compact high-dimension image, then request /api/v1/message/{id}/part/{partID}/thumb to force server-side memory and CPU work far larger than the encoded attachment size before Mailpit returns a 180x120 thumbnail. Technical Details The route is registered as GET /api/v1/message/{id}/part/{partID}/thumb in server/server.go. The handler in server/apiv1/thumbnails.go loads the requested attachment and accepts any part whose content type begins with image/: storage.GetAttachmentPart() reparses the stored raw email and returns the matching attacker-supplied attachment bytes. Thumbnail() then calls imaging.Decode() before any check on declared dimensions or estimated decoded bytes. The subsequent imaging.Fill(img, 180, 120, ...), imaging.Clone(),…
Recommended action: Upgrade to 1.30.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/axllent/mailpit >= 1.29.0, <= 1.30.5
Fixed in
1.30.6· Vendor fix available
Issue
The cross-site WebSocket hijacking fix was reimplemented as an origin check gated on a raw-URI prefix test, but Go's ServeMux routes on the percent-decoded path, so requesting /%61pi/events reaches the WebSocket handler while skipping the only origin control, and the upgrader itself accepts every origin. Confirmed at HEAD 408b30d. Affects 1.29.0 through 1.30.5. The defect Two halves that were each correct in isolation. server/websockets/client.go accepts any origin and delegates the check elsewhere: server/server.go performs that check but keys it on the RAW request target: r.RequestURI is the untouched wire target; Go's ServeMux routes on the percent-DECODED path. So for /%61pi/events: strings.HasPrefix("/%61pi/events", "/api/") is FALSE (origin check skipped), ServeMux decodes %61 to "a" and routes to /api/events, and the upgrader's CheckOrigin returns true. Measured, default config, no auth: /api/events with Origin: https://evil.example returns 403; /%61pi/events with the…
Recommended action: Upgrade to 1.30.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Mailpit's SMTP DATA reader enforces the configured MaxMessageSize only after bufio.Reader.ReadBytes('\n') has already buffered a complete DATA line. A remote unauthenticated SMTP client can send one line larger than the configured message-size cap and force memory allocation before Mailpit returns the expected 552 5.3.4 rejection, leaving patched versions still exposed to a single-line incomplete-fix variant of the earlier SMTP DATA body-size issue. Technical Details Mailpit enables SMTP by default. The SMTP server now wires config.MaxMessageSize into srv.MaxSize: The DATA reader then checks that cap, but only after reading a full newline-terminated line into memory: This ordering violates the size-limit invariant. The configured cap can reject the message only after the attacker has supplied the line terminator and ReadBytes('\n') has allocated the over-limit line. With the default 50 MiB cap, a 64 MiB single DATA line is still buffered before Mailpit returns 552 5.3.4…
Recommended action: Upgrade to 1.30.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for GHSA-fpxj-m5q8-fphw (CVE-2026-45710, "Mailpit: Set a default 50MB p/m limit to prevent DoS via unlimited SMTP DATA and /api/v1/send body sizes") wrapped only POST /api/v1/send with http.MaxBytesReader. The four other Mailpit JSON-body API endpoints PUT /api/v1/messages (SetReadStatus), DELETE /api/v1/messages (DeleteMessages), PUT /api/v1/tags (SetMessageTags), and POST /api/v1/message/{id}/release (ReleaseMessage) still call json.NewDecoder(r.Body) directly with no body-size cap and remain reachable unauthenticated in the default docker run axllent/mailpit:latest deploy. An unauthenticated remote attacker can post a multi-million-element IDs slice and drive RSS from ~25 MiB baseline to ~450 MiB per 16 MB request body. Repeating across multiple connections accumulates the same per-request amplification per process. Affected versions - Mailpit at HEAD 67a7ca83ff759082d2b86dda07eb5bb3dad404e0 (v1.30.0, 2026-05-14). - All versions <= v1.30.0 (the release that shipped…
Recommended action: Upgrade to 1.30.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The remediation shipped in mailpit v1.29.2 for GHSA-mpf7-p9x7-96r3 (CVE-2026-27808) is incomplete. The tools.IsInternalIP deny-list relies on Go's stdlib classification helpers (IsLoopback, IsPrivate, IsLinkLocalUnicast, IsLinkLocalMulticast, IsUnspecified, IsMulticast) plus an inline CGNAT range, but those helpers do not match two classes of IPv6 address that should be blocked for SSRF purposes: 1. IPv6 forms that embed an IPv4 destination via documented translation mechanisms — 6to4, NAT64, IPv4-compatible IPv6, ISATAP, or (in older Go versions) IPv4-mapped IPv6. These let an attacker reach internal IPv4 destinations by supplying an IPv6 literal that encodes the desired IPv4. 2. IPv6 prefixes that fall outside the narrow private/loopback/link-local ranges Go's stdlib classifies — specifically the deprecated site-local prefix fec0::/10 (RFC 3879/4291) and the documentation prefix 2001:db8::/32 (RFC 3849). The first is still routable on dual-stack hosts and is cited as a…
Recommended action: Upgrade to 1.30.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details Pre-auth, remote DoS on every Mailpit deployment running the default configuration. Memory is the primary axis; disk is a secondary one, because each…
Recommended action: Upgrade to 1.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The screenshot/print proxy (/proxy?data=…) maintains a package-level assets map[string]MessageAssets cache, but reads the map without holding assetsMutex while a long-running cleanup goroutine and (re-entrant) CSS-rewriting code path concurrently write to it under the lock. When the unsynchronized read coincides with a synchronized write, Go's runtime raises fatal error: concurrent map read and map write — a runtime.throw that is not recoverable by http.Server's handler-panic recover. The whole Mailpit process exits, taking the SMTP, POP3 and HTTP listeners down with it. Details A remote, unauthenticated attacker who can (1) reach /proxy and (2) plant any message with a stylesheet link in the inbox can crash Mailpit by issuing concurrent /proxy?data=… requests against the same message's CSS URL. Mailpit's defaults make both prerequisites trivial: the SMTP listener accepts mail anonymously, the HTTP listener accepts requests anonymously, and the cleanup goroutine fires every…
Recommended action: Upgrade to 1.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The mailpit dump --http <base-url <out-dir sub-command downloads every message from a remote Mailpit instance and writes each one as <id.eml inside the user-supplied output directory. The message ID field is taken verbatim from the JSON response of the remote server and concatenated into the output path with path.Join, which silently normalizes .. segments. A malicious HTTP server impersonating Mailpit can therefore make mailpit dump write attacker-controlled bytes to any path the running user can write, fully outside the intended output directory. Details Anyone who can convince a user to run mailpit dump --http <attacker-url <dir (typosquat, phishing tutorial, MITM of a plain-http:// Mailpit, or a compromised internal Mailpit they back up regularly) obtains an arbitrary file write primitive as the dumping user. Realistic post-exploitation includes overwriting init/cron files, shell startup files, CI artifact upload targets, web roots, etc. — anything the dumping user can…
Recommended action: Upgrade to 1.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for GHSA-6jxm-fv7w-rw5j (CVE-2026-23845, "Server-Side Request Forgery (SSRF) via HTML Check API"), shipped in mailpit v1.28.3, hardened internal/htmlcheck/css.go::downloadCSSToBytes with a 5MB size cap, a text/css content-type check, login-info stripping in isValidURL, and an opt-in --block-remote-css-and-fonts config flag — but did not add the IP-filtering dialer that the same codebase already uses on the two sister SSRF endpoints (the proxy handler and link-check). At HEAD 8bc966e61834a24c48b4465da418f75e73be0afd (2026-05-06), internal/htmlcheck/css.go::newSafeHTTPClient is mis-named — it builds an http.Client whose Transport.DialContext calls net.Dialer.DialContext directly with no IP allowlisting. As a result, the SSRF originally reported by Bao Anh Phan still permits the server to dial: - loopback (127.0.0.0/8, ::1), - private (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7), - link-local incl. cloud IMDS (169.254.0.0/16, especially 169.254.169.254), - CGNAT…
Recommended action: Upgrade to 1.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Link Check API (/api/v1/message/{ID}/link-check) is vulnerable to Server-Side Request Forgery (SSRF). The server performs HTTP HEAD requests to every URL found in an email without validating target hosts or filtering private/internal IP addresses. The response returns status codes and status text per link, making this a non-blind SSRF. In the default configuration (no authentication on SMTP or API), this is fully exploitable remotely with zero user interaction. This is the same class of vulnerability that was fixed in the HTML Check API (CVE-2026-23845 / GHSA-6jxm-fv7w-rw5j) and the screenshot proxy (CVE-2026-21859 / GHSA-8v65-47jx-7mfr), but the Link Check code path was not included in either fix. Details The doHead() function in https://github.com/axllent/mailpit/blob/v1.29.0/internal/linkcheck/status.go#L59-L98 creates a plain http.Transport{} and http.Client with no DialContext hook or IP validation: The call chain is: 1. GET /api/v1/message/{ID}/link-check hits…
Recommended action: Upgrade to 1.29.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Server-Side Request Forgery (SSRF) via HTML Check CSS Download The HTML Check feature (/api/v1/message/{ID}/html-check) is designed to analyze HTML emails for compatibility. During this process, the inlineRemoteCSS() function automatically downloads CSS files from external <link rel="stylesheet" href="..." tags to inline them for testing. Affected Components - Primary File: internal/htmlcheck/css.go (lines 132-207) - API Endpoint: /api/v1/message/{ID}/html-check - Handler: server/apiv1/other.go (lines 38-75) - Vulnerable Functions: - inlineRemoteCSS() - line 132 - downloadToBytes() - line 193 - isURL() - line 221 Technical Details 1. Insufficient URL Validation (isURL() function): 2. Unrestricted Download (downloadToBytes() function): 3. Automatic CSS Processing: Attack Vectors Attack Vector 1: Cloud Metadata Credential Theft Attacker sends HTML email with: When HTML check is triggered: 1. Mailpit makes GET request to AWS metadata endpoint 2. Downloads IAM credentials as "CSS…
Recommended action: Upgrade to 1.28.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Report: SMTP Header Injection via Regex Bypass Vulnerable Code: mailpit/internal/smtpd/smtpd.go Executive Summary Mailpit's SMTP server is vulnerable to Header Injection due to an insufficient Regular Expression used to validate RCPT TO and MAIL FROM addresses. An attacker can inject arbitrary SMTP headers (or corrupt existing ones) by including carriage return characters (\r) in the email address. This header injection occurs because the regex intended to filter control characters fails to exclude \r and \n when used inside a character class. RFC Compliance & Design Analysis "Is this behavior intentional for a testing tool?" No. While testing tools are often permissive, this specific behavior violates the core SMTP protocol and fails the developer's own intent. 1. RFC 5321 Violation: The SMTP protocol strictly forbids Control Characters (CR, LF, Null) in the envelope address (Mailbox). RFC 5321 Section 4.1.2: A Mailbox consists of an Atom or Quoted-string. An Atom…
Recommended action: Upgrade to 1.28.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/axllent/mailpit >= 1.2.6, < 1.28.2; < 0.0.0-20260110031614
Fixed in
0.0.0-202601100316141.28.2· Vendor fix available
Issue
The Mailpit WebSocket server is configured to accept connections from any origin. This lack of Origin header validation introduces a Cross-Site WebSocket Hijacking (CSWSH) vulnerability. An attacker can host a malicious website that, when visited by a developer running Mailpit locally, establishes a WebSocket connection to the victim's Mailpit instance (default ws://localhost:8025). This allows the attacker to intercept sensitive data such as email contents, headers, and server statistics in real-time. Vulnerable Code The vulnerability exists in server/websockets/client.go where the CheckOrigin function is explicitly set to return true for all requests, bypassing standard Same-Origin Policy (SOP) protections provided by the gorilla/websocket library. https://github.com/axllent/mailpit/blob/877a9159ceeaf380d5bb0e1d84017b24d2e7b361/server/websockets/client.go#L34-L39 Impact This vulnerability impacts the Confidentiality of the data stored in or processed by Mailpit. Although…
Recommended action: Upgrade to 1.28.2 or 0.0.0-20260110031614 (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server-Side Request Forgery (SSRF) vulnerability exists in Mailpit's /proxy endpoint that allows attackers to make requests to internal network resources. Description The /proxy endpoint allows requests to internal network resources. While it validates http:// and https:// schemes, it does not block internal IP addresses, allowing attackers to access internal services and APIs. Proof of Concept Basic SSRF Request This returns internal API data including database path and runtime statistics. Impact Assessment 1. Internal Network Scanning Attacker can probe and discover internal services on the network. 2. Information Disclosure Access to internal API data, database paths, and runtime statistics. 3. Email Content Access Ability to read all captured emails via internal API endpoints. 4. Cloud Metadata Access If deployed in cloud environments (AWS/GCP/Azure), potential access to instance metadata services (e.g., http://169.254.169.254/). Attack Scenarios Scenario 1: Development…
Recommended action: Upgrade to 1.28.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.