CVE-2026-2201: ZeroWdd studentmanager XSS Vulnerability

CVE-2026-2201 Overview

A stored Cross-Site Scripting (XSS) vulnerability has been identified in ZeroWdd studentmanager, an open-source student management system. This vulnerability affects the addLeave function within the LeaveController.java file, where insufficient input validation allows malicious script injection through the "Reason for Leave" parameter. The exploit has been publicly disclosed and the affected code repository has been inactive for many years, leaving users without an official security patch.

Critical Impact
Authenticated users with elevated privileges can inject malicious JavaScript through the leave request form, potentially leading to session hijacking, credential theft, or malicious actions performed on behalf of other users when they view the compromised leave request data.

Affected Products

ZeroWdd studentmanager (up to commit 2151560fc0a50ec00426785ec1e01a3763b380d9)
All versions of the rolling release model prior to any security fix
Deployments using the LeaveController.java component for leave management

Discovery Timeline

2026-02-09 - CVE-2026-2201 published to NVD
2026-02-09 - Last updated in NVD database

Technical Details for CVE-2026-2201

Vulnerability Analysis

This Cross-Site Scripting vulnerability exists in the leave management functionality of the studentmanager application. The addLeave function in src/main/java/com/wdd/studentmanager/controller/LeaveController.java fails to properly sanitize user-supplied input in the "Reason for Leave" field before storing and rendering it in the application.

The attack requires network access and an authenticated user with elevated privileges to inject the malicious payload. However, the stored nature of this XSS means that any user viewing the affected leave request data will execute the attacker's script in their browser context. This could enable session token theft, defacement of the application interface, or phishing attacks targeting other users of the system.

The project uses a rolling release model without versioned releases, and notably, the code repository has been inactive for many years. This abandonment status significantly increases the risk as no official patch is expected to be released.

Root Cause

The root cause is improper input validation and output encoding in the addLeave function. The application accepts user input through the "Reason for Leave" parameter and stores it directly in the database without sanitizing potentially dangerous HTML or JavaScript content. When this data is later retrieved and rendered in web pages, the malicious scripts execute in victims' browsers.

This is a classic CWE-79 (Improper Neutralization of Input During Web Page Generation) vulnerability where the application fails to:

Validate and sanitize input on submission
Encode output properly when rendering stored data

Attack Vector

The attack is initiated remotely over the network. An authenticated attacker with appropriate privileges submits a leave request containing malicious JavaScript in the "Reason for Leave" field. The application stores this payload without sanitization.

When other users (administrators, teachers, or students depending on the application's access model) view the leave request, the stored script executes within their browser session. This could allow the attacker to steal session cookies, perform actions on behalf of the victim, or redirect users to malicious sites.

The vulnerability exploits the trust relationship between the application and its users, as content stored in the database is implicitly trusted when rendered in the user interface.

Detection Methods for CVE-2026-2201

Indicators of Compromise

Presence of HTML tags or JavaScript syntax in leave request "Reason" fields (e.g., <script>, javascript:, event handlers like onerror, onload)
Unusual characters or encoding patterns in database records for leave requests
User reports of unexpected browser behavior when viewing leave request pages
Web application firewall (WAF) logs showing blocked XSS patterns targeting the leave management endpoints

Detection Strategies

Review database records in the leave management tables for entries containing script tags, event handlers, or other HTML injection patterns
Implement web application firewall rules to detect and block common XSS payloads in POST requests to leave-related endpoints
Deploy Content Security Policy (CSP) headers to detect inline script execution attempts through violation reports
Monitor application logs for suspicious patterns in the leave request submission parameters

Monitoring Recommendations

Enable detailed logging for all leave request submissions including full parameter values
Configure browser CSP violation reporting to capture attempted XSS exploitation
Set up alerts for database entries containing potential script injection patterns
Review access logs for unusual patterns of leave request viewing that might indicate reconnaissance or exploitation

How to Mitigate CVE-2026-2201

Immediate Actions Required

Implement input validation to reject or sanitize HTML/JavaScript content in all user-supplied fields, particularly the "Reason for Leave" parameter
Apply output encoding (HTML entity encoding) when rendering user-supplied content in web pages
Deploy Content Security Policy headers to prevent inline script execution
Consider disabling or restricting access to the leave management functionality until proper fixes are applied

Patch Information

No official patch is available from the vendor. The ZeroWdd studentmanager project repository has been inactive for many years and uses a rolling release model without versioned releases. Users should implement their own fixes or consider migrating to an actively maintained alternative.

For technical details and vulnerability disclosure information, refer to the VulDB Advisory or the Yuque Security Document.

Workarounds

Fork the repository and implement proper input sanitization in the LeaveController.java file before the addLeave function processes user input
Add a servlet filter or Spring interceptor to sanitize all incoming request parameters
Configure a Web Application Firewall (WAF) to filter XSS payloads targeting the application
Implement strict Content Security Policy headers to mitigate the impact of successful XSS attacks
Restrict access to the leave management module to trusted users only until a proper fix is implemented

bash

# Example Content Security Policy header configuration for Apache
# Add to .htaccess or httpd.conf
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; frame-ancestors 'self';"