CVE-2026-113608 in Configurable Reports Plugin
Summary
by MITRE • 10/20/2026
Configurable Reports block for Moodle (moodle-block_configurablereports) before 5.3.1 contains an sql injection vulnerability in report_sql::prepare_sql() via the filter_var request parameter of viewreport.php. Low-privileged users permitted to view reports using the %%FILTER_VAR%% placeholder can inject subqueries or UNION SELECT to read arbitrary database tables, including user password hashes.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The Moodle Configurable Reports block represents a widely utilized plugin that allows administrators and authorized educators to create custom data views within the learning management system by querying its underlying relational database. In versions prior to 5.3.1, this functionality contains a critical SQL injection vulnerability located specifically within the report_sql::prepare_sql() method. The flaw is triggered when processing requests directed at viewreport.php, particularly through the filter_var request parameter which is designed to substitute values into predefined query templates using the %%FILTER_VAR%% placeholder mechanism. This architectural design intends to provide flexibility for dynamic reporting while maintaining security boundaries between user input and database execution logic.
The technical root cause of this vulnerability stems from insufficient sanitization or type checking applied to the data supplied via the filter_var parameter before it is integrated into the SQL query string. Although the system employs a placeholder substitution pattern that typically suggests an intent toward safe parameter binding, the implementation fails to adequately validate the input against injection payloads. Consequently, attackers can manipulate this parameter to inject arbitrary SQL syntax directly into the execution context of the database engine. This lack of proper isolation allows malicious actors to break out of the intended query structure and append additional commands or modify existing ones without authorization.
From an operational perspective, the impact of this vulnerability is severe due to its potential for unauthorized data access by low-privileged users. Individuals who are merely permitted to view reports using the %%FILTER_VAR%% placeholder can exploit this flaw to execute subqueries or UNION SELECT statements against the database. This capability effectively bypasses standard role-based access controls, enabling these users to read arbitrary tables within the Moodle database schema. Of particular concern is the ability to extract sensitive information such as user password hashes, session tokens, and other personally identifiable data stored in the system. The exploitation does not require administrative privileges, significantly expanding the attack surface available to malicious insiders or compromised accounts with minimal permissions.
This vulnerability aligns closely with CWE-89 Improper Neutralization of Special Elements used in an SQL Command within industry classification standards. It also maps directly to MITRE ATT&CK technique T1059 Command and Scripting Interpreter, specifically the database query component, as well as T1213 Data from Information Repositories, reflecting the unauthorized extraction of data from structured storage systems. The exploitation path demonstrates how seemingly benign configuration parameters can become vectors for significant security breaches when input validation is neglected in dynamic query generation processes.
Mitigation strategies must prioritize immediate patching to version 5.3.1 or later where this specific logic error has been addressed through improved input sanitization and stricter type enforcement on the filter_var parameter. In environments where upgrading is not immediately feasible, administrators should restrict access to viewreport.php for any users who do not strictly require report viewing capabilities. Additionally implementing Web Application Firewall rules that detect common SQL injection patterns within query parameters can provide a layer of compensatory control. Regular auditing of database permissions and ensuring the principle of least privilege are applied to all user roles further reduces the risk associated with this class of vulnerability.