The target was a private Bugcrowd program. I'll call it Reacted.com a car rental platform. Simple app, not a lot going on, and weeks of me finding absolutely nothing.

I tried XSS on every input, messed with prices on the booking form, and went through my usual checklist. Nothing worked. At some point I had to be honest with myself I was testing the same things again and again. So I asked a different question: what actually happens after someone books a car? I had never really looked there.

I booked a car for £70 and then cancelled it just to see what the request looked like in Burp. The cancellation endpoint had no auth check at all it didn't verify who you were or whether the booking was yours. The only thing it needed was a booking code and the security totally depends on that unique booking code

Here's what got me the app showed a booking ID on screen, just a plain number. But the cancellation request was using a booking code a totally different value that never showed up anywhere in the UI. So I had an endpoint that could cancel any booking without checking who's asking, but I had no way to get someone else's code. The obvious question was where does this code even come from?

So I copied my own booking code and searched for it across every request and response I'd captured in Burp. I just wanted to know if I'd seen this value somewhere else without realising it.

And I had.

There was a trip lookup endpoint I'd hit in booking process but i ignored that time. That request only need `booking_id` and a `provider_name`, and it gives back trip details and right there in the response was the booking code. If I could call this for other people's bookings, I'd get their codes too.

Booking IDs were just counting up one by one 1001, 1002, 1003. Easy. The problem was the provider name had to match the booking id or you will get nothing back. I needed to know what provider names were even valid on this platform.

I dug through the JavaScript files and found one provider name sitting in the code. That told me more were in there somewhere. Then I checked if the source map file was sitting on the server these are files that turn the messy minified code back into clean readable code. They're only supposed to exist on a developer's laptop, not on a live website.

I typed the URL. It opened.

I dropped the whole source map file into Claude and asked it to find every provider name in there. Got back a list of 7. That was the last thing I was missing.

I wrote a simple script. For each booking ID, it tried all 7 providers one by one. When a match hit, the response came back with full trip details and the booking code sitting right in it. I ran it, got a bunch of hits, grabbed one of those codes, and sent it to the cancellation endpoint.

Someone's booking got cancelled. Not mine. No login, no password, nothing just a code I got from an open endpoint.

Three bugs on their own were nothing special. An open source map file, a trip lookup that didn't check ownership, and a cancellation endpoint that didn't check who was asking. But together, they let anyone cancel any booking on the entire platform.

Every time I hit a dead end, I just asked one question: what does this thing need, and where does that come from? That kept moving me forward. The whole picture only made sense at the very end, but each answer opened the next door.

But unfortunately It came back as a duplicate, and yes, that hurt a bit. But finding a duplicate means you did it right you found a real bug on your own. You just weren't first. Honestly, I learned more from this one than from a lot of bugs that paid out, and that kind of experience adds up over time.

Follow me on LinkedIn: Atharv Chawan