Disclaimer:
This research was conducted responsibly, in good faith, and coordinated through CERT/CC. No sensitive details, exploit payloads, or live systems are exposed in this post.

When I started testing my college’s website, I wasn’t trying to “hack” anything in the dramatic sense.

I was a computer science student, interested in cybersecurity, doing what many security-minded students do: poking at systems to understand how they work, and where they break.

What I didn’t expect was that this curiosity would lead me to discover a vulnerability affecting over 100 educational institutions, eventually resulting in an officially assigned CVE with a CVSS Score of 9.8 (Critical).

This is the story of how that happened.

It all started With a Login Page

Like many colleges, mine uses a web portal for things like:

student logins
exam results
internal marks
academic records

While interacting with the login functionality, I noticed behaviour that immediately raised red flags from a security perspective.

After careful, limited testing, it became clear that the login flow was vulnerable to SQL Injection! A classic but still dangerously common vulnerability.

At first, I assumed this was just a local issue.

I was wrong.

Realizing This Wasn’t Just One Website

Digging a bit deeper (still responsibly), I noticed that the same web application with the same structure and the same behavior was being used by many other colleges.

This wasn’t a single vulnerable site, it was a vulnerable product that is trusted and deployed across multiple institutions.

At that point, the stakes changed completely.

A vulnerability like this doesn’t just mean a broken login page,

It meant:
Exposure of student data
Exposure of faculty data
modification of exam results
loss of trust in academic systems
And in some configurations, something even worse.

From SQL Injection to Something More Serious

In several real-world deployments, the database configuration allowed the SQL Injection to be escalated further.

Without going into exploit details, this meant that:
Arbitrary SQL queries were possible.
And depending on configuration, operating-system level command execution could be achieved.

In other words, a login form bug could become a full system compromise.

That’s when I stopped testing and moved straight to responsible disclosure.

Reaching out to the vendor

First thing that I did was to responsibly prepare a report and mail it to the vendor.
However, the vendor did not have any established medium for reporting security vulnerabilities.
I tried to reach out to the relevant people in the company, and eventually contacted the Chief of Operations, he acknowledged my finding, and asked me to wait for a while and that they would fix it.

Waiting game began

Now came the most annoying part, the vendor did not fix it, and stopped responding to my messages and emails all together, I digged a bit and discovered that this vulnerable product has been shipped to 100+ institutions that held about 1M+ students data.

This made me think that the irresponsible behaviour of the vendor would directly impact the security, and privacy of at least 1 million students whose data was hosted on vulnerable web servers.

Choosing Coordinated Disclosure

Instead of publishing anything or contacting institutions directly, I reported the issue through CERT Coordination Center (CERT/CC).

This kicked off a long coordination process involving:
CERT reaching out to the vendor.
Rounding up all affected deployments.
Rolling out a patch to fix the vulnerability
Retesting and patch verification.
and careful handling to avoid harm.

At multiple points, fixes were attempted, re-tested, and refined to ensure the vulnerability was actually resolved.

Eventually, after proper validation, the issue was formally recognized and assigned a CVE.

The CVE

The vulnerability is now tracked as:

👉 CVE-2025–14598 (CVSS Score: 9.8)

🔗 CVE record: https://cve.org/CVERecord?id=CVE-2025–14598

A public Vulnerability Note was also published through CERT/CC:

🔗 CERT Vulnerability Note: [kb.cert.org/vuls/id/361400]

For those interested in the technical details (without exploit code), I’ve also published a full technical write-up here:

🔗 Technical blog post: [www.afnaan.me/…]

🔗 Github Repository: [github.com/Afnaan-Ahmed/…]

What I Learned From This

A few important takeaways from this experience:

1. “Simple” Bugs Can Have Massive Impact
SQL Injection is decades old, yet it still appears in critical systems — sometimes at national scale.

2. Configuration Matters
The same vulnerability can range from “bad” to “catastrophic” depending on how systems are configured.

3. Responsible Disclosure Is Slow, but Worth It
Coordination takes time. It can be frustrating. But it protects users and gives issues the seriousness they deserve.

4. You Don’t Need to Be a Professional to Do Meaningful Research
I wasn’t employed as a security researcher. I was just curious, careful, and persistent.

Final Thoughts

I’m sharing this story not to glorify “hacking,” but to highlight:
How fragile critical systems can be.
How important secure development practices are.
How much impact responsible security research can have.

If you’re a student interested in cybersecurity: learn deeply, test ethically, and disclose responsibly.

Sometimes, that’s all it takes to make a real difference.

Curiosity is powerful. Responsibility makes it meaningful.
Keep hacking.