CVE-2026-10228: XSS Vulnerability in raisulislamg4 Student Management System

Technical summary

The vulnerability is a reflected cross-site scripting (XSS) flaw classified as CWE-79 with secondary characteristics of CWE-94 (improper control of generation of code). It exists in admission_form_check.php, a PHP script that processes the Message parameter without adequate input validation or output encoding. The attack vector is network-accessible, requires low complexity, and demands authenticated user privileges. The vulnerability does not require special user permissions to exploit, but does require the target user to interact with a crafted payload (UI:R). The affected codebase uses a rolling release model, making traditional version tracking impractical; the known vulnerable commit is identified as 310d950e09013d5133c6b9210aff9444382d16d1.

Business impact

For organizations using this student management system, the primary risk is unauthorized modification of displayed content and potential theft of session credentials or sensitive student information through browser-based attacks. Although the severity is rated LOW, the presence of a public exploit and the educational context of the application (handling student data) warrants attention. Attackers could impersonate legitimate system messages, redirect users to malicious sites, or harvest authentication tokens. Given the nature of student information systems handling personally identifiable information (PII), regulatory compliance obligations (FERPA in the US, GDPR in Europe) may be triggered if exploitation leads to unauthorized data access.

Affected systems

The raisulislamg4 student_management_system_by_php project is affected, including all commits up to and including 310d950e09013d5133c6b9210aff9444382d16d1. Because the project employs a rolling release model without discrete version releases, organizations using this codebase must determine their deployed commit hash to confirm exposure. No official vendor product versions are tracked in the vulnerability data, indicating this is an open-source project without formal commercial release management. Organizations should verify their exact deployment commit against the known vulnerable commit hash.

Exploitability

The vulnerability is exploitable remotely by authenticated users with minimal effort. Public exploit code is available, reducing the barrier to weaponization. However, the attack requires the target user to interact with a malicious payload (e.g., click a link or visit a specially crafted page), which constrains real-world exploitation scope. An attacker with valid credentials can craft a message parameter containing JavaScript, and any subsequent user viewing that message in certain contexts will execute the malicious script in their browser. The low complexity and lack of special privileges required suggest straightforward exploitation for adversaries with system access.

Remediation

The raisulislamg4 project maintainers have been notified but have not yet responded or released a fix. Organizations using this system should immediately implement input validation and output encoding in the admission_form_check.php file. Specifically, the Message parameter and any user-controlled data reflected in HTML responses must be properly encoded (e.g., using htmlspecialchars() or equivalent) to prevent script execution. A Web Application Firewall (WAF) can provide interim protection by filtering JavaScript payloads in the Message parameter. Long-term, consider migrating to a maintained, actively patched student management system or implementing a comprehensive code review and security hardening process for this project.

Patch guidance

No official patch has been released by the project maintainers. Monitor the project repository for security updates or consider forking and patching the codebase internally. The fix should include: (1) Input validation to reject or sanitize JavaScript-bearing content in the Message parameter; (2) Output encoding when the Message parameter is rendered in HTML contexts, using functions like htmlspecialchars() with ENT_QUOTES and UTF-8 encoding; (3) Implementation of a Content Security Policy (CSP) header to restrict script execution; and (4) Review of all similar parameters in the application for the same vulnerability pattern. Verify the fix by re-testing with common XSS payloads (e.g., <img src=x onerror=alert(1)>) before deploying to production.

Detection guidance

Monitor web access logs for admission_form_check.php requests containing suspicious Message parameter values, such as script tags, event handlers (onerror, onload, onclick), or encoded JavaScript. Search for patterns like %3Cscript, javascript:, onerror=, onload=, and similar XSS indicators. Implement WAF rules to flag or block requests matching common XSS patterns targeting the Message parameter. Use browser-based security tools (e.g., browser console) to check for unexpected script execution on the admission form page. Enable HTTP response header inspection to confirm Content-Security-Policy and X-XSS-Protection headers are present and properly configured. For deployed instances, correlate access logs with user complaints about unexpected page behavior or unauthorized messages to identify exploitation attempts.

Why prioritize this

Although the CVSS score is LOW (3.5), this vulnerability merits prioritization due to the public availability of exploit code, the authenticated attack vector in a system handling sensitive student PII, and the lack of vendor response. Organizations in regulated industries or with strict data protection obligations should treat this as medium priority. The requirement for user interaction provides some natural defense, but the ease of exploitation and educational sector targeting justify rapid remediation planning. If the system is internet-facing or accessible to a large number of authenticated users, the effective risk increases beyond the base score.

Risk score, explained

The CVSS 3.1 score of 3.5 reflects a LOW severity vulnerability with network accessibility, low attack complexity, and requirements for authentication and user interaction. The vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N breaks down as: (1) Network-accessible attack surface; (2) Low complexity (straightforward exploitation); (3) Low privileges required (authenticated user); (4) User interaction mandatory (target must click/view); (5) Unchanged scope (attacker cannot escalate privileges); (6) No confidentiality impact; (7) Low integrity impact (malicious script can modify displayed content but not underlying data); (8) No availability impact. The score does not account for threat actor motivation, public exploit availability, or regulatory context—factors that may elevate practical risk in your environment. Use this score as a baseline, not an absolute risk determination.

Frequently asked questions