CBSE - How a 19-Year-Old Uncovered Critical Security Weaknesses in a National Examination Portal

Introduction

In May 2026, public reports emerged describing a series of critical vulnerabilities affecting a national examination marking platform used to evaluate student answer sheets. According to the disclosures, the issues could be chained together to enable complete examiner account compromise using nothing more than a web browser and built-in developer tools.

The case attracted significant attention because of both the severity of the reported vulnerabilities and the simplicity of the techniques allegedly required to exploit them.

What Was Reportedly Discovered?

Publicly available information described six vulnerabilities, including several categorized as critical or high severity.

The reported issues included:

→ Hardcoded credentials exposed within client-side JavaScript

→ Weaknesses in OTP validation logic

→ Insecure Direct Object Reference (IDOR) vulnerabilities

→ Insufficient server-side authorization checks

→ Weak password reset controls

→ Excessive trust in client-side session data

Individually, each issue posed a security risk. Together, they reportedly created a complete account-takeover pathway.

Understanding the Vulnerability [ Technical ]

Estimated CVSS Severity Scores

• Master Password Hardcoding: 9.6 (Critical)
• Client-Side OTP Bypass: 9.2 (Critical)
• Insecure Direct Object Reference (IDOR): 9.0 (Critical)
• Password Reset Flaw: 8.5 (High)
• Weak Route Protection: 7.8 (High)

—————————————————————————————————

1. Hardcoded Credentials in Client-Side Code

Reports indicated that authentication-related secrets were embedded within JavaScript delivered directly to users' browsers.

Any information accessible to a browser should be considered accessible to an attacker. Credentials, API keys, and security decisions should never be trusted solely to client-side code.

2. Client-Side OTP Validation

The reported findings suggested that portions of the multi-factor authentication workflow relied on browser-executed logic.

When authentication decisions are enforced on the client instead of the server, users can potentially modify or bypass those controls using standard browser developer tools.

3. Broken Access Control and IDOR

Further analysis reportedly revealed that account identifiers stored within browser sessions could be manipulated to access information associated with other users.

This is a classic example of an Insecure Direct Object Reference (IDOR), one of the most common authorization failures observed in modern web applications.

4. Weak Account Recovery Controls

Public disclosures also described password reset functionality that lacked sufficient verification safeguards.

Account recovery mechanisms must be protected with the same rigor as primary authentication workflows because they ultimately control account ownership.

5. Missing Server-Side Authorization

Reports indicated that backend endpoints failed to consistently validate whether a user was authorized to perform sensitive actions.

Authorization checks should never depend on client-side controls and must be enforced for every request reaching the server.

The Root Cause: Trusting the Client

Perhaps the most important lesson from the incident is that the reported vulnerabilities stemmed from a common architectural mistake: trusting data and security decisions originating from the browser.

Client-side code can improve user experience, but it cannot serve as a security boundary.

Authentication, authorization, privilege validation, and sensitive business logic should always be enforced on the server.

Disclosure and Public Response

According to public reports, the researcher initially disclosed the findings through responsible channels before later publishing details after an extended waiting period.

The disclosures subsequently attracted media attention and prompted additional review and discussion regarding the security of systems involved in examination processing.

As with many public vulnerability disclosures, some aspects of the findings became the subject of debate between stakeholders and the researcher.

Key Security Lessons

Organizations responsible for critical public-facing applications should:

• Never store sensitive credentials in client-side code
• Enforce authentication decisions on the server
• Validate authorization on every request
• Protect password reset workflows with strong verification
• Conduct regular secure code reviews
• Establish clear vulnerability disclosure processes
• Respond rapidly to reports involving authentication and access control

Final Thoughts

Whether viewed as a technical failure, a governance challenge, or both, the incident serves as a reminder that seemingly simple mistakes can have outsized consequences when they occur in systems handling sensitive public data.

The reported findings reinforce a fundamental security principle: browsers are part of the attack surface, not part of the trust boundary.