🌙 The night I found something nobody should see
I was half-relaxed and half-panicked exams were a week away, I was traveling between cities, and life felt like a messy juggling act: revision notes in one pocket, bus ticket in the other. I wasn't hunting bugs that day. I was trying to enjoy the ride.
Still, old habits die hard. As a computer‑science student with a habit of seeing systems like puzzles, my "cyber sense" was quietly active in the background. While checking my travel ticket on my phone, I noticed the QR and the link that came with it. I took a screenshot more out of boredom than intent, kept the phone in my pocket, and kept traveling.
A few days later, with exams only a couple of days away, I used the same ticket system again to travel to the exam city. That's when my quiet curiosity snapped into focus. I looked at the URL and the QR a little closer. Something in the link structure and the way the QR was presented didn't sit right. It was a tiny detail but in security, tiny things can mean everything.

💡 The odd detail that pulled me back in
When I reached home at night after traveling, I was completely exhausted, but my curiosity was wired on high caffeine. My roommates were deep in their dreams, the apartment silent, and the only light came from my laptop's glowing keypad and my phone screen. My mobile showed the QR ticket as expired, and instead of opening textbooks or reviewing notes for my exams, the Kali Linux dragon in my mind was summoned.
That night, I found myself playing with my own demons exploring the ticket system in my head, thinking like a hacker while the world around me slept 😂. Every detail of the QR and the URL caught my attention. My exhaustion transformed into sharp focus, and a strange thrill took over.

🧠 The mindset — curious, careful, responsible
When you do this for a living (or for the thrill), three rules guide every move:
- Observe, don't break. Treat the system like a black box. Note what it returns; don't try to pull live user data.
- Validate with your own accounts. Use only data you control; never harvest or expose someone else's information.
- Document, then disclose. Capture sanitized screenshots and a short demo showing the visible effect enough for triage, not enough for exploitation.
I followed that path exactly. I verified behavior with my own tickets, captured what was needed to explain the issue, and prepared a responsible report. This was a genuine information disclosure simple, clear, and important.
🔎 The moment the puzzle flipped
- When I first noticed it, the ticket URL looked short and predictably structured, so it immediately caught my attention.
- The next thing I saw was that the QR showed as "expired," so I inspected the page, removed the visual overlay that was hiding the QR, and saved the image.
- I tried decoding the QR with online decoders, but they failed (I couldn't understand why).
- After some research I learned there are Python libraries that can decode tricky QR formats, and since I was still a beginner in Python, I asked a well‑known AI creature for help (ChatGPT).
- After lot of requests and few please I got a local script to run against the saved QR, and the result was shocking the decoded payload contained raw data exposing phone numbers.
- I checked my older tickets, noted the pattern at the end of the URL, and found I could view my own previous ticket that's when it became clear this was both an IDOR‑like access issue and an information‑disclosure problem.
- I ran a very limited, controlled validation to confirm the scope, then stopped further probing.
- From what I could determine, the exposure could be large potentially affecting millions, so I documented everything and reported it responsibly.

💥 Real impact — why this matters beyond theory
This isn't a "could maybe" problem. The consequences are concrete:
- Privacy breach: Phone numbers data exposed through QR payloads (If done OSINT on phone numbers it could expose Name, E-mail, Social Accounts, Home Address, etc.).
- Scalable risk: Short tokens are easier to enumerate, enabling many records to be discovered automatically.
- Business harm: Support costs, investigations, and reputation damage follow fast once customers lose trust.
A tiny design shortcut became an entry point to a large exposure that's the dangerous part.
✅ Practical fixes — what teams should do first
These changes are straightforward and effective; they preserve user experience while closing the easy attack paths:
- Use long, cryptographically secure tokens. Make enumeration impractical.
- Enforce server‑side authorization. Don't return QR payloads unless the request is authorized. Server checks matter more than client overlays.
- Encrypt or minimize QR payloads. Avoid embedding raw PII; if necessary, sign or encrypt the payload so only trusted clients can decode it.
- Render expired content server‑side. Serve a safe placeholder instead of hiding data with a client overlay.
Fixing these items removes the fast path from curiosity to catastrophe.
💬 The human part — why this mattered to me
Finding bugs feels a little like solving a quiet puzzle at 2 a.m. — thrilling, focused, oddly peaceful. But it's never just about the thrill. These are real people's numbers and travel details. That reality keeps me responsible. The best reward is knowing a simple report can prevent real harm for thousands of users.
