SMTP Header Injection

What SMTP header injection is, and why it matters

SMTP header injection is a message-building flaw, not a mail-server flaw. It appears when untrusted input reaches header fields without filtering carriage return and line feed characters, allowing attacker-controlled text to become new headers or extra message content.

The practical danger is that the application loses control over the structure of the email it is sending. That can let an attacker rewrite recipients, change subject lines, add blind copy targets, alter reply paths, or manipulate other metadata that downstream mail systems and users trust.

How header injection happens in mail-sending code

The weakness usually starts with unsafe string concatenation. If an application inserts user input into fields such as From, To, Cc, Subject, Reply-To, or custom MIME headers and does not neutralise line breaks, the SMTP parser may treat the injected newline as the start of a new header.

This is closely related to other input-boundary failures, but the issue here is specific: the application is mixing data and protocol structure. Once the boundary is broken, validation that only checks for an email address format is not enough, because the attack is about creating additional header syntax, not just supplying a malformed address.

It often shows up in forms, ticketing systems, password reset workflows, contact pages, notification engines, and any feature that sends mail from user-controlled content. When the input is later copied into the outbound message, the attacker can steer how the message is interpreted before it leaves the application.

What can be changed or abused in the email

Injected headers can change message semantics in ways that look legitimate to recipients and mail infrastructure. An attacker may add hidden recipients, modify the subject to improve social engineering, redirect replies, or create multipart content that carries a second message body.

Because these changes happen before delivery, downstream controls may see a perfectly valid SMTP transaction. That makes the attack useful for phishing, message tampering, and abuse of trusted application mail flows, especially where the application sends security-sensitive notifications.

Header injection can also undermine auditability. If recipients, headers, or MIME structure are altered silently, logs and application records may no longer reflect the actual content that was sent, which complicates incident review and user trust.

How to prevent it in applications and mail pipelines

The safest pattern is to treat header fields as structured data, not free-form strings. Applications should validate each field against the exact format the field allows, reject carriage return and line feed characters, and use mail libraries that build headers safely instead of hand-assembling raw SMTP text.

Security reviewers should pay close attention to any code path that copies user input into mail templates or notification services. The Web Application Attacks Guide is useful background when you want to recognise how injection flaws cross trust boundaries, and the Command Injection Guide helps frame the broader danger of unsafe input handling in execution paths.

Defensive review should also include the mail transport layer. The Network Ports and Protocols Security Guide provides useful context for SMTP as a protocol surface, while OWASP Top 10 remains a useful high-level reference for injection-style application weaknesses and input handling failures.

Risk and Threat Considerations

SMTP header injection is dangerous because it turns a trusted application mail channel into a message-tampering surface. The attacker does not need to break mail delivery, only to smuggle protocol control characters into a field the application assumes is data.

Failure mechanism: If CR and LF characters are accepted in a header value, the SMTP parser may interpret attacker-supplied text as a new header block, enabling recipient manipulation, content injection, or message rewriting.

Impact: The result can include phishing assistance, unauthorized disclosure through added recipients, altered notification semantics, and loss of trust in outbound email controls and records.

Practitioner Guidance

Why practitioners should care: Any feature that sends mail on behalf of users should be reviewed as a security boundary, not a convenience function. Header injection often survives basic validation because the input may look like a harmless string until it is rendered into SMTP syntax.

What to watch for: Look for manual header assembly, template engines that insert raw user content into mail headers, and code that validates only the visible address while ignoring control characters. Test not just the recipient fields, but every header and any user-controlled value that can reach the outbound message.

Practitioner takeaway: Safe mail generation depends on strict field-level encoding and on eliminating raw line-break handling from every path that constructs outbound email.

Related resources from NHI Mgmt Group

• What breaks when a dependency CVE depends on header injection but the runtime blocks it?
• Who is accountable when Host header injection leads to SSRF exposure in a web application?
• Why does HTTP header injection create a broader account takeover risk than a simple response manipulation issue?
• What happens when header injection is combined with stored XSS in an authentication workflow?