I discovered these vulnerabilities in 2023, during my 3rd year of BTech at AKTU (Dr. A.P.J. Abdul Kalam Technical University). For context: I never liked the education system, or the way engineering is taught in most Indian colleges. So even with full root access to the database that stores every student's marks, the thought of touching my own record never crossed my mind.
I had continuous backs through college. Barely cleared them in the final year. But I was never planning to join a company dumb enough to judge me on a college report card over my actual skills, so it didn't matter much to me. I built things, shipped things, broke things on purpose, and that was the education I cared about.
What I'm publishing here is the technical content of a responsible disclosure report I sent to AKTU's senior administration in July 2023. Three years later, the vulnerabilities are still live. So this post is, in effect, a louder second attempt.
How I stumbled into it
It started innocently. I wanted to see one of my own exam answer sheet copies. AKTU runs an online evaluation system where scanned answer sheets are uploaded, distributed to evaluators, graded digitally, and then made available to students on request. The portal that powers all of this is called intelliEXAMS, built by a vendor called MindLogicX. It is essentially the end to end pipeline for e-evaluation of exam copies: scanning, distribution to faculty, online marking, moderation, result generation, and student facing copy delivery.
On the homepage there is a small student login box. Out of habit (and a half formed suspicion) I typed an apostrophe into the username field. The server threw back a SQL error in the response body:
Unclosed quotation mark after the character string 'admin'*'.
Incorrect syntax near 'admin'*'.
That is a textbook signature of a SQL Injection vulnerability. The user input was being concatenated directly into a SQL query against the backend database, with no sanitisation, no parameterisation, nothing. From an attacker's standpoint, that is the front door left wide open.
Mapping the attack surface
Before going deeper, I did a quick Google dork to see what else lived on the same software stack. The vendor leaves a very obvious URL fingerprint that surfaces login pages for different roles inside AKTU (student, faculty, evaluator, admin, college-level) and, more worryingly, login pages for many other major Indian universities running the exact same intelliEXAMS deployment. Since the vulnerability lives in the product itself and not in AKTU's specific configuration, the same SQL injection almost certainly works on most of them. I deliberately did not test any other institution, but the blast radius of a single unpatched vendor bug here is enormous: dozens of universities, millions of students, all behind the same broken login page.
I am intentionally not publishing the dork string here, since it is the fastest path to finding still-vulnerable deployments.
Confirming the SQL injection
I saved the login POST request to a file and ran sqlmap against it:
sqlmap -r login_req.txt
sqlmap confirmed the username parameter was injectable through two techniques:
- Error-based SQL injection
- Stacked queries based SQL injection
It also fingerprinted the stack: Microsoft SQL Server 2014 behind IIS 10.0, running ASP.NET 4.0.30319. Stacked queries on MSSQL is one of the worst combinations to have exposed, because it lets an attacker chain arbitrary statements after the original one.
Enumerating the databases
Next step, list every database on the server:
sqlmap -r login_req.txt --dbsThe instance was hosting 16 databases. Among them:
AKTUDATAIEDB,IEDB_SUMMER2023,IEDBEVALUATIONBatchProcess,BatchProcess_II,BatchProcess_III,BatchProcess_IV,BatchProcess_ModerationReportServer$WINTER2022,ReportServer$WINTER2022TempDB- The usual system DBs:
master,model,msdb,tempdb
From the names alone you can guess what is inside: student data, evaluation data, batch processing of result moderation, an entire semester's exam database. I popped a SQL shell with sqlmap and listed tables in AKTUDATA. Tables like AdminUserGroup, AdminUserGroupDetails, AdminUserLogs, AdminUserProfile, ApprovedColleges, AccessPointTimeSpanDetails showed up immediately. The schema was wide open.
Escalating to an OS shell
On Microsoft SQL Server, if the xp_cmdshell stored procedure is enabled and your DB user is privileged enough, you can execute arbitrary operating system commands on the host. I checked, and yes, it was enabled.
sqlmap -r login_req.txt --os-shell
A working shell on the Windows host. From there I listed the C drive contents and confirmed I was running as a system user with enough rights to enumerate the filesystem and run non-root commands. I did not attempt privilege escalation to SYSTEM or Administrator. The point was already made.
Finding web.config and the database credentials
ASP.NET apps store database connection strings in a file called web.config. From the OS shell I searched for every copy of that file across the D drive:
d: & dir /s web.config
Several copies were returned, including legacy backups going back years. I picked the most recently modified path (the live application) and read it:
D: & cd Application\AKTU\iis & type web.config
Inside that file were the live SQL Server connection strings, with server, port, database name, application user, and the password in plaintext. With those credentials, an attacker no longer needs the SQL injection at all. They can connect directly to the database from any IP that can reach the server, using a normal SQL client. Faster, quieter, and harder to detect than a sqlmap session.
I tested the credentials by opening a connection in DBeaver. They worked. I now had a stable, direct, persistent connection to the production database of one of the largest technical universities in India.
The data that was sitting there
I deliberately limited what I queried, only pulling a few records to confirm the data was real and sensitive. Even with that, the picture was bad:
- Admin accounts in
IEDB.dbo.AdminUser, with user IDs and passwords stored in cleartext. Not hashed. Not salted. Cleartext. - Faculty accounts with names, employment codes, and passwords. Again, cleartext.
- Student PII: names, enrollment numbers, college mappings, exam metadata.
- Internal API keys and URLs in
web.configfor SMS and email providers used by the University.
The database user the application connects with had full rights. Not least-privilege scoped to the few tables it actually needed, full rights on the schema. That meant from a single SQL injection on a public login page, the maximum access I had was effectively:
- Read every row of every table in every database on the server.
- Modify or delete any row of any table. Including marks, results, evaluator assignments, admin permissions.
- Execute OS commands on the Windows host.
- Pivot through the host into the internal network it sits on.
- Impersonate the University by abusing the harvested SMS and email API keys.
I stopped there and wrote the report.
What an attacker could actually do with this
The point of a vulnerability report is not the technical novelty, it is the business impact. So I spelled it out:
- Impersonation. SMS and email keys can be used to send official looking messages to students and faculty for fraud or scams.
- Mass data breach. Personally identifiable information of students and teachers across the university.
- Result manipulation. Marks, passes, fails, degrees. All editable.
- Defamation. Replace exam content or pages with explicit material to embarrass the institution.
- Compromise exam integrity. Access confidential exam papers and evaluation data before or during exams.
- Compromise evaluator anonymity. The system is designed to keep the identity of the evaluator hidden from the student. Direct DB access trivially breaks that.
- Unauthorised admin actions. Create or delete users, alter configurations, manipulate logs.
For a university that issues degrees recognised across India, this is not a theoretical risk. This is the kind of issue that, if exploited by the wrong person, could quietly compromise the validity of an entire exam cycle.
The disclosure, and the silence
I am against cheating, manipulation, and unethical use of access. I did not share these findings with anyone, did not exfiltrate data at scale, and did not sell or post any of it. Instead I wrote a clean VAPT report with reproduction steps, screenshots, redacted proof of access, business impact, and recommended fixes, and I sent it on 15 July 2023.
I found the relevant people on LinkedIn and the AKTU website and emailed:
[email protected](Vice Chancellor)[email protected](Controller of Examinations)[email protected][email protected][email protected][email protected]
What I expected: an acknowledgement, a question or two, and a patch within a reasonable window. Even a one-line "got it, looking into it" would have been fine.
What I got: nothing. No reply. No acknowledgement. No bounty (not that I expected one from a public university, but I asked, politely). Most importantly, no fix. Over the next months I checked occasionally. Same injection, same response, same plaintext credentials sitting in web.config.
I also tried to reach the vendor directly. The bug lives in their product, not in AKTU's configuration, so a single patch from MindLogicX would fix it across every university that runs intelliEXAMS. I sent disclosure messages through the contact channels I could find on their website and via LinkedIn to people listed as engineering and leadership at MindLogicX. Same outcome as AKTU: zero response. Not an acknowledgement, not a "we forwarded this", nothing.
Three years later, in 2026, the underlying vulnerabilities are, as far as I can tell, still exploitable on the same endpoints. MindLogicX is still shipping the same software to the same set of major universities, and none of the institutions I dorked back then appear to have switched stacks.
Why I'm publishing this now
I sat on this for three years because I did not want to be the person who made an already fragile system worse. But last week I read Nisarga's tweet about a vulnerability he found in the CBSE OSM (On Screen Marking) portal, a similar disclosure that only started getting attention after he went public, and it pushed me over the line.
Quiet responsible disclosure assumes the other side is reading. After three years of total silence from AKTU, I think public pressure is now the most responsible thing I can do. Maybe a public post forces someone, the University, the vendor, or a journalist, to push for a fix in days instead of decades.
To AKTU and MindLogicX, the fixes are not complicated:
- Parameterised queries everywhere. Kill string concatenation in SQL.
- Drop
xp_cmdshellon production SQL Server, or at minimum revoke it from the app's DB user. - Apply principle of least privilege to the application's DB account. It does not need
sysadmin. - Stop storing admin and faculty passwords in cleartext. Hash them with a modern algorithm (Argon2id or bcrypt). Add MFA for admin roles.
- Move secrets out of
web.configinto a secret manager, and rotate every credential that was ever exposed. - Put the database behind a firewall / IP allowlist. There is no reason it should accept connections from arbitrary internet IPs.
- Commission a real third party VAPT, not a checklist audit.
None of this is novel. All of it is in the original report I sent in July 2023.
A note for students reading this
If you are a student at AKTU, or any institution running intelliEXAMS, your name, enrollment number, marks, and possibly your password have likely been sitting in a database that anyone with a laptop and an afternoon could reach. That is not your fault and there is not much you can individually do about it, except assume the data is already out there and reuse no passwords with any system that touches your university login.
To end it well. I was always the kid who loved breaking toys more than playing with them. I loved tinkering. But after I moved to 11th grade I noticed something shift in the people around me. The other kids got serious. They were preparing for something life changing, something big. When I asked, they said JEE.
And while I saw all these kids studying impossibly hard to pass that one exam that was supposedly going to change their life, I barely saw anyone actually enjoying any of it. Nobody talking about the crazy science behind a problem. Nobody pausing to observe the wonders of the engineering they were trying to get into. They were running behind the illusion of a successful life. And many of them, three years into a degree or wherever they landed, are still running.
I just genuinely enjoyed engineering. I still do. I broke into a university database not because I wanted to game my marks. For me the marks were nothing more than an 8 bit unsigned integer. I did it because somewhere underneath all the result portals and the report cards there was a real system, and I wanted to understand it. The education system actively tries to kill that curiosity. I just managed to save mine. And it is the part I most wish more students around me had fought to keep.
If you are a student at AKTU, or anywhere similar, please do not let four years of mark sheets convince you that your real worth lives on a piece of paper signed by a Controller of Examinations. The institution that prints those sheets cannot even keep them safe. Build things. Break things on purpose. Be honest about what you find. The world outside the report card is much more interesting, and much more forgiving, than the inside of it.
Original report submitted to AKTU on 15 July 2023. No personal data of students or faculty is included anywhere in this article. Credentials and identifiers were redacted from all screenshots in the original PDF and are not republished here. If you are at AKTU or MindLogicX and want to coordinate a fix, please reach me at [email protected]. I don't expect any monetary reward from you.