student-management-system EUVD-2026-35006

Exploitation requires a valid low-privilege account in the student management system (PR:L per CVSS 4.0 vector) - unauthenticated external exploitation is not indicated by available data. The vulnerable code path is specifically the getStatus function within the Certificate Verification Endpoint; only requests to that endpoint with a manipulable nic argument trigger the flaw. No non-default configuration is required beyond a running application instance with the Certificate Verification feature accessible to authenticated users. Exploitation is limited by the need for at least one valid credential; environments where student/staff login is tightly controlled or where the Certificate Verification Endpoint is network-restricted have meaningfully reduced exposure.

The CVSS 4.0 score of 2.1 is unusually low for a network-accessible SQL injection and warrants explanation. The vector AV:N/AC:L/AT:N establishes trivial remote reachability with no special conditions, but PR:L (low privileges required) confirms that unauthenticated exploitation is not indicated - a valid account is needed. The impact triad VC:L/VI:L/VA:L and the absence of any subsequent-system impact (SC:N/SI:N/SA:N) reflect that the database likely contains only student and grade records with limited downstream systemic consequence. Counterweighing the low score: the E:P supplemental metric confirms a public proof-of-concept exists, substantially lowering attacker skill requirements. There is no CISA KEV listing and no EPSS data provided in available intelligence, so widespread automated exploitation cannot be confirmed. The realistic priority is moderate for any internet-facing deployment: the PoC is accessible, the attack is low-complexity once authenticated, and no vendor patch is available. For internal-only academic deployments with restricted login access, real-world risk is meaningfully lower.

A student or staff member with a valid low-privilege account submits a crafted value for the nic parameter to the Certificate Verification Endpoint - for example, appending a SQL fragment like ' OR '1'='1 or a UNION-based payload - which the getStatus function passes unsanitized to the database query. A publicly available proof-of-concept linked in GitHub issue #2 demonstrates the technique, enabling an attacker with basic SQL injection knowledge to enumerate, extract, or modify records in the underlying database.