Exposing Critical Vulnerabilities in CBSE’s On-Screen Marking Portal: From Authentication Bypass to Full Account Takeover — ni5arga
← back to blog<br>Exposing Critical Vulnerabilities in CBSE’s On-Screen Marking Portal: From Authentication Bypass to Full Account Takeover
May 22, 2026
I first posted a rough write-up of these vulnerabilities to r/CBSE using a throwaway reddit account, but I figured a proper write-up on my own blog would be a better home for it. The tweet (X post) where this is being discussed can be found here.
These vulnerabilities were initially discovered on 25 February 2026 and were promptly reported to CERT-In.
What is CBSE and On-Screen Marking?
The Central Board of Secondary Education (CBSE) is one of the largest national education boards in India. It operates under the Government of India and runs major examinations like the Class 10 and Class 12 board exams for millions of students every year.
CBSE is affiliated with over 28,000 schools in India and several hundred more abroad, which makes it one of the most influential educational bodies in the country. Every year, millions of answer sheets are evaluated by thousands of teachers and examiners as part of the board exam process.
To streamline all of that, CBSE has started moving to a digital On-Screen Marking (OSM) system for the Class 12 board exams (circular). Instead of checking physical answer sheets, examiners log into an online portal where scanned copies of answer scripts are assigned to them for evaluation.
Because this platform is used by huge numbers of evaluators and handles sensitive academic data, its security really matters. It seems like this platform is developed by Coempt EduTeck Pvt Ltd and this same OnMark platform is used by multiple boards & other institutions.
While poking around, I found several critical vulnerabilities in the OSM portal that could lead to full account takeover of examiner accounts. Anyone exploiting these could also tamper with or disrupt the grading process, which directly threatens the integrity of the exam evaluations.
I reported all of this to CERT-In before publishing this blog.
Finding the Vulnerabilities
Some background on me first. I'm a hobbyist cybersecurity researcher and I just finished my Class 12 exams this year. I've done bug bounty and security work for fun before, so when CBSE rolled out OSM and I noticed the portal link was completely public, my curiosity got the better of me.
I opened the On-Screen Marking portal and started playing around with the HTTP requests and everything else I could see.
The login page asks for three things: a user ID, a school code, and a password, followed by an OTP step. Nothing about that screen looks unusual. The problems only showed up once I stopped looking at the page and started looking at the code behind it.
Reading the JavaScript Bundle
Like most modern single-page apps, the portal is an Angular application that ships its entire frontend logic in one bundled, minified JavaScript file. The browser downloads this file and runs it locally to render every screen of the app.
That bundle is served publicly at:
https://cbse.onmark.co.in/cbseevalweb/main.dc17c24606b3b008.js
Anyone can request it, logged in or not. So I pretty-printed it and started reading. What I found inside was horrible.
Vulnerability 1: A Hardcoded Master Password
Sitting in plain text inside the frontend bundle was a hardcoded master password . Not a hash, not a token reference, but the literal password string, baked directly into the client-side JavaScript that gets shipped to every visitor's browser.
The logic around it was worse than the leak itself. When this master password was entered into the login form, the app automatically filled the OTP field and bypassed the normal authentication flow entirely . There was no second factor to clear and no server-side check to satisfy. Entering the magic string was enough.
To log in as a specific examiner, all an attacker needs is:
A target's user ID and school code , both of which are publicly obtainable.
The master password , sitting in a JS file anyone can download.
With those, I was able to log in as an examiner (bypassing the OTP/2FA flow totally) and reach the evaluation dashboard, where I could view and edit marks.
Vulnerability 2: OTP Validation Done Entirely Client-Side
The OTP step turned out to be pure theatre. When you trigger authentication, the server sends the OTP back inside the auth response , and the JavaScript running in your browser compares what you typed against that value locally before letting you through.
Think about what that means. The secret you're supposed to prove you received is handed straight to your browser, and the browser grades its own test. Anyone watching the network tab can just read the OTP out of the response. And because the comparison happens in client-side code, you can skip the form altogether and simply tell the app the check passed.
A security control...