A Look at Upcoming Innovations in Electric and Autonomous Vehicles A Teenager Found Five Critical Flaws in CBSE's Exam Portal. Nobody Fixed Them.

A Teenager Found Five Critical Flaws in CBSE's Exam Portal. Nobody Fixed Them.

A seventeen-year-old who had just finished his own Class 12 board examinations opened a browser, pulled up the Central Board of Secondary Education's new digital marking portal, and within hours had discovered that the system evaluating the answer scripts of 1.8 million students could be breached by anyone willing to read a JavaScript file. Nisarga Adhikary reported his findings to India's national cybersecurity agency, CERT-In, on 25 February 2026. Nearly three months later, the vulnerabilities remained unpatched. On 22 May 2026, with students already raising public alarms about wrong marks and blurred scans, he published everything.

What the Portal Was Doing Wrong - and How Badly

CBSE introduced its On-Screen Marking system by circular on 9 February 2026. Under the arrangement, physical answer sheets are scanned at designated centres and uploaded to a portal operated by private vendor M/s Coempt EduTeck Pvt. Ltd. on what appears to be its "OnMark" platform. Examiners log in and grade scripts on screen. The portal handles the assessed work of every Class 12 candidate in the country.

What Adhikary found was not a single, exotic vulnerability requiring rare expertise. It was five elementary failures, stacked on top of one another, any one of which would have been cause for serious concern.

  • A hardcoded master password in public JavaScript. The portal's JavaScript bundle - downloadable by any visitor - contained a master password in plaintext. Entering it caused the application to auto-fill the one-time password field and bypass multi-factor authentication entirely. The second factor was not a second factor. It was theatre.
  • The OTP returned to the browser. When a normal login was triggered, the server sent the one-time password back inside the authentication response itself. The application then compared what the user typed against what the browser had just received. The secret was handed over before it was tested.
  • No access controls on internal pages. The Angular application had no route guards - no mechanism to verify that a user navigating directly to internal URLs like /dashboard or /evalscriptsview had authenticated at all. Writing a few values into browser storage and typing a URL was sufficient to reach marking screens.
  • A password-change endpoint that ignored the old password. The API accepted a valuator ID and a new password and made the change. The old password field visible on the form was collected, then silently discarded before the request was sent to the server.
  • Systemic Insecure Direct Object Reference (IDOR). Nearly every API call read the user's identity from the browser's own session storage and trusted whatever value it found there. Changing a single value in browser developer tools was enough to act as any examiner in the system.

The fourth and fifth flaws together allowed complete, credentialless takeover of any examiner account on the platform. From there, an attacker could view assigned answer scripts and alter marks. As Adhikary himself put it, "the hardest part was reading a JavaScript file and editing a couple of values in DevTools." He estimated he could have corrected the defects, had they been his to fix, in an hour or two.

An Acknowledgement, Then Silence - While Students Complained Publicly

CERT-In registered the disclosure, assigned it an incident reference number, and replied with a boilerplate email advising that it was "in process of taking appropriate action with the concerned authority." Adhikary provided additional detail on request, including a video walkthrough. After that, nothing. His follow-up messages received no substantive response, and the vulnerabilities, on his account, were not remediated.

This pattern will be familiar to anyone who has filed a responsible disclosure with CERT-In. The agency's statutory mandate under Section 70B(4) of the Information Technology Act, 2000, requires it to collect and analyse incident reports, coordinate response, and issue advisories. Rule 12 of the CERT-In Rules, 2013 prescribes the action to be taken. What actually happened here, beyond the acknowledgement email, is not publicly known - a point made more pointed by the fact that a November 2023 amendment to the Second Schedule of the Right to Information Act now exempts CERT-In from that statute entirely, closing the principal channel through which citizens could have sought answers.

CBSE declared Class 12 results on 13 May 2026. From around 19 May, students and parents began posting publicly about incorrect marks, blurred scanned answer sheets, missing pages, portal failures and payment errors in the re-evaluation process. Complaints accumulated under the hashtags #banOSM, #GRACEUSCBSE and #cbseSCAM on X. Press coverage from Deccan Herald, ANI, Careers360 and OneIndia documented the volume and specificity of the complaints. CBSE maintained that its post-result verification process was functioning normally.

It is worth recalling that in March 2026 - while the disclosed vulnerabilities sat unaddressed - CBSE had warned teachers and others not involved in evaluation that they faced legal action for sharing "misleading" or "factually incorrect" information about the OSM process on social media.

The Legal and Institutional Failures Behind the Technical Ones

The Internet Freedom Foundation has now written to the Secretary of the Department of School Education and Literacy and to the Director General of CERT-In. The representation requests an investigation into CBSE's conduct, a review of its contract with Coempt EduTeck, immediate remedial measures, and a transparent public audit and disclosure. The legal dimensions of the situation are considerable.

CBSE processes the personal data of examiners and 1.8 million candidates through the OSM portal. It is a Data Fiduciary under Section 2(i) of the Digital Personal Data Protection Act, 2023, and is required under Section 8(5) to maintain reasonable security safeguards. Section 8(6) obliges it to notify the Data Protection Board and affected individuals where a personal data breach occurs. That the Act is not yet being enforced in full does not relieve a public authority of the obligation to meet its standard of care. The engagement of a private processor - Coempt EduTeck - does not transfer those obligations away from CBSE.

There is a separate and more immediate compliance question. CERT-In's Cyber Security Directions of 28 April 2022, issued under Section 70B(6) of the IT Act, require any body corporate or government organisation to report cyber incidents - including data breaches, unauthorised access and targeted probing - to CERT-In within six hours of being made aware of them. CBSE was apprised of the disclosure through CERT-In no later than the February-March 2026 period. There is no public confirmation that it filed a mandatory report within the required window. Non-compliance attracts criminal liability under Section 70B(7): imprisonment of up to one year, a fine of up to one lakh rupees, or both.

The deeper problem, as technologist Srinivas Kodali has observed, is structural. CERT-In sits at the centre of India's cybersecurity economy, and that economy has been shaped to be secretive. The Digital Personal Data Protection Act routes any penalties for data breaches to the Government of India rather than to an independent body, which - as Kodali notes - removes structural incentives for institutions to report breaches to any prospective Data Protection Board. The RTI exemption for CERT-In compounds this: the agency can act, or decline to act, on disclosures without any public accountability for what it chose to do.

Against that backdrop, a teenager who had just finished his own board exams acted with more procedural discipline than the institutions nominally responsible for cybersecurity in India. He reported promptly, furnished evidence on request, waited a reasonable period, and disclosed publicly only when it became clear that nothing was being fixed. The vulnerabilities he found were not subtle. A master password shipped inside public JavaScript is not an edge case or an advanced persistent threat. It is a basic misconfiguration that reflects either a vendor with inadequate engineering standards or a procurement process that never asked for a security review - or both.

For 1.8 million students whose examination results passed through that portal, the question of which it was is not academic.