Email Phishing with HTML Injection
Contact forms are a really common feature on main company websites and brochureware sites - you've seen them before.
Something I haven't seen many people talk about, which I personally have reported on several occasions, is HTML injection in emails.
This vulnerability arises (as most application vulnerabilities do) when user input from these forms is inserted directly into emails without proper sanitization,
resulting in the ability to inject arbitrary HTML content into email bodies.
What makes this vulnerability particularly impactful is that the emails are sent from a trusted source (usually a "no-reply" or "noreply" email address)
and therefore are usually not picked up by inbox filters, and can lead to pretty sophisticated phishing emails.
Example Attack Scenario
Here's how an attacker might exploit this vulnerability:
- The attacker identifies a website with a contact form. This is one I found whilst bug bounty hunting:
- To test for the vulnerability, the attacker submits inputs with HTML syntax. In this case, I chose to use strong tags in all of the input fields.
- We got a confirmation email back with our inputs - and the strong tags were rendered. These conditions mean that the application is likely not sanitising HTML inputs, and therefore is potentially vulnerable. At this point, the attacker can use developer tools to determine the HTML structure of the email contents.
- The attacker then can construct their phish. A payload similar to the below could be used. This payload uses styling to change the appearance of the original email contents to 1px font size and transparent / while colouring, and includes further arbitrary HTML to create a phishing email.
- The result is a phishing email sent to the victim, from the company's no-reply email address. Because of the domain, the email provider even recognises the email as being sent as part of a mailing list. Cool right?




Now, obviously this is a basic example, and would be unlikely to get many clicks. However, a sophistacted phish could be constructed with the inclusion of images, scripts, stylesheets and more carefully thought-out HTML structures. It is also worth noting, your payload will need to be adjusted for the specific email software / application you are targeting - the above example targeted protonmail.
Impact
Here are some of the potential impacts of this vulnerability:
- Phishing from trusted sources - Emails come from the company's own domain, typically a "no-reply" or "noreply" email address. This can give the sense of legitimacy to the email, and increase the likelihood of the recipient interacting with the email.
- Email filter bypassing - These emails may bypass spam/phishing filters due to the origin.
- Damage to reputation - This type of attack could result in users or customers believing the email is legitimate and originated from the company. Depending on what an attacker decides to send, this has the potential for powerful defacement attacks. Furthermore, exploitation of this vulnerability at a larger scale could result in the domain being added to an email provider's blocklist.
Prevention Measures
Website owners can protect against this vulnerability by implementing these measures:
- Sanitize all user input on the server-side before including it in email templates. This could be through HTML encoding, or even better, by using an allow-list of characters. After all, why would you need to allow anything other than a-Z 0-9 and a few other characters?
Conclusion
HTML injection in contact form emails represents a significant but often overlooked security risk. By understanding this vulnerability and implementing proper input sanitization, organizations can protect themselves and users from sophisticated phishing attacks that leverage trusted domains.
Remember that security is a continuous process. Regularly audit your web applications for vulnerabilities like this one and stay updated on emerging threats and best practices.
← Back to Home