I Found a Critical Bug in Meesho. They Fixed It Silently, Gave Me -5 Signal, and Locked Me Out of Disputing It.

This is the story of my first real bug bounty finding. The vulnerability was real. The fix happened. And then I discovered how the system can be used against the researchers who help secure it.

Finding the Vulnerability

Meesho is one of India's largest e-commerce platforms. I was doing mobile security research on their Android app using Frida for SSL pinning bypass and Burp Suite for traffic interception — standard mobile pentesting methodology.

While analyzing authenticated requests I noticed something immediately wrong. Every single request across the entire application used exactly two headers for authentication:

Authorization: <static_value>
xo: <encrypted_payload>

I stripped every other header and kept only these two. Still got HTTP 200. These two headers were the entire authentication system for the whole app.

That's when I started pulling the thread.

What I Found

The Authorization header never changed. Three login/logout cycles. Identical value every time. A static hardcoded credential used as a session token.

Logout did absolutely nothing server-side. Captured both headers, logged out, replayed them in Burp Repeater. HTTP 200. Full valid response. The server had no idea logout happened. Tested across multiple cycles — original tokens from the very first session kept working throughout all of them.

No expiration ever. No time limit, no rotation on new login. Capture once, valid permanently.

User financial data exposed post-logout. The endpoint /api/v1/user/meesho/balance returned sensitive balance information using old post-logout tokens. Separate information disclosure finding on top of everything else.

The xo: header carries your identity. Modifying the userid header triggered an error confirming the user ID lives inside the encrypted xo: token. The app told me exactly how it works — server decrypts it and validates identity from within. Almost certainly wrapping JWT.

Chain all of this together: capture someone's headers once and own their account permanently. The victim can do nothing. Logging out doesn't help. New sessions don't help. Zero recourse.

The Program Response

Reported April 11, 2025. Acknowledged within 2 hours on a Saturday — impressive. Then silence for 6+ days past their own stated 1 day 23 hour SLA. Follow up comments ignored.

Eventually:

"We are aware of this behaviour, and all sensitive flows, such as ordering, do not work once you log out. Therefore, please close this as N/A within the next hour."

One hour. No technical proof. Just a claim and a countdown.

As my first real finding I made the mistake of trusting this without verifying it independently. I closed the report.

When I retested after closure — JWT expiration errors appeared where none existed before. The issue was silently fixed after my report. No credit. No acknowledgment. No bounty.

The -5 Signal Trap

Here is the part every new researcher needs to understand.

Meesho's N/A closure gave me -5 HackerOne signal.

HackerOne's mediation system — the only official mechanism to dispute a program closure — requires signal of zero or greater to access.

So the sequence looks like this:

Program gives questionable N/A
→ Researcher gets -5 signal
→ -5 blocks mediation access
→ Cannot officially dispute the closure
→ Program faces zero accountability
→ Researcher must find 3+ more valid bugs
  just to recover access to dispute mechanisms

The program that potentially acted in bad faith made it structurally impossible for me to challenge them through official channels. HackerOne support confirmed mediation is unavailable at my current signal level and closed the ticket.

This is not a theoretical concern. This happened. And it will keep happening to new researchers because the incentive structure allows it. A program with bad intentions can exploit this gap deliberately — delay triage, fix silently, pressure closure, collect the negative signal damage, and walk away untouchable.

New researchers are the most vulnerable because they have no signal buffer. One bad N/A from a predatory program and you're locked out of the dispute system on your very first finding.

What I Should Have Done

Test every sensitive endpoint before submitting. Not testing order and payment flows gave them their argument. Never again.

Never close under time pressure. When a program asks you to close a report they want your endorsement of the N/A. They can close it themselves. The request is a tactic.

Demand proof for N/A claims. The right response was — show me technical evidence that ordering flows are protected post-logout and I will verify it independently. Force them to prove it.

Know the signal consequences before filing a dispute. The -5 risk is real and it has real consequences. Go in informed.

The Takeaway

The vulnerability was real and it got fixed. That's what responsible disclosure is supposed to do and it happened.

But the way it was handled exposed something worth naming publicly. Some programs run bug bounty programs as free security audits. They know the platform policies. They know new researchers don't. And they use that gap deliberately.

Your documentation is your only leverage. Your timestamp is your only proof of priority. Your skepticism of unverified program claims is your only protection.

The skills you build are permanent. The programs that treat researchers unfairly will eventually have a reputation built on exactly that.

Keep hacking. Test everything. Trust nothing. And never close a report in one hour.

All testing on self-registered test accounts on Android emulator. No real user data accessed. Reported to Meesho via HackerOne: April 11, 2025 HackerOne: @sovereignishere

GitHub: crimsonsovereign X: @sovereign8209 Linkedin: ashish-patil-2591b93b7