⚠️ Disclaimer

This write-up is for educational purposes only.
All testing was conducted on authorized targets within the scope of a responsible disclosure or bug bounty program.

Do not attempt to test or exploit systems without proper permission.

Bug bounty hunting teaches you a lot of things.

Patience.
Curiosity.
And sometimes… that bugs have a better comeback story than your favorite movie character.

This is the story of how one very simple bug refused to die — and ended up paying twice.

🎯 The Target

I was testing target.com, a Swiss insurance company with a clean and modern authentication system.

At first glance, everything looked solid:

• Smooth UI ✅
• Secure flows ✅
• No obvious XSS ✅

So naturally, I thought:

“Yeah… this one is going to be painful.” 😅

🔍 The “Hmm… That’s Weird” Moment.

While going through the registration flow, I landed on this endpoint:

/registration/email-confirmation?email=<user_input>

Out of curiosity (and a little boredom), I replaced the email with:

The mason lives in a small house. We detected a suspicious activity on all user accounts.

And boom 💥

➡️ The page happily displayed it.

🤔 Me vs The Bug (Round 1).

My brain immediately went:

“WAIT… is this XSS?? 👀”

So I did what every hacker does:

"><script>alert(1)</script>
"><img src=x onerror=confirm(1)>

Result?

Nothing.
Silence.
Disappointment.

The app was like:

“Nice try, but I sanitize my inputs, so go away.” 😌

😐 The Almost-Abandoned Bug

At this point, most people would close the tab and move on.

And honestly… I almost did.

Because:

• No JavaScript execution ❌
• No HTML injection ❌
• No fireworks ❌

Just… text.

Boring, right?

💡 Plot Twist: Context Is King

Then it hit me.

This wasn’t just any page.

This was a verification flow.

Which means:

• Users trust it.
• Messages feel official.
• Anything shown = “must be legit”.

And suddenly, the “boring” bug wasn’t so boring anymore.

🎭 The Trick

I crafted a link like this:

?email=SECURITY ALERT: Your account has been compromised, call +4180000000 immediately.

Now imagine sending that to someone.

They open it and see:

“Your account has been compromised, call +4180000000 immediately.”

On a legitimate domain.

No hacking.
No scripts.
Just pure psychological damage. 😄

📨 First Report = First Win

I reported it as:

UI Injection / Reflected Input in a security-sensitive flow.

And guess what?

✅ Accepted
✅ Rewarded
✅ Fixed

At this point I was like:

“Nice. Clean. Let’s move on.” 😎

🎬 But This Is Where The Story Gets Good…

A few days later, I came back (because hackers don’t really move on… we hover 😅).

And I thought:

“What if… just what if… they fixed only this part?”

So I checked another flow:

🔓 Password Reset

Classic entry point.

1. Enter email
2. Receive code
3. Land on:

/password/reset-confirmation?email=<user_input>

And you already know what I did next…😏

🤡 Me vs The Bug (Round 2)

[email protected], we noticed an unusual activities on your account.

And the app said:

“Oh Yes, Welcome back, you look familiar.😄”

Because YES… it reflected again.

Same bug.
Different endpoint.
Same energy.

😂 At This Point…

I just sat there like:

“You again?? We just fixed you last week!”

The bug really said:

“I’m not a bug… I’m a feature.” 😭

🚨 Why This Was Even Better

This time, it was inside a password reset flow.

Which is basically:

“Trust me, I’m important” mode activated. 🔐

So now the injected message feels even more real.

Example:

We noticed an unusual activities on your account.

That’s not just text anymore.

That’s social engineering fuel. 🔥

🎭 Attack Scenario (But Make It Real).

1. Attacker crafts a link.
2. Sends it to victim.
3. Victim opens it.
4. Sees scary message on legit domain.
5. Brain goes:
   “Oh no.”
6. Attacker goes:
   “Oh yes.” 😏

🔁 Second Report = Second Payment. 💰

This time, I reported it as:

“Incomplete remediation — same vulnerability present in password reset flow”.

And boom again:

✅ Accepted.
✅ Paid… again.

🧠 The Real Lesson

This isn’t about XSS.
This isn’t about payloads.

This is about:

Inconsistent fixes.

📌 What Developers Often Do.

• Fix one endpoint ✔️
• Forget similar ones ❌
• Assume problem is gone ❌

Meanwhile, the bug is like:

“Oh dude, I have siblings.” 👨‍👩‍👧‍👦

🧠 What Hackers Should Do.

After a fix:

• Re-test similar flows.
• Check authentication endpoints.
• Look for patterns, not just bugs.

Because sometimes…

One bug = multiple paydays. 😄

🚀 Final Thoughts

Not every bug needs to scream:

alert(1)

Sometimes, it just whispers:

“Hey… look at me, I’m still here.”

And if you listen carefully…

You might get paid twice for it. 😉

🙌 Enjoyed This?

If you found this helpful (or at least laughed once 😄),
feel free to clap 👏 and follow for more real-world bug bounty stories and insights.

More bugs. More lessons. Maybe more double payments. 😉

I go by kjulius, a self-taught Ethical Hacker.
https://x.com/ethical_h4ck3r_