CVE-2026-63152 in Agora Project
Summary
by MITRE • 10/13/2026
Omnispace Agora Project before 26.10.0 contains a second-order SQL injection vulnerability that allows authenticated attackers to inject malicious SQL via the _idCategoryFilter parameter, which is persisted into the session and later concatenated into a SQL statement without parameterization. Attackers can store a malicious payload that executes when the filter is subsequently applied in app/Common/MdlCategory.php, leading to unauthorized database access or manipulation.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified within Omnispace Agora Project versions prior to 26.10.0 represents a critical security flaw classified as a second-order SQL injection. This type of vulnerability is particularly insidious because the malicious payload is not executed immediately upon input but is instead stored in a persistent location, such as a user session or database record, and only triggered later when that data is retrieved and used in a subsequent operation. In this specific instance, the flaw resides in the handling of the _idCategoryFilter parameter. An authenticated attacker can supply a crafted value for this parameter during an initial request, which the application accepts without proper sanitization and stores it within the user's session state. This persistence mechanism allows the malicious input to survive across multiple requests, effectively bypassing immediate validation checks that might otherwise catch such payloads in non-persistent contexts.
The technical root cause of this vulnerability lies in the improper handling of data during its subsequent usage. When the application later processes a request involving category filtering, it retrieves the stored _idCategoryFilter value from the session and concatenates it directly into an SQL query string within the app/Common/MdlCategory.php module. This process occurs without the use of parameterized queries or prepared statements, which are essential for separating code from data in database interactions. By embedding user-controlled input directly into the SQL command structure, the application fails to distinguish between executable SQL commands and legitimate data values. Consequently, any special characters or SQL syntax included in the initial payload become part of the executed query logic rather than being treated as literal string content.
The operational impact of this vulnerability is severe, granting authenticated attackers the ability to perform unauthorized database access and manipulation. Because second-order SQL injection allows for complex payloads, an attacker can not only read sensitive data from the backend database but also modify or delete records, potentially compromising the integrity of the entire application's data store. In some scenarios, depending on the underlying Database Management System configuration, this could even lead to remote code execution if specific functions like xp_cmdshell are enabled and accessible by the database user account running the query. The requirement for authentication means that while external unauthenticated users cannot exploit this directly, any compromised or malicious insider with valid credentials poses a significant risk vector. This aligns closely with CWE-89, which defines Improper Neutralization of Special Elements used in an SQL Command, and is categorized under ATT&CK technique T1059 as Command Line Interface exploitation through database interactions.
To mitigate this vulnerability, immediate remediation efforts must focus on refactoring the code within app/Common/MdlCategory.php to utilize parameterized queries or prepared statements for all database operations involving user-supplied data. This ensures that input is always treated as data and never as executable code, regardless of its content. Additionally, implementing strict input validation and output encoding at every stage of the application lifecycle can provide defense-in-depth layers against injection attacks. Security teams should also enforce principle of least privilege for database accounts to limit the potential damage if an injection does occur. Regular security audits focusing on session management and data persistence mechanisms are recommended to identify similar patterns where stored values might be improperly concatenated into dynamic queries in other parts of the application codebase.