Injection vulnerabilities generally occur when some data (usually text) is parsed and used to control behavior. In the case of SMTP Injection, this occurs in the code used to parse text to create an SMTP request.

An attacker needs to know what programming language and the library a backend uses to perform SMTP injection. Let’s ignore the how of this and assume that our attacker, somehow, knows about a vulnerable website. The exact injection method varies from library to library, and not all libraries are vulnerable, so our attacker will need to do some research.

Luckily for our attacker, our example website uses an incredibly naive approach: It places the required information, including the user-provided message and return address, into a text file. It then runs a command called sendmail through the system shell, passing in the text file, which is parsed and used to generate an SMTP request. This is a worst-case scenario because it doesn’t require any clever tricks on the part of our attacker: They can paste a list of BCC email addresses into the message field, and sendmail will obediently add those addresses to the headers when it processes the message.

Usually, the process is a little more complicated, requiring the attacker to insert special characters like > and/or encoded characters like \r\n (a line break) into a field that is used specifically to generate headers (the return address field is a common choice).