CVE-2025-40694 is a stored Cross-Site Scripting (XSS) vulnerability identified in version 1.2 of the PHPGurukul Online Fire Reporting System (OFRS). The vulnerability arises due to improper neutralization of user input in the 'fromdate' and 'todate' POST parameters at the endpoint '/ofrs/admin/bwdates-report-result.php'. Specifically, these parameters are not properly validated or sanitized before being embedded into the web page output, allowing an attacker to inject malicious scripts that are stored on the server and later executed in the context of authenticated users who access the affected page. This stored XSS can be exploited remotely without authentication, but the attacker must trick an authenticated user into visiting a crafted URL or submitting a crafted request, enabling the attacker to steal session cookies or perform actions on behalf of the victim. The CVSS v4.0 base score is 5.1 (medium severity), reflecting network attack vector, low attack complexity, no privileges required, but user interaction is necessary. The vulnerability does not impact confidentiality, integrity, or availability directly but compromises user session confidentiality through cookie theft. No patches are currently available, and no known exploits are reported in the wild. The vulnerability is assigned CWE-79, indicating improper input neutralization during web page generation, a common vector for XSS attacks. The issue was reserved in April 2025 and published in September 2025 by INCIBE, a recognized cybersecurity entity. The vulnerability affects only version 1.2 of the product, which is a specialized online fire incident reporting system used primarily by administrative personnel for generating reports based on date ranges.

For European organizations, particularly those involved in emergency services, municipal fire departments, or public safety agencies using the PHPGurukul Online Fire Reporting System, this vulnerability poses a risk of session hijacking and unauthorized actions within the administrative interface. An attacker exploiting this flaw could steal session cookies from authenticated users, potentially gaining unauthorized access to sensitive fire incident data or administrative functions. This could lead to data disclosure, manipulation of fire reports, or disruption of reporting workflows. While the vulnerability does not directly cause system downtime or data destruction, the compromise of administrative sessions could undermine trust in the reporting system and delay critical emergency response coordination. Additionally, if attackers leverage stolen sessions to escalate privileges or pivot to other internal systems, the impact could extend beyond the application itself. Given the specialized nature of the product, the impact is more pronounced in organizations that rely heavily on this system for operational reporting and decision-making. The medium severity rating suggests moderate risk, but the potential for targeted attacks against public safety infrastructure in Europe warrants attention.

To mitigate this vulnerability, organizations should implement strict input validation and output encoding for the 'fromdate' and 'todate' parameters in the affected endpoint. Specifically, input should be validated to accept only properly formatted date strings (e.g., YYYY-MM-DD) and reject any input containing script tags or suspicious characters. Output encoding should be applied to ensure that any user-supplied data rendered in the HTML context is safely escaped to prevent script execution. Until an official patch is released by PHPGurukul, administrators should consider the following practical steps: 1) Restrict access to the '/ofrs/admin/bwdates-report-result.php' endpoint to trusted IP addresses or VPN users to reduce exposure. 2) Implement Web Application Firewall (WAF) rules that detect and block common XSS payloads targeting the vulnerable parameters. 3) Educate users to avoid clicking on suspicious links or submitting untrusted data within the application. 4) Monitor application logs for unusual input patterns or repeated access to the vulnerable endpoint. 5) Consider deploying Content Security Policy (CSP) headers to limit the execution of unauthorized scripts within the application context. 6) Plan for an update or patch deployment as soon as the vendor releases a fix. These steps go beyond generic advice by focusing on the specific parameters and endpoint involved, as well as operational controls to reduce risk in the interim.