EUVD-2026-26204Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Keys and data are in publicly served client-side JS, so unauthenticated network read with no interaction (AV:N/AC:L/PR:N/UI:N); impact is confidentiality-only (C:H, I:N, A:N).
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
3DescriptionCVE.org
This vulnerability exists in e-Sushrut due to disclosure of sensitive information and hardcoded AES encryption keys in client-side JavaScript. An unauthenticated remote attacker could exploit this vulnerability by accessing the client-side code to extract sensitive information and cryptographic keys.
Successful exploitation of this vulnerability could lead to exposure of sensitive data and compromise of cryptographic protections on the targeted system.
AnalysisAI
Sensitive information disclosure in e-Sushrut (Hospital Management Information System / HMIS) lets an unauthenticated remote attacker read client-side JavaScript to harvest exposed sensitive data and hardcoded AES encryption keys, undermining the application's cryptographic protections. The flaw was reported by CERT-In and carries a CVSS 4.0 score of 8.7 (High); no public exploit identified at time of analysis. EPSS is very low (0.06%, 18th percentile) and CISA SSVC rates exploitation as 'none' with only partial technical impact, indicating no observed exploitation despite the high severity rating.
Technical ContextAI
e-Sushrut is a hospital management information system (developed under India's C-DAC ecosystem and widely used across public-sector Indian healthcare institutions). The root cause is CWE-321 (Use of Hard-coded Cryptographic Key): AES keys are embedded directly in client-side JavaScript delivered to the browser. Because any client can fetch and read this JavaScript, the 'secret' key is effectively public. Once an attacker knows the static AES key, any data encrypted with it - whether in transit, in local storage, or in request/response payloads - can be decrypted, and any client-side encryption relying on that key provides no real confidentiality. The additional disclosure of sensitive information in the same client-side code compounds the exposure.
RemediationAI
No vendor-released patch version is identified in the available data; consult the CERT-In advisory CIVN-2026-0207 (https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01&VLCODE=CIVN-2026-0207) for vendor guidance and any released update. The core architectural fix is to stop performing security-relevant cryptography with keys shipped to the client: remove all hardcoded AES keys and sensitive data from client-side JavaScript, move encryption/decryption and key custody to the server side, and rotate any exposed keys since they must be treated as compromised. As compensating controls until an official update is deployed, minify/strip secrets from front-end bundles, terminate confidentiality with TLS on the server rather than client-side AES, restrict application exposure to trusted networks or VPN (trade-off: reduces legitimate remote access for clinical staff), and audit whether any data previously 'protected' by the static key must be re-secured. Note that simply obfuscating the JavaScript is not a fix - obfuscation delays but does not prevent key extraction.
Same weakness CWE-321 – Use of Hard-coded Cryptographic Key
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today