CVE-2026-66092 in openEQUELLA
Summary
by MITRE • 10/29/2026
In openEQUELLA before 2026.2, the pre-login notice is stored as HTML and rendered on the legacy logon page without encoding or sanitisation. A user holding the EDIT_SYSTEM_SETTINGS permission can set a notice containing an arbitrary script (PUT /api/preloginnotice), resulting in stored cross-site scripting on the login page. Unauthenticated exploitation is possible where EDIT_SYSTEM_SETTINGS has been granted to the guest user or Everyone
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in openEQUELLA versions prior to 2026.2 represents a critical security flaw rooted in improper input validation and output encoding within the application's authentication workflow. Specifically, the system fails to sanitize HTML content when storing pre-login notices that are subsequently rendered on the legacy logon page. This architectural oversight allows for stored cross-site scripting attacks where malicious scripts can be embedded into the notice field via a PUT request to the /api/preloginnotice endpoint. Because this data is persisted in the backend and served to every user visiting the login interface, it constitutes a high-impact vulnerability that affects both authenticated administrators with specific privileges and potentially unauthenticated users depending on permission configurations.
From a technical perspective, the core issue lies in the lack of context-aware output encoding when rendering dynamic content within HTML documents. When an attacker injects arbitrary JavaScript code into the pre-login notice field, the application stores this payload without applying necessary sanitization filters or escaping mechanisms such as HTML entity encoding. Consequently, when any user accesses the login page, their browser parses and executes the injected script in the context of the openEQUELLA domain. This behavior aligns with CWE-79, which classifies improper neutralization of input during web page generation as a primary cause for cross-site scripting vulnerabilities. The persistence of this payload ensures that every subsequent visit to the login screen triggers the malicious code execution, amplifying the potential blast radius significantly compared to reflected XSS variants.
The operational impact of this vulnerability is severe due to its placement on the authentication gateway itself. If an attacker successfully exploits this flaw, they can execute arbitrary JavaScript in the victim's browser session while interacting with the login page. This capability enables a range of malicious activities including credential harvesting through keyloggers or form hijacking, session token theft via document.cookie access, and redirection to phishing sites designed to mimic the legitimate authentication portal. Furthermore, because the attack vector is stored server-side, it does not require complex social engineering tactics involving specific links; simply visiting the login page is sufficient for exploitation if the malicious notice has been deployed by a privileged user or an unauthenticated actor with write access.
The severity of this vulnerability is heavily influenced by the system's permission model and default configurations. While exploitation typically requires EDIT_SYSTEM_SETTINGS permissions, which are generally restricted to administrators, there exists a critical risk scenario where these privileges have been inadvertently granted to lower-privileged roles such as guest users or the Everyone group. In such misconfigured environments, unauthenticated attackers can directly manipulate the pre-login notice without needing valid credentials. This transforms what might otherwise be an insider threat into a remote code execution vector accessible by any internet user with network connectivity to the application server.
To mitigate this vulnerability, immediate remediation involves upgrading openEQUELLA to version 2026.2 or later where these input validation and output encoding issues have been addressed. For systems that cannot be immediately upgraded, administrators should audit their role-based access control policies to ensure that EDIT_SYSTEM_SETTINGS permissions are strictly limited to trusted administrative accounts and never assigned to guest or public roles. Additionally, implementing a Content Security Policy header can help mitigate the impact of any remaining XSS vectors by restricting script execution sources. It is also advisable to review all existing pre-login notices for residual malicious content and clear cached versions if applicable.
This vulnerability maps directly to MITRE ATT&CK technique T1059, specifically sub-technique 007 which covers JavaScript-based command execution within web browsers. The attack pattern follows the initial access phase where a stored payload serves as the delivery mechanism for subsequent actions such as credential theft or lateral movement preparation. By addressing the root cause through proper encoding practices and tightening permission boundaries, organizations can effectively neutralize this threat vector and restore trust in their authentication infrastructure.