It was around the end of August, 2024. I was standing at the bus stop, watching my bus pull away — two minutes early. Two minutes. I'd been on time. The bus wasn't.

That was the moment I decided I was going to make sure their systems are secure in case someone is out there to hack them.

The Setup

The target was a local public transport company running a subsidized travel card system for students. You register, submit a declaration proving you're a student, and get a discounted transit card. Standard stuff. Boring stuff. Except their web app was anything but boring — it was a goldmine.

I started poking around with Burp Suite, intercepting requests like any normal frustrated person does after missing their bus. The subscription endpoint caught my eye immediately:

POST /api/web/v2-6/subscriptions?card_sdist=2023977

A sequential integer. In a public-facing API. In 2024.

The Vulnerability

I changed 2023977 to 2023975. Sent the request. The response came back — 6,549 bytes of base64 encoded data.

I decoded it.

What I got was a full legal subsidy declaration document. Someone else's. Complete with their full name, CNP (Romanian national identification number), and a signed declaration referencing multiple Romanian laws and government ordinances — the kind of document you'd file with a government office.

This wasn't just a data leak. This was an IDOR (Insecure Direct Object Reference) — one of the most well-known, most preventable vulnerability classes in web security. No authentication check. No ownership validation. Just: here's a number, here's someone else's legal document. Enjoy.

The only thing stopping a full database dump was my unwillingness to do it without anonymization. The vulnerability was that clean.

The Timeline

I reported this. Five times. Over six months.

I wasn't vague about it either — I explained the vulnerability class, the potential impact, and even pointed out that under GDPR, failing to address a reported data breach of this nature could result in fines of up to €20 million or 4% of annual global turnover. I laid it out clearly. I gave them every reason to respond.

Silence. Every single time.

Sometime in the following months, the vulnerability was quietly patched. No acknowledgment. No thank you. No "hey we fixed it." Nothing. They just closed the hole and hoped nobody noticed — or more likely, hoped I'd forget.

I didn't forget.

The Technical Breakdown

The root cause is straightforward: the backend performed no authorization check to verify that the requesting user owned the subscription record being queried. The card_sdist parameter was trusted entirely at face value.

The fix is equally straightforward: before returning any record, verify that the authenticated user's ID matches the owner of that record. One database join. One condition. That's it.

The fact that this wasn't in place on an endpoint returning legally sensitive personal documents, in a system handling student subsidy applications tied to national ID numbers, is genuinely hard to excuse.

Closing Thoughts

I'm publishing this because the vulnerability is patched, the company had six months and five separate reports to acknowledge it, and the public deserves to know that their data was exposed. The people who submitted those declarations to get a discounted bus pass didn't agree to have their personal documents freely readable by anyone with a browser and five minutes.

To the company: fix your bus schedules too.

Responsible disclosure attempted August 2024 through early 2025. Five reports sent. Zero responses received. Vulnerability silently patched.