🎯 When Password Reset Turns into a Privacy Leak: CSRF, IPs & a Little Bit of WTF

4 min readJun 10, 2025

قَالَ اللَّهُ تَعَالَى: “يَرْفَعِ اللَّهُ الَّذِينَ آمَنُوا مِنكُمْ وَالَّذِينَ أُوتُوا الْعِلْمَ دَرَجَاتٍ ۚ وَاللَّهُ بِمَا تَعْمَلُونَ خَبِيرٌ” (سورة المجادلة، الآية 11)

By Team — @GET /BountyOrDie

“It’s just a password reset form. What could possibly go wrong?”
Spoiler alert: a lot.

🧠 The Intro

While testing a web application (name hidden to protect the identity), We noticed something interesting — when you submit a password reset request, the account owner receives an email.
Standard behavior, right?

But this email had a bonus feature: it included the IP address of the person who triggered the reset.

Now that’s… extra.

So naturally, my hacker brain kicked in:

“What if I could trick a victim into triggering this reset… and get their IP delivered to my inbox — straight from the app’s email server?”

The Time For CSRF.

The Discovery

Here’s what We found:

The password reset endpoint is a POST request to something like /api/rest/v1/sessions/forgot.
It originally expects application/json.
So far, so boring.
But when I changed the Content-Type to application/x-www-form-urlencoded...

It still worked. No tokens. No cookies. No CSRF protection.

The Weaponized PoC

Let me introduce you to my not-so-innocent friend:

<html>
  <body>
    <form action="https://target.com/api/rest/v1/sessions/forgot" method="POST">
      <input type="hidden" name="username_or_email" value="victim@example.com" />
      <input type="submit" value="Surprise!" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

📩 Boom — the victim visits this page, and I get an email from the app with their IP address.
All wrapped up in a bow, straight from a “trusted” source.

So What’s the Risk?

You might be thinking:

“Can’t I just get someone’s IP with a tracking pixel or a sketchy website?”

True. But here’s the twist:

This isn’t some shady site grabbing your IP.
This is a trusted platform sending your real IP address to a random attacker via email.
The attacker can then do:
🗺️ Geolocation (country, city)
🌐 ISP analysis
🕸️ Network fingerprinting
🧠 Behavioral profiling
🔐 Targeted phishing/surveillance

All from… a reset password email.

🗺️ From CSRF to Street View

Let’s be honest: getting someone’s IP might sound boring at first.

But here’s where it gets spicy 🔥:

After successfully triggering the CSRF, the platform kindly delivered the victim’s IP address to my inbox (thank you, automated security notification robot 💌).

So naturally, We did what any mildly curious hacker would do…

We plugged the IP into a public geolocation service. And guess what?

🎯 Boom: City, region, ISP, and even approximate street-level location.

But We didn’t stop there.

I took the coordinates and dropped them into Google Maps — and suddenly I wasn’t just looking at numbers.

I was looking at:

At that point, I realized:

This isn’t just an IP. It’s a one-way ticket to Google Street View.

All this, from a CSRF that most people would ignore.

So while the system may think this is just “informational,” it turns out that:

“Here’s your IP” + “Here’s your front porch on Google Maps” = Not so chill.

What’s Missing?

✅ JSON validation
❌ CSRF token
❌ SameSite cookie
❌ CAPTCHA
❌ Any user verification at all

Even the frontend tries to send JSON, but the server is like:

“Yeah, I’ll take whatever. You do you, bro.”

The Final Result

We submitted this as a bug report.

Initial response: “Not Applicable.”

“An attacker could just get the IP some other way.”

Fair point. But this isn’t about just getting IPs.
It’s about your platform being misused to do it — making users believe you leaked their info.

Which brings me to…