Sitemap
Vermadevkumar

Vermadevkumar

One File, One Line of Code, One Institution’s Worth of Data: Why Cybersecurity Cannot Stay an Afterthought

6 min readOct 24, 2026

A few days ago, security researchers disclosed something called PHP2Shell: two critical flaws, tracked as CVE-2026–109618 and CVE-2026–109619, sitting inside PHP itself, the language that quietly powers a huge share of the web. A single request, sent by someone with no login and no special access, can let an attacker run code on a server before any application code even gets to execute. Researchers have called it one of the most severe PHP vulnerabilities ever found. There were already signs of people attempting to exploit it before the fix was even made public.

I bring this up because it is a reminder of something I keep running into in my own work. It does not take a sprawling, sophisticated breach to put thousands of people’s information at risk. Sometimes it only takes one unpatched line, one misconfigured server, or one forgotten file. The distance between a minor oversight and a mass data exposure is often just time: the time before someone finds the problem, and whether anyone is listening when they report it.

That second part is what I actually want to talk about.

Cybersecurity as an afterthought

In my spare time, I do responsible vulnerability research, mostly aimed at Indian educational institutions. Student and admissions portals tend to be exactly the kind of software that gets built once and then left alone for years. When I find something, I report it through proper channels and expect nothing in return beyond an acknowledgment that someone saw it.

One thing I have noticed doing this work across borders, informally, is how differently institutions treat the idea of being reported to in the first place. Universities abroad quite often run a formal vulnerability disclosure program, a published page that tells a researcher exactly where to send a report and what to expect back. In my experience looking at Indian institutions, that is rare. Of all the ones I have researched or reported to, IISc Bangalore is the only one I have found with anything resembling a proper disclosure channel. Everywhere else, I have had to track down a general contact, a professor’s email, or someone on LinkedIn, and hope it reaches the right person.

Some institutions handle this well regardless. I have reported issues such as authentication gaps, exposed admin endpoints, and outdated libraries carrying known vulnerabilities, and a number of them responded quickly and fixed what I flagged. Internshala’s engineering team, for example, wrote back within a few days and asked for a proof of concept so they could reproduce the issue and patch it properly. That is what the process is supposed to look like.

It does not always go that way, though. I have sent formal reports that simply disappear. No acknowledgment, no fix, nothing, for weeks at a stretch. When the usual channel goes quiet like that, you are left wondering whether anyone ever actually read it, or whether it is sitting unopened in a general inbox somewhere.

What I found, and what happened after

The most recent case involved a backup configuration file that had been left publicly accessible on a university website. Nothing was broken into to find it. It was simply a URL that should not have been reachable, but was. A file like that typically holds database credentials and the security keys a site depends on to keep logins and sessions safe. If it gets picked up by an automated scanner before anyone notices, the risk stops being theoretical very quickly.

Get Vermadevkumar’s stories in your inbox

Join Medium for free to get updates from this writer.

People reading this will probably assume I am talking about some small, under-resourced college with no IT budget to speak of. I am not. This is an Institution of National Importance, the same legal tier that includes the IITs, the IIMs, and the NITs. If an institution with that status and that kind of funding can leave a database password sitting in a public URL for anyone to find, it says something about how low a priority this still is almost everywhere, not just at the places you would expect it from.

Press enter or click to view image in full size
This is the screen shot of burp suit of the http request exposing all the credentials.
Press enter or click to view image in full size
Exposed Crucial Keys
Press enter or click to view image in full size
This is the live exposed backup file on the browser.

I reported it properly first, through a formal report to the institution. There was no response. So I found someone on the development team through LinkedIn and explained the issue to him directly.

His first reply was, “Why are you doing this? What do you want?”

It did not read as hostile so much as genuinely confused that a stranger would flag a security problem for nothing in return. I explained again that I was not asking for anything, that I simply thought a university’s worth of student data being at risk was reason enough on its own. I sent him the full report, and he said he would verify it with the professors who oversee the system. As of writing this, that is where things stand.

Why this keeps happening

I do not think the problem is bad intent. I think it is that cybersecurity, in a lot of institutional settings, is nobody’s clearly assigned responsibility until something has already gone wrong. There is often no dedicated contact, no published way to report a vulnerability, and no internal process for handling a message from a stranger saying something is broken. That absence of a disclosure program is not a small detail. It is the difference between a researcher knowing exactly who to write to and a researcher spending days guessing, the way I did here. So it falls through the cracks, not out of malice, but because nobody actually owns it.

PHP2Shell is a useful reminder of how high the stakes in that gap have become. The flaws behind it had quietly existed for years before anyone realized they could be exploited at this scale. The institutions running PHP based systems, and a large number of Indian university portals do, do not get to opt out of that risk simply by not thinking about it. The only real choice is whether they notice before or after someone else decides to use it against them.

I am not naming the institution in this piece, and I will not, until the issue is actually resolved. This is not about calling anyone out publicly. It is about asking why “we take security seriously” so often only becomes true once someone outside the organization insists on it.

If you do this kind of research yourself and have hit the same wall, I would genuinely like to hear about it. If you work at an institution and think this deserves a proper policy rather than guesswork, I would like to hear that too. Please do comment below with your own experience, whichever side of this you have been on, and if an institution or a developer ever receives a report like mine, please just reply to the email.

Feel free to connect with me on LinkedIn if you would like to talk more about this: https://www.linkedin.com/in/dev-kumar-verma-/

Sources:

--

--