From Disclosure to National Crisis: What the CBSE OSM Fiasco Reveals About India's API Security Blind Spot

A Crisis That Was Predicted in Public

Three months ago, a Class 12 student named Nisarga Adhikary privately reported a serious vulnerability he had discovered in the CBSE On-Screen Marking (OSM) portal. With the issues still largely unaddressed, he published his findings publicly — outlining how the portal could be compromised end-to-end using nothing more than a browser, a JavaScript file, and DevTools. He cautioned that the integrity of board exam evaluations for millions of students could be at risk.

This week, the prediction came true. In a span of seventy-two hours:

• Students reported being charged anywhere from ₹1 to over ₹69,000 for a single revaluation request as the CBSE portal's payment gateway malfunctioned
• One Class 12 student shared screenshots showing that the "Physics answer sheet" linked to his roll number contained handwriting and responses that were not his
• Another student reported a similar mismatch in his Chemistry answer sheet
• CBSE acknowledged the discrepancies, issued an apology, and stated revised marks would be issued
• The Union Education Minister tasked IIT Madras to conduct an emergency platform audit

Step back from the noise and look at the architecture behind these failures. Every symptom dominating the headlines had already been described, in technical detail, months earlier. The question is no longer whether the vulnerabilities were real — it's what they reveal about how India is designing and operating critical citizen-facing APIs.

Two Stories, One Architecture

Story A — The Technical Vulnerabilities (Feb 2026)

Story B — The Public Fiasco (May 21–26, 2026)

• Payment gateway chaos: students charged ₹1 to ₹69,000+ for the same revaluation request
• Mismatched answer sheets: Physics and Chemistry scripts with different handwriting mapped to wrong student IDs — confirmed by CBSE
• Portal instability: crashes, frozen pages, and "service unavailable" errors throughout the revaluation window
• Ministerial escalation: IIT Madras directed to audit authentication, payment gateway, and infrastructure

Full OWASP Mapping

The Disclosed Vulnerabilities

The Operational Fiasco

Why Traditional Defences Would Not Have Helped

If you put a typical WAF or API gateway in front of the OSM portal, would either have prevented what we witnessed? Walk through it:

# What the CBSE attack looks like on the wire
POST /api/ChangePassword
Authorization: Bearer <valid-looking session token>
Content-Type: application/json

{"ValuatorID":"EXAMINER_42","pin_NewPassword":"NewPass123!"}

# WAF assessment:
→ No SQLi pattern detected
→ No XSS payload present
→ No command injection found
→ Schema: valid JSON
→ DECISION: ALLOW

# Reality:
→ No old_password field sent — server accepts anyway
→ ValuatorID belongs to a different examiner
→ Password reset completes — full account takeover
→ WAF saw nothing suspicious. Zero alerts fired.

The OSM attacks succeed because the server-side runtime never has ground truth about who the caller actually is. No amount of perimeter inspection fixes that. You need visibility inside the application runtime — where the syscall, the process, the real session identity, and the API operation all meet.

How ziriz.ai Would Have Changed the Outcome

ziriz.ai operates inside the host kernel — observing every API call as it leaves or enters the application process, with full server-side context attached. Here's how each crisis layer would have been handled differently:

Five Lessons for India's Public-Sector and Enterprise APIs

This Was Not a Surprise. The Next One Doesn't Have To Be Either.

The full sequence — a responsible disclosure in February, unpatched vulnerabilities through April, payment chaos and misbound answer sheets in May, viral student outrage, and ministerial intervention bringing in IIT Madras — was avoidable. Every layer of the failure maps to a well-understood OWASP category that India's security community has known about for years.

To anyone in government, BFSI, healthcare, education, or any sector running APIs that handle the trust of millions of citizens: now is the moment to ask whether your defences sit outside your runtime or inside it. The CBSE OSM crisis is showing us, in real time, what happens when they sit outside.

ziriz.ai was built for this exact moment. Kernel-native. Runtime-aware. Identity-anchored to the server, not the browser. We see the API the way the operating system sees it — with full context, in real time — and we act before the damage compounds.