# Responsible Disclosure: How a Single Mobile Flaw Exposed Million+ Student, Parent & Teacher Records Across India
> **Author:** Ashitesh Kumar Singh (Class 12th Student & Independent Quantum Computing & Cryptography Researcher • [GitHub](https://github.com/AshiteshSingh))
> **Category:** Mobile Security / Reverse Engineering / Cloud Infrastructure / Responsible Disclosure
> **Status:** Remediated & Officially Acknowledged by CERT-In
---
## 📌 Executive Summary
In July 2026, while in **Class 12th**, I was reverse engineering and analyzing the client-side architecture of a widely adopted Indian school enterprise resource planning (ERP) platform used by my own school. During this research, I uncovered an escalating vulnerability chain.
What began as an inspection of local caching on my personal student account quickly escalated into direct access to central cloud infrastructure, production databases, and master administrative accounts. The vulnerability exposed an estimated **5 million+ citizen entities** (a conservative baseline calculation factoring in all enrolled students, parents, and faculty across thousands of schools nationwide, with the actual real-world total likely being even higher), spanning over **12 TB+ of sensitive records**—including:
* Detailed personally identifiable information (PII) of minor students
* Parent contact data & financial records
* Faculty dossiers & master administrative credentials
* Enterprise employee payroll and salary registers
* Defense-affiliated school registries
If an adversary had exploited this architecture, the private data of millions of students, parents, and teachers would have leaked across the country. Furthermore, the elevated access technically granted full write and update privileges—meaning I had the capability to **manipulate exam marks, alter academic records, falsify attendance, and modify fee payment ledgers**.
Rather than tampering with any records or exploiting this access, I immediately halted all database operations, prepared a reproducible Proof of Concept (PoC) for validation, and coordinated with **CERT-In (Indian Computer Emergency Response Team)**. Following formal verification and vendor remediation, CERT-In issued an official acknowledgment recognizing the responsible disclosure.
---
## 🔍 The Reality Check: An 8 GB Slice of My Own School
To verify the scope of the vulnerability safely without intruding into unauthorized organizations, I restricted testing strictly to the tenant slice of my own enrolled school.
As a **Class 12th student** analyzing an application I used every day, this was no longer an abstract dataset or synthetic test entries—these were real-world production records belonging to my own classmates, friends, and teachers:
* **Complete Academic Profiles:** Unrestricted access to classmates' full academic histories, raw exam marksheets, internal performance remarks, attendance logs, and disciplinary notes.
* **Arbitrary Record Manipulation (Untouched):** Elevated access carried write privileges that made it technically possible to arbitrarily alter exam scores, modify report cards, clear pending tuition fee dues, and tamper with student profiles. Adhering to strict ethical principles, **not a single record was ever modified, falsified, or tampered with.**
* **Intimate Identity Records:** Direct visibility into student profile photos, residential home addresses, and linked national identity documents (including student and parent Aadhaar records and PAN details).
* **Financial & Banking Records:** Parent bank account numbers, fee payment transactions, tuition billing histories, and saved card transaction tokens.
* **Device Telemetry & Expired Token Replay:** Hardware identifiers, device models, OS versions, and push notification tokens. Critically, backend verification failed to enforce proper invalidation—allowing state queries and data retrieval through expired tokens and orphaned device sessions.
> ⚠️ **Scope & Scale:** Querying the partition for just my own school accounted for approximately **8 GB** of sensitive data. Extrapolating this verified footprint across the **thousands of educational institutions** served by the platform nationwide—including several schools catering to families of Indian defense personnel—established an aggregate central data footprint exceeding **12 TB+** and upwards of **5 million+ citizen records** (calculated as a conservative lower bound across students, parents, and teachers, with the actual total likely to be even higher). If breached by a malicious threat actor, the personal and financial data of millions of students, parents, and educators would have been catastrophically leaked.
---
## 🌐 The Full Scale of Exposure
Beyond student and institutional records, deeper infrastructure routes revealed unrestricted access to central administrative systems:
```text
[Student Mobile App]
│
▼ (Static APK Analysis / JADX)
[Insecure SQLite Persistence (CWE-312)]
│
▼ (Plaintext Operational AWS Keys Extracted)
[Internal 12-Hour Rotating Service APIs]
│
▼ (Unrestricted IAM Escalation)
[Central Production Clusters (12 TB+ / 5M+ Records)]
├── Student & Parent PII (Aadhaar, Marks, Bank Data)
├── Defense School Registries
├── Cleartext Master Admin Credentials
└── Corporate HR, Payroll & Employee Salaries
```
* **Master Admin Portals:** Cleartext administrative passwords that allowed direct logins into multi-tenant master consoles across **thousands of schools**.
* **Corporate & Employee Data:** Internal company payroll databases, staff salaries, HR files, and vendor configuration secrets.
* **Defense School Assets:** Confidential student and parent rosters for educational institutions operating under defense family welfare boards.
---
## ⚙️ Technical Breakdown
### 1. Static Reverse Engineering & APK Logic Inspection
Applying static reverse engineering to the vendor's production Android APK (using **JADX-GUI** and **APKTool**) revealed that permanent root AWS keys were not hardcoded in the string pool. However, decompiling and reversing the client session management logic exposed a critical architectural flaw: upon successful authentication, operational credentials were written directly into local app cache files.
---
### 2. Dynamic Execution & Insecure Local Persistence (CWE-312)
Accessing an Android application's sandboxed internal database directory (`/data/data/`) normally requires root permissions on a device. Instead of rooting a physical smartphone, I utilized **LDPlayer** (with root mode enabled) as a controlled testing environment.
Authenticating through my legitimate personal student account inside the emulator, I inspected the app's internal database directory via ADB:
```bash
adb shell
su
cd /data/data//databases/
sqlite3 local_cache.db
```
Querying the SQLite database confirmed the critical failure: **The app stored active operational AWS Access Key IDs and Secret Access Keys in plaintext on client-side storage.**
---
### 3. Traversing the 12-Hour Rotating API
The recovered credentials carried overly permissive IAM policies across the vendor's cloud environment:
1. The keys granted direct interaction with an internal service routing gateway.
2. Within this subsystem, a secondary service API rotated access tokens every 12 hours.
3. Inspecting routing tables and endpoint responses exposed direct connection paths leading straight into the vendor's central production database clusters.
---
### 4. Verification and Ethical Cessation
Once the 8 GB institutional slice and the existence of multi-terabyte production tables were confirmed, all probing was terminated immediately:
* 🚫 **No data dumping:** No tables were dumped, mirrored, or exfiltrated.
* 🚫 **Zero data tampering:** Marks, fees, attendance, and student profiles were never modified or altered.
* 🚫 **Zero retention:** No personal records of classmates, parents, or staff were retained.
* 🧹 **Complete sanitization:** All temporary debugging databases, tokens, and test logs were permanently wiped from the testing machine.
---
## ⏱️ Disclosure Timeline
| Date | Milestone / Action |
| :--- | :--- |
| **July 07, 2026** | Insecure client-side key storage discovered; personal school dataset and master cloud endpoints mapped. |
| **July 08, 2026** | Database scope (8 GB school slice / 12 TB+ total infrastructure across thousands of schools) verified; all probing halted immediately. |
| **July 09, 2026** | Initial report submitted; CERT-In replied requesting step-by-step video/screenshot PoC with active timestamp. |
| **July 10, 2026** | Non-destructive PoC submitted. CERT-In registered formal incident under official **Ref: CERT-In [Redacted]**. |
| **July – August 2026** | CERT-In coordinated remediation with the ERP vendor; cloud IAM policies tightened, client persistence removed, and DPDP consent framework planned. |
| **September 24, 2026** | CERT-In confirmed full remediation and issued an official Letter of Acknowledgment to **Ashitesh Kumar Singh**. |
---
## 🛡️ Verification Proofs & CERT-In Correspondence
### 1. PoC Request with Active Timestamp (July 09, 2026)
Following initial reporting, CERT-In's Incident Response team verified receipt and requested an active-timestamp validation proof:
---
### 2. Official Incident Registration (July 10, 2026)
Upon receiving the step-by-step PoC, CERT-In formally registered the incident and assigned a case reference ID:
---
### 3. Formal Acknowledgment of Responsible Disclosure (September 24, 2026)
Following vendor remediation and verification, CERT-In issued an official acknowledgment letter:
---
## 🏆 The Outcome: Safeguarding Millions & Enforcing DPDP Compliance
* **Zero Records Breached, Everything Fixed:** Because this disclosure was conducted in strict good faith, **not a single record was leaked, breached, or sold**. All vulnerable endpoints, credential persistence flaws, and permissive IAM roles were thoroughly remediated and patched.
* **Protecting 5 Million+ Students, Parents & Teachers:** As a Class 12th student, I am glad and proud to have helped secure the sensitive personal data of approximately **5 million+ students, parents, and teachers** (calculated as a conservative baseline across thousands of schools, though the true figure is likely even higher) before any malicious actors could discover and weaponize this flaw.
* **Mandated DPDP Act (Digital Personal Data Protection) Consent:** Because this massive dataset involved the PII of minor students, the vulnerability exposed significant compliance vulnerabilities. Following this disclosure and CERT-In's intervention, the vendor was required to enforce **explicit DPDP Act consent workflows and parental consent verification** directly into the platform's login and onboarding architecture.
---
## 💡 Key Takeaways for EdTech & Mobile Security
1. **Zero Trust on Client Storage**
Mobile devices must never store cloud infrastructure keys or IAM credentials. All database interactions must terminate at an authenticated backend API implementing strict role-based access control (RBAC).
2. **Proper Token Lifecycle Management**
Session tokens and authentication artifacts must be validated server-side on every request, with strict expiration enforcement to prevent token replay and orphaned sessions.
3. **Strict Cloud IAM Scoping (Principle of Least Privilege)**
Cloud identities must adhere to the Principle of Least Privilege (PoLP). A client-facing configuration must never have network paths or IAM permissions to query master production clusters, corporate HR payroll, or cross-tenant datasets.
4. **Compliance by Design (DPDP Act & Minor PII)**
Platforms managing students' and minors' records must treat data protection as a legal baseline. Integrating transparent consent, parental verification, and automated audit logs is essential for compliance under modern regulations like India's DPDP Act.
---
> **Responsible Disclosure Notice:**
> This vulnerability was researched and disclosed entirely in good faith in compliance with responsible security disclosure standards. All vendor names, sensitive endpoints, school identifiers, and exploit scripts have been omitted or redacted.