CVE-2026-58205 in GRR
Summary
by MITRE • 10/28/2026
GRR is a resource management and reservation application. Prior to version 4.5.0, `maj.php` reflects the `forcemaj` parameter without adequate escaping when installation files remain accessible. Removal of these files is not automatic. An attacker can craft a URL that executes arbitrary JavaScript in a victim's browser when the victim accesses it. This reflected cross-site scripting can enable phishing, redirection to malicious sites, cookie theft and session hijacking because the authentication cookie is not `HttpOnly`. This issue is fixed in version 4.5.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
GRR serves as a resource management and reservation application designed to handle scheduling and allocation of shared assets within organizational environments. The software architecture includes administrative interfaces that process user inputs for configuration changes, such as managing major incidents or disruptions via the maj.php endpoint. In versions prior to 4.5.0, this specific component exhibits a critical input validation deficiency where it fails to properly sanitize data before reflecting it back into the HTTP response. This flaw is particularly exploitable when installation files remain accessible on the server post-deployment, as these residual scripts can sometimes expose additional attack surfaces or facilitate easier discovery of vulnerable endpoints by attackers scanning for common administrative paths.
The core technical vulnerability lies in a reflected cross-site scripting (XSS) condition affecting the forcemaj parameter. When an attacker crafts a malicious URL containing embedded JavaScript payloads within this parameter and induces a victim to access it, the application reflects the unsanitized input directly into the page content without adequate escaping or encoding. This behavior aligns with CWE-79, which classifies improper neutralization of input during web page generation as a fundamental weakness in web application security. The reflection mechanism allows arbitrary client-side scripts to execute within the context of the victim's browser session, effectively bypassing same-origin policy protections and granting the attacker control over the DOM environment experienced by the user.
The operational impact of this vulnerability is severe due to the specific configuration characteristics of GRR installations during that period. Because authentication cookies were not marked with the HttpOnly flag, they remain accessible via JavaScript APIs such as document.cookie. This oversight transforms a standard reflected XSS flaw into a potent vector for session hijacking and credential theft. An attacker can exploit this by stealing active session tokens to impersonate legitimate users without needing their passwords. Furthermore, the ability to execute arbitrary scripts enables sophisticated phishing attacks where attackers can inject fake login forms or redirect victims to malicious external sites designed to harvest sensitive information or distribute malware. This aligns with ATT&CK technique T1059.007 (JavaScript) for execution and T1539 (Steal Web Session Cookie) for data exfiltration, highlighting the dual nature of the threat as both an access control bypass and a social engineering enabler.
To mitigate this vulnerability, organizations must ensure that GRR is upgraded to version 4.5.0 or later, where the input validation logic has been corrected to properly escape user-supplied data before rendering it in HTML contexts. Additionally, immediate remediation steps should include removing any leftover installation files from the server filesystem to reduce the attack surface and prevent potential information disclosure that could aid attackers in identifying vulnerable endpoints. Security administrators should also implement a Content Security Policy (CSP) header to restrict script execution sources and enforce the HttpOnly flag on all authentication cookies across the application, thereby neutralizing the impact of any future XSS attempts by preventing client-side scripts from accessing sensitive session data.