Summary
CVE-2026-63152 is a second-order SQL injection vulnerability (CWE-89) in Omnispace Agora Project affecting all versions before 26.10.0. An authenticated attacker can inject malicious SQL through the _idCategoryFilter parameter. Rather than executing immediately, the injected value is persisted into the attacker’s session and is later concatenated into a SQL statement without parameterization when the category filter is applied in app/Common/MdlCategory.php. The described outcome is unauthorized database access or manipulation. The vulnerability carries a CVSS 4.0 base score of 8.6 (HIGH), with a network attack vector, low privilege requirements, no user interaction, and high confidentiality and integrity impacts.
Two properties make this bug worth a close read: it requires only a low-privileged account, and the payload’s execution is deferred to a later request, which means the submission request itself can look entirely benign in logs. The fix is available in version 26.10.0, published as release tag 26.10 on the project’s GitHub repository.
Technical Analysis
The vulnerability is classified as CWE-89, improper neutralization of special elements used in an SQL command. According to the description, the attack path runs through the _idCategoryFilter parameter: an authenticated attacker supplies a value containing malicious SQL, the application persists that value into the session, and at a later point the stored value is concatenated into a SQL statement without parameterization. The sink named in the description is app/Common/MdlCategory.php, where the payload executes when the filter is subsequently applied.
The “second-order” label describes the timing. In a first-order injection, the malicious value reaches the database query within the same request that carries it, and errors or anomalies often surface immediately. Here, the description states that the payload is persisted into the session first. The submission request can complete without any visible symptom, because at that stage the value is only being stored. The injection fires on a later request, when the filter is applied and the stored value is spliced into SQL text in app/Common/MdlCategory.php. This separation between input and execution is precisely what makes second-order vulnerabilities easy to miss in automated scanning and in first-pass manual testing.
A notable detail is the storage medium. In the classic second-order pattern, the payload is stored in the database itself, which raises questions about cross-user reach. In CVE-2026-63152, the payload is persisted into the session, tying the stored value to the attacker’s own session. The description does not state whether the payload can cross account boundaries or affect other users’ requests, and that detail is not fully disclosed. What the description does establish is that the value survives between requests within the session and is later used unsafely.
The description says the stored value is “concatenated into a SQL statement without parameterization.” Concatenation means the filter value becomes part of the SQL text itself rather than being passed as a bound parameter, so any SQL syntax inside the value is interpreted by the database engine as code. Parameterized queries keep data and instructions separate; their absence at this sink is the root cause that the CWE-89 classification captures. The description does not disclose the exact SQL statement, the type of query being built, or the database backend in use, and those details are not fully disclosed.
The provided CVSS 4.0 vector, CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N, yields a base score of 8.6 (HIGH). Breaking it down: AV:N means the attack vector is network-reachable; AC:L and AT:N indicate low attack complexity with no preconditions beyond those described; PR:L matches the description’s “authenticated attackers” phrasing, meaning a low-privileged account is required but no elevated role; UI:N means no user interaction is needed. On the impact side, VC:H and VI:H score high confidentiality and integrity impact on the vulnerable system, consistent with “unauthorized database access or manipulation.” VA:N records no availability impact, and SC:N, SI:N, and SA:N record no impact flowing to subsequent systems. The exploit existence, report confidence, and other supplemental metrics are undefined (X) in the provided vector.
Authentication is the only gate. The CVSS vector’s PR:L metric and the description’s “authenticated attackers” phrasing align: any valid low-privileged account is sufficient to attempt the injection. There is no user interaction requirement (UI:N) and no special precondition (AT:N), so the barrier to entry is an account on a vulnerable deployment. Installations typically have multiple low-privileged users, which is reflected in the 8.6 HIGH score despite the authentication requirement.
For defenders and testers alike, the practical lesson is that a clean response to the parameter submission proves nothing. The payload sits dormant in session storage until the filter application code runs. Any test plan for this class of bug must include the second step: revisiting the functionality that consumes the stored value and observing the database behavior at that moment.
Affected Software and Versions
The affected product is Omnispace Agora Project, the web application published at agora-project.net, with source releases published on the GitHub repository xech/agora-project. According to the description, all versions before 26.10.0 are affected.
The fix is available in version 26.10.0, published as release tag 26.10 on the GitHub repository. The provided data does not include a separate vendor name field; the product is referenced as “Omnispace Agora Project” in both the description and the VulnCheck advisory title. No other products, branches, or version ranges are named in the provided data. Per the provided data, the vulnerability is not listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog.
Impact
The CVSS 4.0 vector scores the impact on the vulnerable system as high for both confidentiality (VC:H) and integrity (VI:H). The description translates this into concrete terms: “unauthorized database access or manipulation.” High confidentiality impact means the injected SQL can reach data the authenticated account is not authorized to read. High integrity impact means the attacker can alter database content through the same injection point.
The vector scores availability as none (VA:N), so denial of service is not part of the scored impact, and no impact to subsequent systems is scored (SC:N/SI:N/SA:N). Because the sink is a model file that applies category filters, the queries exposed are those built in app/Common/MdlCategory.php when the filter is applied. The description does not disclose which specific tables, columns, or records are reachable through the injection, nor whether the database account used by the application permits operations beyond reading and writing data. Those details are not fully disclosed.
For integrity, “manipulation” means the attacker’s SQL is not limited to reading: the description explicitly includes manipulation of the database. What an attacker can realistically change depends on the application’s database account and query context, and the description does not disclose those boundaries, so the practical blast radius within the database is not fully disclosed.
Exploitation Scenario
Illustrative scenario. The following flow is a reconstruction derived strictly from the description; exact endpoints, payload syntax, and query shapes are not fully disclosed.
- The attacker holds a valid low-privileged account on an Agora Project deployment running a version before 26.10.0. The CVSS vector requires low privileges (
PR:L), and the description specifies authenticated attackers. - Through the category filter functionality, the attacker submits a crafted value in the
_idCategoryFilterparameter containing SQL syntax. The application persists this value into the session. At this point nothing malicious has executed, and the request may look routine in logs. - On a subsequent request from the same session, the attacker triggers functionality that applies the stored category filter.
- In
app/Common/MdlCategory.php, the stored value is concatenated into a SQL statement without parameterization, and the injected SQL executes against the database. - The result is unauthorized database access or manipulation, as described in the advisory.
The two-step structure is the defining feature: the request that stores the payload and the request that triggers execution are separate, and the session is the bridge between them. The description does not name the page or route that accepts _idCategoryFilter, the page or route that applies the filter, or the structure of the vulnerable SQL statement, and those details are not fully disclosed.
Detection and Mitigation
Detection
Start with versioning: any Agora Project deployment running a version before 26.10.0 should be treated as affected.
Because the payload is persisted into the session and only executes when the filter is applied, detection should cover both stages. On the input side, review access logs for requests carrying _idCategoryFilter values that contain SQL metacharacters. On the execution side, correlate those submissions with later requests that apply the category filter, and watch for database errors or anomalous query behavior at that later point rather than at submission time.
Since the payload lives in session data, inspecting stored session values for SQL syntax in the category filter field is a direct indicator of attempted exploitation. For deployments where the source is available, inspect app/Common/MdlCategory.php for concatenation of the filter value into SQL statements; the description identifies this file as the location where the stored payload executes.
Mitigation
The remediation referenced by the provided sources is to upgrade to version 26.10.0, published as release tag 26.10 on the xech/agora-project GitHub repository. After upgrading, verify the deployed version against the 26.10.0 release page and re-check that the category filter functionality no longer accepts or acts on SQL metacharacters in _idCategoryFilter values.
The structural fix implied by the CWE-89 classification is to replace string concatenation with parameterized queries at the sink, so the stored filter value is always treated as data rather than as SQL text. Hardening the input path as well, validating that _idCategoryFilter contains only an expected identifier format before it is written to the session, reduces exposure, but the parameterized query at the execution point is what closes the vulnerability class.
Where an immediate upgrade is not possible, interim measures include restricting which accounts can reach the filter functionality, monitoring logs for SQL metacharacters in _idCategoryFilter values, and invalidating suspicious sessions. Keep in mind that input filtering at submission time alone is not a complete fix for a second-order injection, because the payload is stored first and executed later.
Bug Bounty Angle
This is an authenticated bug: the CVSS vector requires low privileges (PR:L), so testing requires an account on the target. Confirm that your authorization covers account creation and authenticated testing before you begin, and stay within the scope you have been granted.
Second-order vulnerabilities reward patience. If a crafted _idCategoryFilter value returns no error, do not stop there; exercise the functionality that applies the category filter and observe the result. The description indicates the payload executes only when the filter is subsequently applied in app/Common/MdlCategory.php, so the submission request alone proves nothing.
The project’s source is published on GitHub (xech/agora-project), which means you can read app/Common/MdlCategory.php and confirm the concatenation pattern before sending any payload. Reviewing the fixed 26.10.0 code can also show what changed, which helps you write a precise, verifiable report.
Document the two-step flow in your report: the request that stores the payload in the session, and the request that triggers execution. Reviewers triage many first-order injection reports; a clear second-order chain with the session-persistence step called out is far easier to validate and approve.
Per the provided data, this CVE is not listed in the CISA KEV catalog. That does not diminish its value as a finding on any target running an affected version of Agora Project.
Frequently Asked Questions
What is CVE-2026-63152?
A second-order SQL injection (CWE-89) in Omnispace Agora Project before 26.10.0. Authenticated attackers inject SQL via the _idCategoryFilter parameter; the value is persisted into the session and later concatenated into a SQL statement in app/Common/MdlCategory.php, enabling unauthorized database access or manipulation.
Is CVE-2026-63152 in the CISA KEV catalog?
No. Per the provided data, CVE-2026-63152 is not listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog.
How is CVE-2026-63152 fixed?
Upgrade Omnispace Agora Project to version 26.10.0 or later. The fix is published as release tag 26.10 on the project’s GitHub repository (xech/agora-project). Versions before 26.10.0 remain affected.
How severe is CVE-2026-63152?
CVSS 4.0 base score 8.6 (HIGH). The vector shows network exploitation, low attack complexity, low privileges required, no user interaction, and high confidentiality and integrity impacts with no availability impact.
Discovery and Credits: Discovered by Geoffrey Robert of akailabs and Valentin Holubec of akailabs; CVE assigned by VulnCheck.
Leave a Reply