How I Found Ten Vulnerabilities in a School Platform Serving Thousands of Students Across India
How I Found Ten Vulnerabilities in a School Platform Serving Thousands of Students Across India
May 27, 2026
I am an alumnus of St. Karen's High School, Patna. I have no formal background in cybersecurity. What I do have is a habit of looking carefully at how things work — and a willingness to follow that curiosity wherever it leads.
After reading Nisarga's write-up on the CBSE OSM portal, I grew curious about the alumni portal my own school uses. A few hours later, I had found ten security vulnerabilities across four properties — all operated by the same vendor, Franciscan Solutions Pvt. Ltd — affecting the personal data, financial records, and account security of students and alumni across dozens of schools in India.
This is the full account of what I found, how I found it, and what I believe it means.
The Platform
My school's alumni portal is at alumni.stkarenshighschool.com. At the bottom of every page, a small line reads:
Designed & Maintained by: Franciscan Solutions Pvt. Ltd
The same footer appeared when I visited alumni portals for other schools — Our Lady of Fatima Convent in Gurugram, Kundan Vidya Mandir in Ludhiana, Rosary Sr. Sec. School in Delhi. Different schools, same platform, same vendor. This is a shared SaaS product used by dozens of institutions across India.
Any vulnerability here is platform-wide, not school-specific.
Part One — The Alumni Portal
The URL That Opened Every Door
After logging in, my profile URL looked like this:
https://alumni.stkarenshighschool.com/User/Alumni/Default.aspx?Id=19162
I changed 19162 to 12002. Someone else's profile loaded — a user from Our Lady of Fatima Convent, Gurugram. A completely different school in a different city.
I tried more values. Every integer returned a full profile: name, birthday, relationship status, home town, location, workplace. No error. No access denied. No check that the requested profile belonged to a user from the same school as the requester.
This is a textbook Insecure Direct Object Reference (IDOR). The server queries the database by ID without asking whether the person requesting that ID is authorised to see it.
The global integer ID space spans at least from 12,000 to 19,762. That is a lot of profiles.
I Could Message Anyone. Anywhere.
The messaging feature lives at SendMsgTo.aspx, which accepts the same ?Id= parameter. I loaded it with the ID of a user from Kundan Vidya Mandir, Ludhiana. A compose box appeared, addressed to them. I typed a test string and clicked Send.
It went through.
I captured the network request. The POST body contained only:
__EVENTTARGET=ctl00$ContentPlaceHolder1$lbtnSend
ctl00$ContentPlaceHolder1$txtMsg=test
No sender ID. No recipient ID. No school identifier. The server determined the recipient from the URL parameter alone and applied no cross-school check. The same vulnerability extended to friend requests.
Email Addresses Hidden in Plain Sight
The platform uses ASP.NET WebForms, which stores page state in a hidden field called __VIEWSTATE. This field is base64-encoded — not encrypted. Running a single command in the browser console:
atob(document.querySelector('[name="__VIEWSTATE"]').value)
...revealed the profile owner's email address on every profile page I visited, despite that email appearing nowhere in the visible interface.
Combined with the IDOR: visit any profile, decode the ViewState, extract the email. Repeat across 7,000+ profiles. Fully passive, completely invisible to the victim.
A Server Running Software From 2005
A standard header check revealed:
x-aspnet-version: 2.0.50727
ASP.NET 2.0 reached end-of-life in July 2011. This platform is running a runtime with no security patches for fifteen years, affected by CVE-2010-3332 — the Padding Oracle attack — which can enable authentication bypass without knowing any user's password.
Part Two — The ERP and Payment Portal
Franciscan Solutions also operates a full school ERP at app.franciscanecare.com, connected to a fee payment portal at payment.stkarenshighschool.com.
A Token That Never Expires
When a student navigates to the fee section, the ERP generates a signed token and redirects the browser:
https://payment.stkarenshighschool.com/mlogin.aspx?token=<TOKEN>
I copied this URL. I opened a fresh incognito window — no session, no cookies, no authentication. I pasted the URL and pressed Enter.
The fee portal loaded. Fully. With all fee records and official receipts accessible and downloadable.
The token had no expiry. It required no active session. Anyone who captured it — from browser history, network logs, a shared screenshot, a HAR file — would have permanent, unrestricted access to that student's financial records.
Merchant Credentials in a URL Anyone Could See
When a student clicks Pay Now, the server constructs a redirect to the Atom PayNetz payment gateway:
https://payment.atomtech.in/paynetz/epi/fts?login=440064&pass=386c0aaf&...
pass=386c0aaf is the school's merchant password for the Atom PayNetz account — transmitted in a GET URL, visible in DevTools to any student or parent who has ever made a payment. Present in browser history, server logs, and network captures since the portal launched.
The same credential appeared, unchanged, across every payment session I captured.
The Atom PayNetz merchant account controls all fee transaction processing for the school. This credential should be treated as fully compromised.
What I Did Not Do
I tested only accounts registered to me or with the explicit knowledge and consent of the account holder. I did not enumerate IDs at scale. I did not collect, store, or share any user's personal data. I did not use the merchant credentials for any purpose. I stopped testing when I had enough to prove the vulnerability class, and did not proceed further.
Responsible Disclosure
I reported all ten vulnerabilities to Franciscan Solutions and CERT-In on the same day of discovery, before any public disclosure. Franciscan Solutions acknowledged the report and held a meeting to discuss the findings. The alumni portal vulnerabilities were acknowledged. The vendor stated other issues were under review.
I am publishing this post after that engagement, with technical reproduction details withheld for the most critical findings until remediation is confirmed.
What This Means
Every vulnerability documented here falls into the category of business logic failures — they are not exploitable by automated scanners, not detectable by WAFs, and not visible to intrusion detection systems. They require a human who understands how web applications are supposed to work, and who notices when they don't.
The root cause of every finding is the same: the server trusts the client. User IDs come from URLs. Merchant passwords travel through browsers. Session tokens persist without expiry. These are not obscure edge cases. They are the baseline that every web application handling personal or financial data should have right.
Thousands of students and families use these systems. Their data deserves better than this.
Timeline
| Date | Event | |------|-------| | May 27, 2026 | Vulnerabilities discovered | | May 27, 2026 | Reported to Franciscan Solutions and CERT-In | | May 27, 2026 | Vendor acknowledged and requested meeting | | Post-meeting | This post published |
Hemant Kumar is an alumnus of St. Karen's High School, Patna. Contact: contactme@hemantkumarmp.in