JEE Advanced 2026: When Cloud Misconfiguration Exposes 1.8 Lakh Exam Records

One Cloud Misconfiguration, 1.8 Lakh Students

On June 1, 2026 — the same day IIT Roorkee declared JEE Advanced results — a 16-year-old researcher named Rylen Anil filed a responsible disclosure report with the institute. He had found that a cloud storage endpoint tied to the JEE Advanced results portal was publicly accessible without authentication.

What sat inside: the personal and examination data of approximately 1,79,600 candidates. Names, dates of birth, mobile phone numbers, result records, and admit card PDF files, all readable by anyone with the URL.

IIT Roorkee confirmed the incident. Its statement noted that the data was stored in read-only format, preventing tampering. Engineers fixed the misconfiguration and closed the exposure.

The story was reported, acknowledged, and resolved within days. But the episode carries lessons that extend far beyond one portal and one institution — because the underlying problem is structural, not accidental.

How a Cloud Misconfiguration Happens

AWS S3 buckets, Azure Blob containers, and Google Cloud Storage buckets are private by default. They become public through configuration choices: access control lists set to "public-read," bucket policies that inadvertently permit anonymous access, or pre-signed URLs that expire but are replaced with open permissions.

In high-pressure result declaration timelines — where exam systems go from zero traffic to millions of requests in minutes — the fastest path to serving data is often to set storage permissions broadly and tighten them later. "Later" sometimes does not arrive before a researcher does.

The JEE Advanced exposure did not involve malware, a phishing attack, or an external breach. It was a standard misconfiguration: a storage bucket, probably used for serving PDF admit cards and result files, was left accessible without authentication. No firewall or intrusion detection system catches this because it is not an intrusion. The data is just there, on a valid URL, readable by anyone who finds it.

Why Read-Only Does Not Mean Safe

IIT Roorkee's statement emphasised that the data could not be modified. This is important but insufficient.

A breach does not require write access. The risk from this kind of exposure is not that someone alters your marks — it is:

Identity theft at scale. Candidate names, dates of birth, and phone numbers from a high-stakes national exam are high-quality identity data. JEE Advanced candidates are typically 17 to 19 years old. Their mobile numbers and dates of birth, combined with their exam registration numbers, can be used to social-engineer telecom providers, phishing attacks, or SIM swap frauds.

Bulk harvesting. A misconfigured bucket with 1.87 lakh admit card PDFs can be indexed by a bot in minutes. The researcher found it through manual investigation; a less ethical actor could have scraped the entire dataset before the fix.

Compliance exposure. India's Digital Personal Data Protection Act 2023 (DPDP Act) designates institutions that collect and process personal data as data fiduciaries. A public cloud storage incident is a reportable data breach. The consequences include notices, investigations, and potential penalties — regardless of whether the data was modified.

The Pattern Is Not New

The JEE Advanced incident was not isolated. In May and June 2026, the CBSE On-Screen Marking controversy included allegations that Coempt Eduteck stored scanned answer sheets in a public AWS bucket. Internet Freedom Foundation wrote to CERT-In and the Ministry of Education citing the CBSE's student data being processed through third-party AI tools and potentially routed through servers outside India.

Earlier, in 2024, a researcher exposed that CBSE's internal portal had account-takeover vulnerabilities that were disclosed to CERT-In in February 2026. These vulnerabilities, separately from the storage issue, permitted complete takeover of any examiner account and alteration of marks.

Three incidents in eighteen months. Each different in mechanism. Each traceable to the same root cause: exam data being handled by systems that were not designed and tested to the security requirements of the data they carry.

What Secure Exam Data Architecture Looks Like

The problems above are not unfixable. They are the result of deploying general-purpose cloud infrastructure for a specialised, high-sensitivity use case without applying the security controls that use case requires.

Institutions managing exam data — answer sheets, result records, candidate data, examiner credentials — need an architecture built around these principles:

Storage is never public. No bucket, container, or blob store holding exam data should permit public access, full stop. Result files served to students are delivered through application layers that authenticate the request, not through direct storage URLs. This eliminates the misconfiguration risk entirely.

Data minimisation. Admit card PDFs served publicly do not need to include date of birth or mobile number. The less sensitive data appears in externally-accessible files, the lower the blast radius of any misconfiguration.

Separation of environments. Production exam data — live answer sheets, candidate records, result data — should never share storage accounts, access keys, or deployment pipelines with test environments. The CBSE ethical hacker disclosure involved a staging or test server; the risk was that its vulnerabilities mirrored production.

Access logging and alerting. A misconfigured storage bucket, once discovered by monitoring tools, should trigger an alert within minutes. Any storage resource holding exam data should have access logs reviewed for anomalous patterns — bulk downloads, access from unexpected IP ranges — in real time.

Third-party due diligence. When exam data is processed by a vendor — for scanning, OCR, on-screen marking, or result delivery — the contract must specify data residency, access controls, and breach notification timelines. The vendor's infrastructure should be audited against these requirements, not self-attested.

The Examiner Credential Problem

Beyond storage, the examiner credential attack surface deserves specific attention.

In digital evaluation systems, each examiner logs in with a unique credential to access a queue of answer scripts. If that credential is phished, guessed, or stolen through an API vulnerability, an attacker can access scripts, view candidate answers, and in poorly designed systems, modify scores.

Defences that now must be standard:

These are not novel security measures. They are basic controls that any banking or healthcare platform applies as a minimum. Exam systems handle data that determines career outcomes for millions of students annually. They need to be held to the same standard.

For Universities Planning Digital Evaluation

The JEE Advanced incident is not an argument against digital evaluation — it is an argument for doing digital evaluation properly.

Paper-based systems have their own security failures: answer sheets stolen in transit, evaluator identity fraud, centre-level tampering. The question is not digital versus paper; it is whether your digital system is designed to handle the sensitivity of the data it carries.

Before deploying any on-screen marking system, institutions should require their vendor to demonstrate:

The students sitting examinations with your institution have not consented to having their data exposed through a misconfigured bucket. They have consented, implicitly, to your institution handling it responsibly. That responsibility is not discharged by choosing the fastest-to-deploy or lowest-cost option.

Related Reading