CVE-2026-63156 in Agora Project
Summary
by MITRE • 10/14/2026
Omnispace Agora Project before 26.10.0 contains a reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject malicious HTML attributes by manipulating the visioUrl parameter, which was not routed through the URL-sanitizing branch of the parameter filter and was urldecoded after filtering. Attackers can craft a malicious URL containing the visioUrl parameter with an attribute breakout payload to execute arbitrary JavaScript in the victim's browser pre-authentication, with the issue fixed in version 26.10.0 via changes to app/Common/Req.php.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The Omnispace Agora Project prior to version 26.10.0 is susceptible to a reflected cross-site scripting vulnerability that stems from improper input validation and sanitization of the visioUrl parameter. This flaw allows unauthenticated attackers to inject malicious HTML attributes into web pages viewed by other users, facilitating pre-authentication attacks without requiring valid credentials. The root cause lies in the application's request handling logic, specifically within the file app/Common/Req.php, where the filtering mechanism fails to properly sanitize user-supplied input before it is processed and reflected back to the client browser.
The technical nature of this vulnerability involves a specific flaw in how parameters are filtered and decoded. The visioUrl parameter was not routed through the URL-sanitizing branch of the application's parameter filter, which means that standard security checks designed to strip or escape dangerous characters were bypassed for this specific input field. Furthermore, even if some filtering occurred earlier in the pipeline, the value undergoes url decoding after the filtering step. This sequence creates a classic time-of-check-to-time-of-use scenario where malicious payloads encoded with special characters can evade initial validation and subsequently be decoded into executable code by the browser when rendered on the page.
Attackers can exploit this weakness by crafting a specially constructed URL that includes the visioUrl parameter containing an attribute breakout payload. When a victim clicks or is directed to this malicious link, their browser interprets the injected script as part of the legitimate web application content. Because the execution occurs before authentication checks are enforced in certain contexts, attackers can execute arbitrary JavaScript code within the context of the vulnerable site. This capability enables various attacks including session hijacking through cookie theft, credential harvesting via fake login forms, or defacement of the user interface to lure victims into further malicious actions.
From a classification perspective, this vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). Specifically, it represents a reflected XSS attack where the payload is immediately returned by the web application in response to a user's request. In terms of adversary tactics, this falls under MITRE ATT&CK technique T1059, Command and Scripting Interpreter, specifically JavaScript execution within a browser environment. The ability to execute scripts pre-authentication significantly lowers the barrier for exploitation compared to post-login vulnerabilities, as it targets any visitor regardless of their privilege level or account status.
To mitigate this vulnerability, organizations running versions of Omnispace Agora Project earlier than 26.10.0 should immediately upgrade to version 26.10.0 or later where the issue has been resolved through changes in app/Common/Req.php. The fix likely involves ensuring that all user inputs are properly sanitized before any decoding operations take place, thereby preventing malicious scripts from being rendered by the browser. Additionally, implementing Content Security Policy headers can provide an additional layer of defense by restricting the sources from which scripts can be loaded and executed, reducing the impact if similar vulnerabilities exist elsewhere in the application. Regular security audits and static code analysis focused on input validation logic are recommended to prevent recurrence of such flaws in future development cycles.