e-Sushrut HMIS: auth bypass, plaintext OTPs, hardcoded AES keys
TL;DR - Six vulnerabilities in C-DAC's e-Sushrut HMIS: login state is controlled by client-side response parameters (trivially tampered), OTPs come back in plaintext API responses, patient records are reachable via IDOR, and AES keys are hardcoded in client-side JavaScript. CERT-In rates the bundle Critical.
What happened
e-Sushrut is C-DAC's Hospital Management Information System, deployed in healthcare organisations to manage patient records and hospital workflows. On 28 April 2026, CERT-In published vulnerability note CIVN-2026-0207 describing six issues - two of which require no authentication at all.
The auth bypass is the most immediate risk. If your login flow trusts client-visible response parameters to determine authentication state, any attacker who can observe or intercept a response can flip that state. Pair that with OTPs returned in plaintext by the same API layer, and account takeover becomes straightforward - no brute force, no crypto attack, just read the response.
The full breakdown:
| CVE | Issue | Access required | Impact |
|---|---|---|---|
CVE-2026-42513 | Auth bypass via client-side response parameter manipulation | Remote, unauthenticated | Bypass authentication; gain unauthorised account access |
CVE-2026-42514 | OTPs exposed in plaintext in API responses | Remote, unauthenticated | Impersonation; unauthorised account access |
CVE-2026-42515 | IDOR via API request URL parameter manipulation | Authenticated | Unauthorised access to sensitive patient records |
CVE-2026-42516 | Broken access control via encoded URL parameter manipulation | Authenticated | Unauthorised access to patient accounts |
CVE-2026-42517 | Cryptographic failure: Base64 encoding used in place of real protection | Authenticated | Decode and manipulate parameters; access sensitive data |
CVE-2026-42518 | Sensitive data and hardcoded AES keys in client-side JavaScript | Unauthenticated | Extract keys; break all crypto protections that depend on them |
The hardcoded AES keys (CVE-2026-42518) are worth calling out separately. If any other flow in the system encrypts data with those keys, an unauthenticated attacker who reads the JavaScript has already broken that encryption - before touching the auth bypass or OTP issues.
Who is impacted
- Healthcare organisations running
e-SushrutHMIS. - Deployments where
e-SushrutAPIs are reachable from the internet or an untrusted WAN - the two unauthenticated CVEs (CVE-2026-42513,CVE-2026-42518) require no prior foothold. - Any environment where patient data integrity and account security are mission-critical, which describes every HMIS deployment by default.
What to do now
- Contact C-DAC for the patched version. CERT-In's remediation guidance is direct:
"Contact C-DAC for upgrading e-Sushrut HMIS to latest version"
- While you wait for the upgrade, triage your exposure:
- Map where
e-Sushrutis reachable from untrusted networks - check VPN boundaries, reverse proxies, and WAF rules. - Identify any API clients or integrations consuming OTP-related responses and treat that data as potentially observed.
- Map where
- Add detection while the upgrade is in progress:
- Review access logs for unusual authentication patterns and OTP validation activity.
- Look for signs of URL parameter manipulation against patient record and account endpoints.
- Assume potential exposure until scoped otherwise:
- Verify that OTPs and client-side crypto material are not reachable by unauthenticated users in your specific deployment configuration.
- Rotate credentials and any keys plausibly exposed through the affected flows, based on your internal scoping.
Related
Research
Guides
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.