HexBrain

Essity · Report #3802451

HTML Injection in Contact Form Email Enables Phishing via Legitimate ████████ Infrastructure

Validstatus
mediumseverity
42upvotes
5 Oct 2026disclosed

How it was found

Summary

The contact form email endpoint at POST ████████/contacts/email on ████████ accepts a firstName field that is rendered as raw, unescaped HTML in the body of the transactional confirmation email sent via SendGrid. The email greeting reads "Buongiorno {firstName}" where {firstName} is inserted without HTML entity encoding. This allows an unauthenticated attacker to inject arbitrary HTML elements -- including styled anchor tags posing as legitimate action links -- into ████████-branded emails delivered to any recipient address the attacker specifies.

The <img> tag is stripped by the email pipeline, but <a> tags with inline styles persist and render in email clients. The endpoint requires no authentication, no CAPTCHA, and imposes no rate limiting.

The contact form endpoint accepts a JSON body with email, firstName, lastName, queryType, and message fields. Upon submission, the server sends a transactional confirmation email to the provided email address using a ████████-branded HTML template via SendGrid.

The firstName value is interpolated directly into the email body's greeting line:

Buongiorno {firstName} {lastName},

No HTML entity encoding is applied to firstName before insertion into the text/html email body. This allows injection of arbitrary HTML elements that render in the recipient's email client.

Sanitization Behavior

PayloadRendered in Email
<a href='//evil.test' style='font-weight:bold;color:red'>CLICK</a>Rendered as styled link (href rewritten by SendGrid click tracker, but anchor text and styles preserved)
<b>BOLD</b>Rendered as bold text
<img src=x>Stripped by email pipeline
<script>alert(1)</script>Accepted by API (200), rendering depends on email client
<div style='color:red'>RED</div>Accepted by API (200)

The key finding is that <a> tags with inline styles survive the email pipeline. SendGrid rewrites the href through its click-tracking proxy (u28522215.ct.sendgrid.net/ls/click?...), but the anchor text and CSS styles remain entirely attacker-controlled. The tracking proxy transparently redirects to the attacker's URL on click.

Steps to Reproduce

Step 1: Send contact form with HTML-injected firstName

POST ████████/contacts/email?lang=it HTTP/2
Host: ████████
Content-Type: application/json

{
  "email": "[email protected]",
  "firstName": "<a href='https://attacker.test/phish' style='font-weight:bold;color:red'>APRIRE RIFERIMENTO</a>",
  "lastName": "User",
  "queryType": "OTHER",
  "message": "Richiesta di assistenza tecnica."
}

Response: HTTP 200 (empty body) -- email dispatched.

Step 2: Victim receives ████████-branded email

The recipient receives a legitimate ████████ Direct confirmation email with:

  • From: Essity/████████ via SendGrid infrastructure
  • Subject: "Modulo di conferma della richiesta"
  • Body: Full ████████-branded HTML template with logo, blue header bar, and footer
  • Greeting: "Buongiorno APRIRE RIFERIMENTO User," -- where "APRIRE RIFERIMENTO" is a bold red clickable link pointing to the attacker's URL (via SendGrid click tracking redirect)

The injected link blends seamlessly into the email template, appearing as a legitimate ████████ action item.

Step 3: Victim clicks the injected link

The styled anchor tag looks like a legitimate call-to-action within the ████████ email. Clicking it:

  1. Hits SendGrid's click tracker (u28522215.ct.sendgrid.net/ls/click?...)
  2. Redirects to the attacker's URL (https://attacker.test/phish)
  3. The attacker can present a credential harvesting page or malware download

Proof of Concept

import requests

TARGET = "https://████████████████/contacts/email?lang=it"
VICTIM = "[email protected]"

r = requests.post(TARGET, json={
    "email": VICTIM,
    "firstName": "<a href='https://attacker.test/phish' style='font-weight:bold;color:red'>APRIRE RIFERIMENTO</a>",
    "lastName": "User",
    "queryType": "OTHER",
    "message": "Richiesta di assistenza."
})
print(f"Status: {r.status_code}")  # 200 = email sent

Confirmed Email Rendering

The injected HTML renders in the actual ████████ email template as follows:

  • The ████████ logo and blue header bar display normally
  • The greeting reads: "Buongiorno APRIRE RIFERIMENTO User,"
  • "APRIRE RIFERIMENTO" appears as a bold, red, clickable link
  • The rest of the email (summary section, FAQ links, footer) renders as a standard ████████ communication
  • The email originates from Essity's SendGrid sending infrastructure, passing SPF/DKIM/DMARC validation

The phishing link is visually indistinguishable from a legitimate ████████ action link within the email template.

Impact

  1. Phishing via trusted infrastructure -- the attacker sends emails from Essity's legitimate SendGrid domain, passing all email authentication checks (SPF, DKIM, DMARC). The injected phishing link appears within a genuine ████████-branded template, making it significantly more convincing than a standalone phishing email.

  2. Arbitrary recipient targeting -- the email field accepts any address, allowing the attacker to target any individual. Combined with the lack of authentication and rate limiting, this enables phishing campaigns at scale through Essity's own email infrastructure.

  3. No authentication or CAPTCHA -- the endpoint is completely open. No bearer token, no session, no CAPTCHA, no rate limiting. Automated abuse is trivial.

  4. SendGrid reputation damage -- mass abuse of this endpoint for phishing could damage Essity's SendGrid sending reputation and potentially cause legitimate Essity emails to be flagged as spam.

Recommendations

  1. HTML-encode the firstName field -- apply HTML entity encoding (&lt;, &gt;, &amp;, &quot;) to all user-supplied values before interpolating them into the email HTML template.
  2. Input validation -- reject or strip HTML tags from name fields at the API layer. Names should be alphanumeric with basic punctuation only.
  3. Add CAPTCHA -- require reCAPTCHA or similar challenge on the contact form endpoint to prevent automated abuse.
  4. Rate limiting -- implement per-IP and per-recipient rate limits on the email endpoint to prevent mass phishing campaigns.

This report was disclosed publicly on HackerOne and belongs to its author and the program. See the original