3 Name Fields, 3 Bugs: How Free Text Became a Phishing Delivery System

In this post I want to walk through three separate reports I filed against the same private program — because once I found the first one, I kept finding the same mistake hiding behind a different form field.

The one blind spot behind all three

Here's the pattern:

A lot of sites let you type free text into a name field — your own name, a gift recipient's name, a shipping contact. It usually gets copied straight into an automatic email.

If the backend never checks what was actually typed there, you can put almost anything in that box like a fake warning, a link, even working HTML. The email system doesn't know the difference between a real name and an attack payload. It just sends whatever it was handed.

WHAT THE FIELD EXPECTS:      "Omar Mohamed"
what can go in:     "VERIFY YOUR PAYMENT: fake-verify-link.com"

WHAT THE FIELD EXPECTS:      "Omar Mohamed"
what can go in:     "VERIFY YOUR PAYMENT: fake-verify-link.com"

The site never asked whether the text was actually a name. That's it, that's the whole bug — repeated three times, in three different corners of the same platform.

Finding #1 — Checkout Emails: Real HTML, Not Just Text

This is the one that actually worried me while I was testing it.

During checkout, two separate name fields — one for a gift recipient, one for the shipping contact — each feed into their own automatic email: the order confirmation and, separately, the order-cancellation notice. Neither field was sanitized, and this time the flaw let through actual HTML, not just plain text.

First pass, just to confirm the field was reflected at all:

"first_name": "Confirm At'x.com",

"first_name": "Confirm At'x.com",

Then the real payload, on the shipping/receiver name field:

"receiver_first_name": "Is Not You? Cancel At <a href=\"[link]\">Here</a>",

"receiver_first_name": "Is Not You? Cancel At <a href=\"[link]\">Here</a>",

I placed the order — no valid payment needed, it cancels itself automatically if payment credentials are wrong— and got both emails back with a genuine, working, clickable link sitting in the middle of otherwise-real company mail.

Why this one is the serious one:

• **Real HTML injection :**an actual working link, not just suspicious-looking text. Far more convincing than typical phishing copy.
• Two independent templates : the identical flaw fires in both the confirmation and the cancellation message. A pattern, not a one-off.
• Zero cost, fully automatic : even an order with no valid payment still fires both emails before it cancels itself. Scriptable, repeatable, free.
• Sent from the company's real servers : because the mail genuinely comes from their trusted sending system, it skips spam filters and skips the "does this look right" instinct most people rely on.

The company pushed back — here's why that was wrong

The report got closed first. Their reasoning:

"You'd need access to the victim's email account to change the account email to theirs — so there's no real-world risk." Closed as Informative — not a security issue.

Except that's not how the flow actually works. The confirmation step only re-verifies the attacker's own existing email — never the victim's. The victim's address is just a string typed into a text box. It's never opened, accessed, or confirmed before it starts receiving the injected emails.

The only account an attacker ever needs is their own.

I wrote back and laid that out plainly. A few days later:

Finding #2 — Gift Registry Invite Emails

The site lets customers build a gift registry — a wedding registry, a baby shower list, that kind of thing — and invite Collaborator by email straight from the settings page. One of those invite fields is meant to hold a guest's name.

I intercepted the invite request and, instead of a name, dropped in an urgent-sounding message with a fake link stitched into it:

what the field expects:   "Omar Mohamed"
what I typed instead:     "YOU MUST VERIFY YOUR ACCOUNT: fake-verify-link.com"

what the field expects:   "Omar Mohamed"
what I typed instead:     "YOU MUST VERIFY YOUR ACCOUNT: fake-verify-link.com"

I sent the invite. The guest's actual inbox got an official-looking email — sent from the company's own real mail system, not a spoofed one — telling them to verify their account.

This one was validated and paid — $$$ bounty.

Finding #3 — Store Credit Card Application Emails

Same weak spot, different form. The store's credit card sign-up flow has its own confirmation email, and its first_name field went into that email exactly as typed, no checks at all.

I didn't even need a working link — just plain text:

what the field expects:   "Nanashi"
what I typed instead:     "Go to www.fake-site.com"

what the field expects:   "Nanashi"
what I typed instead:     "Go to www.fake-site.com"

Same result here — validated, $$$ bounty.

What this actually teaches

A few things I keep relearning on these engagements:

Treat every typed field as untrusted, no matter how small. A "name" box gets the same scrutiny as a login form the moment it's placed into an email or a page — size has nothing to do with risk.

Email HTML needs the same discipline as web HTML. A link is a link whether it renders in a browser tab or an inbox. Output needs to be escaped either way, and "it's just an email template" is not an exemption.

Free-to-trigger plus a trusted sender Mail is a dangerous combo. A flaw that costs nothing to fire(No valid payment required) and rides on a real company's own sending Mail and reputation is dangerous.

$$$$ earned across 2 confirmed reports. The first one is unfortunately closed later as a known issue because they knew that bug internally.

More write-ups soon.

— 0xnanashi

https://www.linkedin.com/in/omar-mohamed-006989248/