Everyone talks about CVEs like they're some mythical achievement reserved for seasoned professionals with 10 years of experience and a hoodie covered in conference stickers.
I'm a BCA student. I found five.
This isn't a flex post. It's the guide I wish existed when I started — because most resources out there skip the parts that actually matter.
Why I Started Bug Hunting
I was deep into TryHackMe rooms and HackTheBox machines, grinding through CTFs at 2 AM, and somewhere in between I started asking myself: is any of this real?
CTFs are fun. But they're controlled environments. Somebody built that box for you to break. The vulnerability is there, guaranteed. Real-world software doesn't come with that guarantee — but it also doesn't come with a scoreboard, a leaderboard, or a congratulations banner when you find something.
What it comes with is a CVE ID with your name on it.
That was enough motivation for me.
The Target I Picked (And Why It Matters More Than Anything Else)
Here's what no guide tells you clearly: your target selection determines everything.
Most beginners go after massive companies — Google, Facebook, Apple. They read about million-dollar bug bounties and aim there first. That's like learning to drive and immediately entering Formula 1.
My approach was different:
Open-source software with a public repo — I could read the actual code, not just probe blindly
Actively maintained but not a massive team — bugs slip through, patches take time
Software I actually used — I understood the functionality deeply, which meant I noticed when something shouldn't work the way it did
I started with smaller tools and libraries in the security and networking space. Stuff I was already using in my VAPT work. When you know how something is supposed to behave, anomalies scream at you.
The Moment I Found the Vuln
I'm not going to walk through the exact technical details of my first CVE here — that's a separate write-up. But I'll tell you what the moment felt like.
It wasn't dramatic. There was no alarm, no flashing "YOU FOUND IT" screen.
It was: wait... that shouldn't respond like that.
I sent a request. The response was wrong in a very specific way. I sent it again with a modified input. The response got more wrong. I sat back and thought for maybe five minutes before I opened Burp Suite and started documenting methodically.
The thing about real vulnerabilities is they feel like a quiet click — not an explosion. The adrenaline comes later, when you're writing the report and you realize what you're looking at.
What helped me spot it:
I had read the documentation and the source code
I was testing edge cases, not just happy paths
I kept notes on every weird behavior, even stuff that seemed minor
I was patient — I'd been poking at this target for days, not hours
The Reporting Process (The Part Nobody Romanticizes)
This is where most write-ups end. "I found it, reported it, got the CVE."
Here's what actually happens:
- Write the report like your reputation depends on it — because it does. Your report needs:
Clear description of the vulnerability
Affected versions
Step-by-step reproduction (assume the person reading has 10 other reports open)
Impact assessment
Suggested fix (optional but respected)
- Find the right contact. Check for a SECURITY.md in the repo. Look for a security@ email. Check their responsible disclosure policy. If none of these exist, open a private GitHub issue or DM a maintainer directly. Do NOT open a public issue.
- Wait. Then wait more. My first report sat for 3 weeks without a response. I sent a polite follow-up. Another week passed. Then I got a one-line reply: "Confirmed. Working on a patch." That's it. No fanfare. Just confirmation that you weren't imagining things.
- Coordinate the disclosure. Work with the maintainer on a timeline. Give them reasonable time to patch — typically 90 days is the industry standard. Don't rush them. Don't go public early. Responsible disclosure is called responsible for a reason.
- CVE assignment. Once the patch is out, either the vendor or a CNA (CVE Numbering Authority) assigns the ID. Sometimes you request it yourself through MITRE. Either way, you end up with a number that lives on the internet forever.
What Changed After
Practically speaking? A lot.
My resume went from "student with certs" to "student with verified security research"
I started getting responses from recruiters who previously ignored me
My confidence in real-world testing went through the roof
I found four more CVEs because the pattern recognition you build is transferable
But the bigger thing was this: it shifted how I see software. Everything is a potential target now — not in a malicious way, but in a deeply curious way. Every feature is a decision someone made. Every decision has edge cases. Every edge case is worth poking.
What I'd Tell My Past Self
Start smaller than you think you should. Seriously. Small open-source tools. Niche libraries. Things with fewer eyes on them.
Read the code. Black-box testing is fine but white-box gives you an unfair advantage.
Document everything. Even the dead ends. You'll thank yourself later.
Be patient with maintainers. They're usually volunteers or small teams. They're not ignoring you — they're busy.
Rejection is fine. Not every report is a CVE. Some are "working as intended." Learn from those too.
The first one is the hardest. After that, you have a framework in your head and the next one comes faster.
Resources That Actually Helped Me
HackTheBox & TryHackMe — for building the baseline
PortSwigger Web Security Academy — free, brutal, excellent
CVE Details (cve.mitre.org) — study what's been found before
GitHub Code Search — your best friend for finding vulnerable patterns
Nuclei templates — understand how automated scanning works, then go beyond it
If you're a student sitting on this page wondering if someone like you can actually do this — yes. You can.
You don't need a degree in computer science. You don't need a senior title. You need curiosity, patience, and the willingness to sit with a weird behavior until it tells you what it's hiding.
The software is out there. Go find something.
I'm Krish — BCA student, CEH certified, 5x CVE researcher, and active on HackTheBox/TryHackMe. I lead my university's cybersecurity club and do VAPT work.Find me at dev.to/krrish_jagbandhu_eca8db9dShare
