| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/axllent/mailpit | < 1.28.3 | 1.28.3 |
| mailpit | < 1.28.3 | 1.28.3 |
Vulnerable Code: mailpit/internal/smtpd/smtpd.go
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.
"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.
Mailbox).
Mailbox consists of an Atom or Quoted-string. An Atom explicitly excludes "specials, SPACE and CTLs" (Control Characters).\v in the regex [^<>\v] proves the developer intended to block vertical whitespace. The vulnerability is that \v in Go regex (re2) inside brackets [] matches only Vertical Tab, not CR/LF. If the design were to allow everything, the \v exclusion wouldn't exist.\r results in the generation of malformed .eml files where the Received header is broken. This is not a feature; it's a bug that creates invalid email files.The vulnerability exists in the regex definitions used to parse SMTP commands:
// internal/smtpd/smtpd.go:32-33
rcptToRE = regexp.MustCompile(`(?i)TO: ?<([^<>\v]+)>( |$)(.*)?`)
mailFromRE = regexp.MustCompile(`(?i)FROM: ?<(|[^<>\v]+)>( |$)(.*)?`)
The developer likely intended [^<>\v] to mean "Match anything that is NOT a < OR > OR Vertical Whitespace".
However, in Go's regexp (RE2) syntax, the behavior of \v changes depending on context:
\v matches all vertical whitespace: [\n\v\f\r\x85\u2028\u2029].[...]): \v matches only the Vertical Tab character (\x0B).Result: The regex [^<>\v] allows Carriage Return (\r) and Line Feed (\n) characters to pass through, as they are not < or > or \x0B.
When Mailpit constructs the Received header, it uses the validated recipient address directly:
// internal/smtpd/smtpd.go:865
buffer.WriteString(fmt.Sprintf(" for <%s>; %s\r\n", to[0], now))
If to[0] contains victim\rINJECTED-HEADER: YES, the resulting string in memory becomes:
for <victim\rINJECTED-HEADER: YES>; ...
While bufio.ReadString prevents injecting immediate \n (newlines), \r (Carriage Return) bypasses this check.
The Result: The stored EML file contains a "Bare CR".
victim INJECTED in the Mailpit UI.The following screenshot of the raw .eml file confirms that the \r character successfully broke the Received header structure in the stored file, effectively creating a new line for the injected content.
As seen in lines of the screenshot:
for <victim
INJECTED_VIA_CR:YES>; Tue, 13 Jan ...
The INJECTED_VIA_CR:YES payload is treated as a start of a new line by the text editor (VS Code), which honors \r as a line break. This proves the injection matches the "Bare CR" attack vector.
\x00)The regex [^<>\v]+ also allows the Null Byte (\x00).
Test: test_null_byte.py sent RCPT TO:<victim\x00-NULL-BYTE-HERE>.
Result: Server accepted the message (250 OK).
Impact: The API returns an empty [] for the To field in the message summary, indicating the parser failure in the UI/API layer. The raw message content confirms the Null Byte is stored in the database.
Tests (0-127 ASCII) confirm that the regex [^<>\v] blocks only the following:
< (Less Than)> (Greater Than)\x0B (Vertical Tab)Crucially, it ALLOWS:
| Character | Hex | Regex Status | Network Status | Impact |
|---|---|---|---|---|
| Carriage Return | \r (0x0D) | ALLOWED | Passed | Header Injection |
| Line Feed | \n (0x0A) | ALLOWED | Blocked* | *Blocked by bufio.ReadString, not regex. |
| Null Byte | \x00 (0x00) | ALLOWED | Passed | API DoS / Corrupt Data |
| Tab | \t (0x09) | ALLOWED | Passed | Formatting issues |
| Delete | \x7F (0x7F) | ALLOWED | Passed | Potential obfuscation |
| Controls | 0x01-0x1F | ALLOWED | Passed | (Except 0x0A, 0x0B, 0x0D) |
This confirms that the regex fails to implement a proper "Safe Text" allowlist, defaulting instead to a flawed denylist.
The following Python script demonstrates the injection of a "bare CR" into the headers, which is successfully accepted by the server.
import socket
def exploit():
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("127.0.0.1", 1025))
s.recv(1024)
s.send(b"EHLO test.com\r\n")
s.recv(1024)
s.send(b"MAIL FROM:<[email protected]>\r\n")
s.recv(1024)
# Injecting \r
payload = b"RCPT TO:<victim\rX-Injected: Yes>\r\n"
s.send(payload)
resp = s.recv(1024)
print(f"Server Response: {resp.decode()}") # Expect 250 OK
s.send(b"DATA\r\n")
s.recv(1024)
s.send(b"Subject: Test\r\n\r\nBody\r\n.\r\n")
s.recv(1024)
s.close()
exploit()
Update the regex to explicitly exclude \r and \n, or use the correct character class escape for control characters.
Recommended Fix:
Use \x00-\x1F to exclude all ASCII control characters.
// Fix: Exclude all control characters explicitly
rcptToRE = regexp.MustCompile(`(?i)TO: ?<([^<>\x00-\x1f]+)>( |$)(.*)?`)
mailFromRE = regexp.MustCompile(`(?i)FROM: ?<(|[^<>\x00-\x1f]+)>( |$)(.*)?`)
Alternatively, strictly exclude CR and LF:
rcptToRE = regexp.MustCompile(`(?i)TO: ?<([^<>\r\n]+)>( |$)(.*)?`)
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free