Smart Attendance System CVE-2026-95957

Requires that the Smart Attendance System's Self-Registration feature (student_signup.php) is exposed and enabled, allowing unauthenticated users to submit the full_name field. Exploitation is unauthenticated (PR:N) and remote (AV:N) but depends on victim interaction (UI:P) - a user or administrator must render the page containing the attacker-supplied name for the script to fire. Impact is limited to the victim's browser context (script execution, potential session theft/defacement); there is no direct server compromise. The primary limiting factor beyond user interaction is the product's rarity - a niche SourceCodester hobby application with essentially no production deployment.

This is a classic low-severity cross-site scripting flaw in a hobby-grade PHP application, and the signals are internally consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P) confirms remote, unauthenticated reach against the public self-registration form, but requires passive user interaction (UI:P) and yields only limited integrity impact (VI:L) with no confidentiality or availability impact per the vendor score - hence the modest 5.3. SSVC-style reading: exploitation is Proof-of-Concept (E:P, POC public on GitHub), the technical impact is partial (single-field script injection, not system takeover), and while the injection point is trivially automatable, the payoff is limited to browser-context script execution against whoever renders the injected full_name. There is no EPSS score, no CISA KEV listing, and no evidence of active exploitation provided - only a public PoC. Net: a real but low-priority issue. It is NOT a high-CVSS-but-low-real-risk mismatch; it is genuinely low-severity, and its practical risk is further bounded by the product's near-zero enterprise footprint. Note the vendor scored VC:N/VI:L (treating XSS as integrity-only); a defender could reasonably argue VC:L as well since XSS commonly enables session/cookie theft - verify impact expectations against your deployment.

An unauthenticated attacker submits the public student self-registration form (student_signup.php) with a JavaScript payload in the full_name field, which is stored/reflected without proper output encoding. When a victim - most likely an administrator reviewing registrations or another user viewing the rendered name - loads the page, the script executes in their browser context, enabling session hijacking or UI defacement. A public proof-of-concept exists (GitHub, Jack-MRJ), lowering the barrier to exploitation.