BTS of CBSE's Infra Meltdown.

I have left a storage bucket open before. I caught it myself, which is the only reason I get to say it out loud. But open is open. It’s never some dramatic act of negligence. It’s one setting flipped the wrong way, one policy nobody reviewed, and suddenly anything with the URL can read everything inside.

In the last post I argued the exam itself should go. This one is narrower, and more uncomfortable. It’s about the software underneath the exam, and why the meltdown keeps happening.

Key Takeaways

• A 19-year-old researcher found scanned Class 12 answer sheets and question papers in an open AWS S3 bucket. CBSE first denied it, then admitted “vulnerabilities” on May 31 (The Quint).
• CBSE called the result-portal load a “barrage of cyberattacks.” Its own headline number, 1.5 million hits in two minutes, is about 12,000 requests a second, or roughly 75,000 page loads: about 4% of the 16.9 lakh students who sat the exam.
• Over four lakh students paid ₹100 to view their own answer sheets and ₹25 to re-check a question, many getting back blurred or half-missing scans (Deccan Herald).
• The marking contract went to a Hyderabad vendor that underbid TCS, with roughly 66 days before a nationwide rollout. The teachers testing it asked for another year (The Week).

The open bucket

The trigger was a 19-year-old researcher, Nisarga Adhikary, who found an unsecured AWS S3 bucket exposing scanned Class 12 answer sheets and question papers. Students had been posting their own scanned sheets online too, some of them incomplete. CBSE first denied the issue, then admitted vulnerabilities on May 31 and thanked “alert citizens and ethical hackers.”

This wasn’t bad luck, and it wasn’t just a bad vendor. It’s what monolithic, vendor-led government IT produces when everything that should be fundamental gets treated as an afterthought.

One misconfigured flag. One open bucket. Four lakh students applying to see their own scans.

A public bucket is a data-exposure event even when nobody “hacks” anything. The Indian precedents are not subtle. vpnMentor reported a misconfigured S3 bucket exposing roughly 409 GB and 7.26 million Aadhaar-linked records on BHIM, which NPCI denied (vpnMentor). In the 2025 NACH exposure, UpGuard found bank-mandate PDFs left publicly readable (UpGuard). Same root cause, every time: storage that was one toggle away from public, and one tired operator who flipped it.

What actually happened

That was the leak. The meltdown is the other half of the story.

The marking ran on a new On-Screen Marking system, served through a portal called OnMark and built by a Hyderabad vendor, Coempt EduTeck. 16,92,794 students sat the Class 12 exams, and results landed on May 13 at an 85.2% pass rate. Over four lakh of them reported incorrect marks and paid to review their own answer sheets. A lot got back broken pages, blurred scans, and sheets that were only half there.

Then came the verification portal, the one where you formally contest a mark. It was promised for May 29, slipped to June 1 “for a glitch-free process,” failed to open on June 1 anyway, and finally went live on June 2, running until midnight on June 6, at ₹100 to see an answer book and ₹25 to re-check a single question.

When the complaints peaked, cyber experts “from across various arms of government as well as the IITs” had been deployed. The vulnerabilities, CBSE said, were “contained.”

Then the portal, CBSE’s @cbseindia29 account said, had survived a “barrage of cyberattacks.” The numbers it gave: 8,000+ concurrent users, 16,000+ submissions by 3 p.m., a denial-of-service attempt of 1.5 million hits in two minutes, and over a lakh “unauthorised file access” attempts.

Those last two are the ones worth slowing down on.

What the numbers actually say

1.5 million hits in two minutes sounds like a siege. It isn’t.

Do the maths. That’s about 12,000 requests a second. And a single modern web page fires twenty or more requests on its own: the HTML, the stylesheet, the scripts, the fonts, every image, every background call. So 1.5 million hits is closer to 75,000 actual page loads, which works out to about 4% of the 16.9 lakh students who sat the Class 12 exams, in a two-minute window, on the one morning every single one of them was told to go and check their result.

And that’s before anyone refreshed. Before a parent opened the same link on their own phone, before a sibling sat down at the same laptop, before a friend tried to pull up a result alongside their own.

The “over a lakh unauthorised file access attempts” works the same way. On a portal whose entire purpose is letting students open their own files, a mistyped roll number and a retried login both look like “unauthorised access” in a log. That isn’t an intrusion. That’s a queue.

I can’t prove there was no attack, and I won’t pretend otherwise. Only CBSE has the server logs. But the simplest explanation, the one that needs no villain, fits every public figure they gave: this was demand, the single most predictable spike in the entire school calendar.

“We were attacked” is just a very convenient thing to say, because it quietly turns an architecture problem into a victim story.

The deeper root cause is procurement. Government IT is built one project, one vendor, one monolithic RFP at a time. Each system reinvents identity, payments, storage, and notifications. Each has its own undocumented config. Each is a fresh attack surface. That contract shape deserves its own post, and it gets one later in this series.

Three failures, none of them unique

Strip away the fuss and three plain failures remain. None of them are unique to CBSE.

Storage misconfiguration. Publicly readable buckets expose sensitive data, and it’s the single most common cause of large public data leaks. BHIM, NACH, and now CBSE are the same mistake wearing different logos.

Peak-event fragility. Result and re-evaluation systems face enormous, predictable, spiky load. A monolith couples that spike to everything else, including payments, notifications, dashboards, and verification flows, so one surge degrades the whole system at once.

Bolt-on security and usability. The experts arrive after the breach. Accessibility and reliability get discovered through student complaints, not designed in. The vendor that underbid TCS got roughly 66 days before a nationwide rollout; the teachers testing it asked for another year. Security and real load testing were supposed to live in that missing year. They got cut instead.

Three patterns. Same machine.

This is the exams piece again, failing in the software layer instead of the assessment layer.

Attacked or not, it was built to fall over

Two stories broke this exam season. One was a leak. The other was a software meltdown. We filed them as separate scandals. They aren’t. They’re the same machine, one layer down.

Nobody had to attack that portal for it to fail. The bucket was open because someone left it open. The portal buckled because a few million people showed up at once, which on results day is not an attack. It is the entire job.

That is not an incident you patch. It is an architecture you replace.

So was it attacked? Maybe. I can’t see the logs, and neither can you. But that question is a distraction, and I suspect that is exactly why it is the one we were handed. Attack or no attack, the failure was wired in long before results day.

It was built to fall over.

Frequently asked questions

What was the CBSE OSM data leak? Researcher Nisarga Adhikary found an unsecured AWS S3 bucket exposing scanned Class 12 answer sheets and question papers. Students had also posted their own scans online. CBSE first denied any issue, then on May 31 admitted vulnerabilities and thanked “alert citizens and ethical hackers” (The Quint).

Was CBSE’s result portal actually hit by a cyberattack? CBSE said it survived 1.5 million hits in two minutes. That’s about 12,000 requests a second, and a single web page fires 20+ requests, so it works out to roughly 75,000 page loads, around 4% of the 16.9 lakh students, on results day. The simplest explanation is demand, not an attack.

How much did students pay to see their own answer sheets? ₹100 to view an answer book and ₹25 to re-check a single question. The verification portal was promised for May 29, slipped to June 2, and ran to June 6. Over four lakh students applied; many got back blurred pages and half-evaluated sheets (Deccan Herald).

Who built the CBSE On-Screen Marking system? The marking ran on a new On-Screen Marking system served through a portal called OnMark, built by Hyderabad vendor Coempt EduTeck. It underbid TCS and got roughly 66 days before a nationwide rollout; the teachers testing it asked for another year (The Week).

Why does this keep happening to Indian government IT? Procurement. Each system is built one project, one vendor, one monolithic RFP at a time, reinventing identity, payments, storage, and notifications, each with its own undocumented config and fresh attack surface. The same misconfigured-bucket pattern hit BHIM and NACH too (UpGuard).

Sources and further reading - CBSE On-Screen Marking controversy (The Week) · Deccan Herald scanned-answer-sheet figures · Researcher report of the open S3 bucket (The Quint) · BHIM/vpnMentor exposure · NACH/UpGuard exposure · CBSE @cbseindia29 statements

What’s next?

This is part of a series on why India’s government software keeps falling over, and how I’d build it so it doesn’t:

• Stop Fixing India’s Exams — why you can’t patch a high-stakes exam into honesty, and the continuous competency profile that replaces it
• BTS of CBSE’s Infra Meltdown (you are here) — why the result-day “cyberattack” was almost certainly just demand, and why the portal was built to fall over
• How I’d Actually Build Government Software That Doesn’t Fall Over — a federated core, HTML-first frontends, and storage you can’t make public
• GitHub for Government Work — trading the multi-year, single-vendor RFP for an open commons paid per merged pull request
• Assume the Endpoint Is Hostile (coming soon) — locking down the lakhs of devices that reach the core, with a closed system on open foundations

One machine, five layers: the exam, the meltdown, the architecture, the procurement, and the endpoint.