CloudClassroom PHP Project CVE-2026-100313

Exploitation requires the attacker to induce a user to open a crafted request to updatequery.php with a malicious queryx parameter value (UI:P - user interaction required); the payload is reflected without sanitization and runs in the victim's browser context. No authentication is required to craft the link (PR:N), but successful impact depends on a victim with an active/valuable session following the link. Realistic risk is limited by the required user interaction, the client-side-only impact (no server compromise), and the product's tiny, non-enterprise deployment base.

This is a genuine-but-low-priority issue. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:P) shows a network-reachable, low-complexity flaw needing no authentication but requiring victim interaction (UI:P), with only low integrity impact (VI:L) and no confidentiality or availability impact per the vendor scoring - consistent with a reflected cross-site scripting bug where the payload executes in a tricked victim's browser rather than compromising the server. Public exploit code exists (VulDB-referenced GitHub advisory by vinniboy021-blip), and the CVSS carries E:P (Proof-of-Concept exploit maturity), but this signals code availability, not active exploitation. There is NO CISA KEV listing and NO EPSS score provided, so there is no evidence of widespread or automated exploitation. The dominant risk-limiting factor is the product itself: an obscure student/hobby PHP project distributed only as a rolling GitHub repo with no enterprise footprint. Net: a real, publicly-exploitable XSS, but low real-world priority. Note a minor signal conflict - the vendor scores confidentiality as VC:N, yet reflected XSS typically enables session/cookie theft, so a C:L rating is defensible; verify actual sink behavior against the POC.

An attacker crafts a URL for updatequery.php containing a malicious script in the queryx parameter and lures an authenticated user (e.g., via a phishing link) into opening it. The unsanitized value is reflected into the response, executing attacker JavaScript in the victim's browser session to steal cookies, perform actions as the victim, or deface the page. A public proof-of-concept for this exact reflected XSS is available on GitHub.