I never expected my first real bug to be on a government website.
I was just a beginner — a guy with a laptop, some free time, and a curiosity about how things break. No professional training. No years of experience. Just a recon session that went somewhere I didn't expect.
This is the story of how I found a Sensitive Data Exposure vulnerability on nic.in — India's National Informatics Centre — and got it confirmed by NCIIPC (National Critical Information Infrastructure Protection Centre).
🌐 What Is NIC.in — And Why Does It Matter?
For those who don't know, NIC (National Informatics Centre) is the Indian government's primary IT infrastructure body. It manages digital services for hundreds of government departments across the country.
In other words — it's not a small target.
When a vulnerability exists on infrastructure like this, it doesn't just affect one website. It can have implications across the entire government digital ecosystem.
That made what I found feel a lot more serious than I initially realized.
🔍 How It Started — A Routine Recon Session
I wasn't specifically targeting nic.in that day.
I was practicing recon — the process of gathering information about a target before testing it. Recon is usually the first phase of any bug bounty or penetration test, and I was doing it purely to sharpen my skills.
Recon involves things like:
- Looking at what subdomains exist
- Checking what technologies a site is running
- Identifying exposed files or directories
- Mapping out the attack surface
I was working through a target methodically, running through my checklist, when something caught my eye.
A response that shouldn't have been there.
💀 The Vulnerability — Sensitive Data Exposure
What I found was a Sensitive Data Exposure vulnerability — specifically, internal server and configuration information that was being leaked publicly.
This type of vulnerability happens when a web application or server accidentally reveals information it shouldn't. In this case, internal configuration details were accessible without any authentication.
Why is this dangerous?
Configuration and server information gives an attacker a roadmap. It can reveal:
- What software and versions are running (useful for finding known CVEs)
- Internal architecture details
- Potential entry points for deeper attacks
It's the kind of information that turns a blank wall into a door.
For a system as critical as NIC's infrastructure, having this exposed publicly was a significant security gap.
😰 The Moment I Realized What I'd Found
Honestly? My first reaction wasn't excitement.
It was panic.
I sat there staring at my screen thinking — is this real? Did I actually just find this? On a government site?
I refreshed the page. Still there. I tried a different browser. Still there. I checked if maybe I was misreading the output.
I wasn't.
The next thought was immediate — I need to report this. Now.
This is something a lot of beginners don't talk about. Finding a real vulnerability, especially on something this serious, doesn't feel like a victory at first. It feels like responsibility.
📧 Reporting to NCIIPC
NCIIPC (National Critical Information Infrastructure Protection Centre) is India's nodal agency for protecting critical information infrastructure. They operate under the Prime Minister's Office and handle vulnerability disclosures for government systems.
I drafted my report carefully:
- Clear description of what I found
- Steps to reproduce the vulnerability
- Screenshots as proof of the exposure
- Impact assessment — why this mattered
- No exploitation — I documented only what was necessary to prove the issue existed
I sent it off and waited.
Waiting after a disclosure is its own kind of anxiety. You don't know if they'll respond. You don't know if they'll take it seriously. You don't know if somehow you've made a mistake.
✅ NCIIPC Acknowledged and Confirmed It
They responded.
NCIIPC acknowledged the report and confirmed the vulnerability was valid.
I'm not going to pretend I was calm about it. I wasn't. That confirmation felt like the moment everything I'd been studying suddenly became real — not just theory, not just lab exercises, but an actual impact on actual infrastructure.
A bug I found. On a government website. Confirmed by a national cybersecurity agency.
As a beginner, that meant everything.
📚 What This Taught Me
Looking back, here's what that experience actually taught me:
1. Recon is everything. I found this during a basic recon session — not some advanced exploit chain. Fundamentals matter more than fancy tools.
2. Document everything as you go. Because I had clear notes and screenshots from the moment I found the issue, writing the report was straightforward. If I hadn't, I might have lost critical details.
3. Responsible disclosure is non-negotiable. I didn't exploit the vulnerability. I didn't share it publicly before it was fixed. I reported it through the right channel immediately. This is the only ethical path — always.
4. You don't need to be an expert to find real bugs. I was a beginner who hadn't finished CEH. I didn't have years of experience. I just had curiosity, a methodology, and the discipline to follow through.
5. The feeling of real impact is different from anything else. TryHackMe rooms are great for learning. But nothing prepares you for the feeling of finding something real. It changes how you see everything.
🏁 Final Thoughts
If you're a beginner reading this — I want you to understand something.
I was you not long ago. Confused, uncertain, wondering if I actually had what it takes to do this for real.
The answer came not from finishing a course or passing a certification — it came from sitting down, doing the work, and following my curiosity wherever it led.
Bug bounty isn't about skill level. It's about methodology, patience, and showing up consistently.
Your first bug is out there. Go find it. 🔍
Found this useful? Follow for more honest cybersecurity content. And if you've found your first bug — drop it in the comments. I'd love to hear your story. 🙌
⚠️ Responsible Disclosure Note: This vulnerability was reported directly to NCIIPC through proper channels before any public disclosure. No data was accessed, extracted, or exploited beyond what was necessary to document the issue. Always practice ethical, responsible disclosure.