CUET NTA: Security Architecture Analysis
Responsible Disclosure Notice: This post describes architectural weaknesses and their potential impact. No exploit details, API endpoints, hardcoded secrets, or reproduction steps are included. Findings have been reported through appropriate channels.
| Field | Detail |
|---|---|
| Application | CUET NTA (Common University Entrance Test) |
| Ministry/Body | MoE (Ministry of Education) |
| Data Category | Education Records |
| Sensitivity | 🟠 High |
| Platform | Web (WordPress/S3WaaS + ASP.NET/NIC ExamSys) |
| Infrastructure | cuet.nta.nic.in (S3WaaS/Varnish) + examinationservices.nic.in (ASP.NET) |
| Analysis Date | 2026-06-15 |
| Critical Findings | 1 |
| High Findings | 3 |
| Medium Findings | 2 |
| Low Findings | 1 |
Summary
This analysis examined the client-side architecture of CUET NTA, operated by the Ministry of Education through the National Testing Agency (NTA), which handles education records — classified as high sensitivity under our data risk framework. CUET is the common entrance exam for admission to central universities across India, processing data for millions of undergraduate applicants annually.
The portal runs on a dual-stack architecture: a WordPress-based information site (S3WaaS theme on cuet.nta.nic.in) and an ASP.NET exam application system on examinationservices.nic.in. The analysis identified 7 categories of architectural concerns, with 1 critical, 3 high, 2 medium, and 1 low severity findings.
Architecture Overview
The CUET NTA ecosystem consists of:
- Information portal (
cuet.nta.nic.in) — WordPress site using the S3WaaS/SDO theme with Bhashini translation, Parichay SSO plugin, and Firebase Cloud Messaging integration - Exam application portal (
examinationservices.nic.in/ExamSysCUETUG26/) — ASP.NET WebForms application built by NIC for registration, login, and form submission - Admit card service (
cnr.nic.in/AdmitCard/AcCuetUG/) — separate service for hall ticket download
Risk Factors
- Client-side password hashing salt embedded in page source — known to anyone who views the login page
- Double SHA-256 with static salt used as the only password protection before transmission — vulnerable to rainbow table and dictionary attacks
- No multi-factor authentication for candidate login — mobile number alone is the recovery mechanism
- WordPress REST API initially exposed (now disabled) — indicates prior misconfiguration
- Bhashini TTS uses base64-to-blob conversion with AJAX callback patterns that expose server-side endpoint structure
- Session management relies solely on ASP.NET session cookies and client-side history manipulation
- jQuery 3.5.1 and Bootstrap 3.3.7 on the exam portal — known vulnerabilities in older versions
Impact Scenarios
Scenario: Credential Stuffing with Client-Side Salt
The CUET exam portal hashes passwords client-side using SHA-256 applied twice — once on the raw password, then again on the hash concatenated with a static salt that is embedded directly in the HTML source code rendered to every visitor. This means the “encryption” is entirely transparent: the algorithm and salt are shipped to every browser that loads the login page. An attacker with a breached password database from another platform can directly compute the CUET-specific hash for any known password and attempt login at scale, since the transformation is deterministic and requires no server-side knowledge.
This is particularly dangerous because CUET candidates are typically young adults (17-19 years) who frequently reuse passwords across platforms. Any prior credential leak from social media, gaming, or other educational platforms becomes a direct vector for CUET account compromise.
Scenario: Account Takeover via Mobile Recycling
CUET uses only an application number and password for login, with password recovery likely tied to the registered mobile number. When a mobile number is reassigned by a telecom operator (common in India’s prepaid-heavy market), the new owner can receive password reset OTPs for accounts registered under the previous owner. For a university entrance exam, this could mean:
- Unauthorized modification of subject choices or exam centre preferences
- Changes to category or PwD claims that affect merit calculations
- Access to the candidate’s personal information including address, photo, and educational details
Scenario: Automated Exam Centre Mapping
Without robust rate limiting and CAPTCHA on the candidate login, an attacker could programmatically attempt logins across sequential application number ranges to determine which numbers are assigned, what exam centres were allocated, and build a demographic map of registrations. This intelligence could be used for targeted coaching scams, fake admit card services, or social engineering against specific candidates.
Scenario: WordPress Plugin Attack Surface
The information portal uses multiple WordPress plugins including Parichay SSO (single sign-on from NIC’s identity platform), Bhashini translation, and JS Composer (WPBakery). WordPress plugins are the most common attack vector for government websites in India. A vulnerability in any of these plugins could allow:
- Defacement of exam notifications and important dates
- Injection of malicious JavaScript into the information portal
- Potential privilege escalation if the Parichay SSO plugin has flaws
- Redirects from legitimate download links (admit cards, information bulletins) to phishing pages
Findings Overview
| Severity | Category | Details |
|---|---|---|
| 🔴 CRITICAL | Hardcoded Salt in Client-Side Password Hashing | Password hashing salt embedded in login page HTML — visible to every visitor |
| 🟠 HIGH | Weak Password Protection (Double SHA-256) | Client-side SHA-256 + salt is deterministic and rainbow-table vulnerable |
| 🟠 HIGH | No Multi-Factor Authentication | Login requires only application number + password; no secondary verification |
| 🟠 HIGH | Stale Dependencies (jQuery 3.5.1, Bootstrap 3.3.7) | Known vulnerabilities in outdated client-side libraries |
| 🟡 MEDIUM | WordPress Plugin Attack Surface | Parichay SSO, Bhashini TTS, JS Composer plugins increase attack surface |
| 🟡 MEDIUM | Session Management Weaknesses | Client-side history manipulation, no duplicate session protection visible |
| 🔵 LOW | Previously Exposed REST API | WordPress REST API was enabled then disabled — indicates prior misconfiguration |
Specific details, values, and code references omitted per responsible disclosure practices.
Why This Matters
CUET is the gateway to India’s central universities. In 2025, over 13 lakh (1.3 million) candidates appeared for the exam. The data held in the CUET system includes:
- Full name, date of birth, photograph, and signature
- Category, PwD status, and reservation claims
- Academic records and subject choices
- Exam centre allocation and admit card data
- Parent/guardian information and contact details
This is precisely the kind of sensitive personal data that India’s Digital Personal Data Protection Act 2023 classifies as requiring the highest protection standards, particularly for minors who form the majority of the user base.
The NTA has faced repeated controversy around exam integrity — from the NEET-UG 2024 paper leak to the UGC-NET 2024 cancellation. Security of the digital infrastructure that supports these exams is not just a data protection issue; it is a matter of public trust in India’s examination system.
Responsible Disclosure Timeline
| Date | Action |
|---|---|
| 2026-06-15 | Blog post published (impact only, no exploit details) |
| Pending | CERT-In report filed |
| Pending | NTA CISO / NIC technical team contacted directly |
| Pending | MoE IT division notified |
| 2026-09-13 | Full public disclosure deadline (90 days) |
Recommendations
Immediate (0-7 days)
- Remove the static salt from client-side code — Move password hashing entirely server-side; use server-generated per-session salts
- Implement server-side bcrypt/Argon2 — Replace the double SHA-256 scheme with a modern adaptive hashing algorithm
- Add CAPTCHA or rate limiting on the candidate login endpoint to prevent automated attempts
Short-term (1-4 weeks)
- Implement multi-factor authentication for candidate login — OTP to registered mobile + email as secondary verification
- Update client-side libraries — jQuery and Bootstrap are outdated; upgrade to current versions
- Harden WordPress plugins — Audit Parichay SSO, Bhashini, and JS Composer for known CVEs; remove any that are not essential
- Add security headers to the ASP.NET exam portal (Content-Security-Policy, Permissions-Policy)
Structural (1-3 months)
- Adopt a public Vulnerability Disclosure Program (VDP) — NTA currently has no way for researchers to report security issues
- Penetration testing before each exam cycle — the registration and login systems should be professionally audited
- Implement continuous security monitoring — Real-time alerts for brute force attempts, unusual login patterns, and plugin vulnerabilities
- Align with DPDP Act 2023 — CUET processes data of minors; explicit verifiable consent and data minimization requirements apply
- Move away from ASP.NET WebForms — The ViewState-based architecture is inherently vulnerable to client-side tampering
This analysis is part of an ongoing audit of Indian government digital services. See the project page for other analyses.