What is header injection?

Header injection is when someone tricks your mail server into adding extra headers that weren't supposed to be there. Think of it as sneaking instructions into a package right before it ships.

The attack works through contact forms or any place where user input gets turned into email headers. An attacker types something like this into a Subject field: Help\r\nBCC: 1000-spam-victims@example.com. That \r\n sequence is a carriage return and line feed. It tells the mail server "new line, new header". If your code doesn't clean that input, the server will read it as two separate headers: one Subject line ("Help") and one BCC line with 1,000 unwanted recipients.

What happens next is the bad part. The server sends your email to all those injected addresses using your domain's reputation. Your IP gets used to spam strangers. Your domain gets blocklisted. You get blamed for mail you never intended to send.

This is why every field that touches email headers (Subject, To, From, Reply-To, anything) needs to be sanitized before it reaches the mail library. That means stripping out \r and \n characters, or encoding them so they can't be interpreted as header delimiters. Most modern email libraries handle this automatically if you use them correctly. The mistake happens when developers concatenate strings by hand instead of using the library's safe methods.

And if you're building anything with a contact form, check how your code generates outgoing email. Does it use a library like Nodemailer, PHPMailer, or your ESP's official SDK? Good. Does it build headers by gluing strings together with + or template literals? That's the danger zone.

Worth testing your forms with inputs that contain \r\n sequences to see if they get through. If they do, fix it before someone else finds it. If you're stuck, our SOS hotline can walk you through what safe header handling looks like for your stack.