October 25, 2026
My First $$ From Real Bug โ And It Was Very Simple
From networking diagrams to actual exploitation โ my bug hunting journey starts here.

By Nishant kumar
3 min read
For the last several months, I've been documenting my cybersecurity learning journey โ Linux fundamentals, networking protocols, ARP, HTTP/HTTPS, Wi-Fi security, the works. It was a lot of theory, a lot of "here's how this attack conceptually works."
Then I decided it was time to talk about vulnerabilities and start finding them.
This is the story of the first real bug I found โ and honestly, it was hiding somewhere so mundane I almost didn't bother testing it.
The Target Nobody Thinks to Test
Most beginners go straight for login forms and search bars โ everyone tests those. I decided to go somewhere less obvious: **a lead-generation form on an e-commerce platform's knowledge base page, the kind that says **"Enter your email and we'll send you a free ebook."
You've seen a hundred of these. You've probably filled one out yourself without a second thought. That's exactly why I was curious about it โ nobody tests the boring forms.
The form asked for three things: an email address, a phone number, and a name.
That last field โ the humble Name field โ is where everything unraveled.
The Payload That Shouldn't Have Worked
Here's the thing about a "Name" field: developers almost never expect it to contain anything dangerous. Nobody thinks a first name could carry a weapon.
So I tried this in the Name field:
"><a href="https://evil.com">Click Me!</a>"><a href="https://evil.com">Click Me!</a>Filled in a real email (mine), a random phone number, hit submit, and waited.
A minute later, I opened my inbox.
There it was. A perfectly rendered, clickable hyperlink โ sitting inside an official email from the platform's own domain โ pointing straight to a URL I controlled.
No sanitization. No encoding. Nothing stopping raw HTML from flowing straight from a form field into a real email sent to a real inbox.
Why This Is More Dangerous Than It Looks
At first glance, this might seem like "just a broken input field." But walk through what an attacker could actually do with it:
1. Weaponized phishing, wearing a trusted mask The email comes from the company's own legitimate domain. Every spam filter, every "does this look suspicious?" instinct a user has โ bypassed, because the email genuinely did come from the real company's mail server.
2. Spear-phishing at scale An attacker doesn't need to fake a company email anymore. They just fill out a public form, and the company does the phishing for them โ sending a convincing, legitimately-hosted malicious link straight to a victim's inbox.
3. A door left open for something worse If that same email content is ever rendered inside the application itself (say, in an admin dashboard showing "recent form submissions"), this stops being just HTML Injection โ it becomes Stored XSS, and the entire threat model escalates.
The Real Lesson Here
This bug didn't require Burp Suite, a fuzzing script, or any advanced tooling. It required exactly one thing: treating an unassuming input field with the same suspicion as a login form.
If there's one thing I'm taking from my first real find, it's this โ the most dangerous vulnerabilities often live in the fields everyone assumes are harmless. A "Name" field feels so innocent that most developers never imagine it needs the same encoding rigor as a password field. That assumption is exactly the gap attackers live in.
The Report:
After successfully validating the vulnerability, I created a simple report with video poc and submits it.
After 3 days, I got response that this report was accepted and rewarded $$ bounty and a place in company's hall of fame.
What's Next
This is the first entry in what I'm calling my Bug Bounty Diaries โ real hunts, real findings, real lessons, documented as they happen. No more theory-only content. If you're on a similar path โ moving from "I understand security concepts" to "I actually find real vulnerabilities" โ follow along. I'll be sharing the wins, the rejections, and everything in between.
If this piece helped you look at "harmless" input fields a little differently, give it a clap and follow for the next writeup. Bug Bounty Diaries #2 is coming soon.
If you found this article helpful and would like to support my cybersecurity learning journey, you can do so here:
https://buymeacoffee.com/nis.sec
You can connect with me on social media platforms.
Linkedin: https://www.linkedin.com/in/nishant-kumar-3a07952b6/
Twitter:https://x.com/BugBugproofmind