CloudClassroom PHP EUVD-2026-109578

The specific trigger is the fname argument submitted through addnewstudent.php, which is stored and later rendered without output encoding (stored XSS). Exploitation requires (1) the ability to reach and submit the add-student form, and (2) a victim subsequently viewing the page that renders the stored fname value (UI:P / user interaction), at which point the script runs in the victim's browser. The CVSS vector marks PR:N (unauthenticated), but because addnewstudent.php is an operator/add-record function it may in practice require an authenticated session - this is not confirmed by the available sources and should be verified. Limiting factors: impact is low integrity only, a victim must view the stored content for the payload to fire, and the product is an obscure rolling-release project with no vendor patch; the only remediation path is the vendor, who has not responded.

This is a medium-severity stored cross-site scripting issue (CVSS 4.0 base 5.3) whose real-world urgency is modest. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:P) describes a remotely reachable, low-complexity flaw that per the vector requires no privileges but does require passive user interaction (UI:P), and the impact is limited to low integrity on the vulnerable system (VI:N confidentiality, VI:L integrity, VA:N) with no scope change. There is no EPSS score in the input, the CVE is not listed in CISA KEV, and the PoC is a reference only that is not verified as working exploit code - so none of the three strong exploitation signals (KEV, verified exploit, high EPSS) are present. The vuln.today decision label is 'this_month', i.e. a routine remediation cadence rather than act_now/emergency. One conflict to verify: the CVSS vector sets PR:N (unauthenticated), yet the sink is addnewstudent.php - an add-student function that in most deployments sits behind an operator/admin login, which would imply PR:L; the available sources do not confirm whether this page is reachable unauthenticated, so the true privilege requirement should be verified against the application. Overall this reads as a genuine but low-priority web bug in an obscure product, not a high-CVSS-but-overrated critical.

An attacker who can reach the add-student form submits a new student whose fname field contains a JavaScript payload, which the application stores without sanitization. When an administrator or other user later views the stored student data, the script executes in that victim's browser, enabling session/cookie theft or actions in the victim's context. A public PoC reference exists but is not verified as working exploit code.