Hey folks, Sarv3shxploit here. I test sites and nudge teams to ship safer code. This writeup shows how a tiny profile Name field that accepted HTML became a trusted-channel phishing vector. I'll explain what stored HTML injection is, how I stumbled on it, the exact PoCs I used, the impact, and what I learned. No company name only lessons.
What is stored HTML injection?
Stored HTML injection happens when user input containing HTML is saved by the app and later injected into an HTML page or template without proper escaping.
Example: if the app stores "<h1>hello</h1>" as your name and later places it into an email template as raw HTML, recipients will see "hello" rendered as a big heading instead of the literal characters. That's the core problem: untrusted data rendered as markup.
The story of how I found it
I was poking around redacted.com in product UI like profile pages, notifications, group flows doing the usual recon. After testing pretty much every function for hours, I eventually went to the Delete Account flow to see how verification works. The site asked for my email and then sent an OTP to confirm deletion. Cool, standard workflow.
When I opened the OTP email I noticed the email included the account owner's name in the message (short snippet: Dear [ACCOUNT NAME], ...). That detail lit a lightbulb in my brain: what if I put HTML into the name and see how the email renders it?
So I did something impulsive and fun: I changed my name to
"><h1>test</h1>Saved, and triggered the OTP again!
YOOOOO!!!
the email showed test as a big H1 headline. It wasn't the literal string, it was rendered HTML. Chills.
I tried another tiny payload:
<a href=//evil.com>Click</a>
That worked too. A clickable link inside an official OTP email. Javascript didn't run (expected - email clients strip scripts), but links and images did, which is all an attacker needs for convincing phishing or tracking. Why scripts don't work: most modern email services strip <script> and block inline JS execution in their renderers.
At first this looked like a self-impact issue (I could only trigger the OTP to my own email via delete). But then I remembered the Members tab and group invite flow on redacted.com. I created a group named:
"><h1>test</h1>
Then I clicked Add member / Invite user. The group invite email includes the group name. That means the H1 (or <a> link) is reflected into emails sent to other users. So suddenly it's not just my inbox. The platform itself becomes a delivery vehicle for phishing links and tracking beacons sent to other people.
I packaged all of this into a detailed report, with screenshots and PoC payloads, and submitted it to the vendor.
Impact
- Trusted-sender phishing: a malicious link inside an official OTP/invite/email has a much higher chance of success than random spam. Users expect these emails to be legitimate.
- Open tracking / reconnaissance:
<img>beacons reveal when recipients open the mail (IP, UA). Useful for targeting follow-ups. - Visual manipulation / OTP confusion: with markup and styles you can hide or alter visual elements (e.g., hide OTP and show a fake one).
Result
I submitted a clear report with repro steps, screenshots, and PoC payloads. Two days later the vendor replied saying the issue was "manageable" and claimed it only affected links in my own email, basically downplaying the impact and asking me to expand the risk. I pushed back politely, re-iterated the cross-user invite scenario (attached the "Add member" screenshot), and shared public writeups showing similar issues being treated as high-severity.
Next day I re-tested and saw the payloads no longer rendered. They'd patched it. That patch alone proved the bug was real. I tried to negotiate classification and recognition (citing the fix and precedent), but the vendor pointed me to their bounty rules page and stopped engaging further. No bounty, no official acknowledgement, just a quiet fix.
So end result: users are safer (win), the bug is closed (win), but the vendor didn't follow up on classification/reward (loss). Still worth it: got a real, fixed finding for my notes and a solid story for the writeup.
Final thoughts
Finding bugs is only half the game. Reporting them clearly and following up is how we get fixes. In this case the vendor fixed it quickly enough; they didn't engage much on reward/acknowledgment, which is annoying but not the end of the world. The real win is users are safer now.
No worries, folks. Keep hunting, keep it responsible, and document everything. Small inputs flowing into high-trust channels are where the fun (and danger) hides.
If you liked this, do a little like & follow. It helps me keep writing and hunting.
#BugBounty #WebSecurity #XSS #HTMLInjection #EthicalHacking #CyberSecurity #BugBountyTips