CVE-2026-61685 in ReactPress
Summary
by MITRE • 09/23/2026
ReactPress is a publishing system for React developers. Prior to version 3.7.0, ReactPress API list endpoints build TypeORM `QueryBuilder` conditions using unsanitized HTTP query parameter names as SQL column identifiers (e.g. `` `article.${key}` ``). TypeORM parameterizes values but not column names, allowing unauthenticated attackers to inject SQL through crafted query string keys. Version 3.7.0 contains a patch. As a workaround, allowlist allowed filter column names before interpolating into SQL.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/23/2026
ReactPress is a publishing system designed for React developers that facilitates content management and API generation. In versions prior to 3.7.0, the application exposes RESTful endpoints intended to list articles or other entities stored in a database via TypeORM. These endpoints accept HTTP query parameters to allow users to filter, sort, or paginate results. The vulnerability arises from how these endpoints construct SQL queries using TypeORM's QueryBuilder interface. Specifically, when processing request filters, the system directly interpolates user-supplied query parameter names into SQL column identifiers without performing any sanitization or validation checks on those input values.
The technical flaw centers on a fundamental misunderstanding of how prepared statements and parameterized queries function within database drivers like TypeORM. While TypeORM correctly parameterizes the values passed to WHERE clauses, preventing injection through data fields such as article titles or IDs, it does not automatically escape column names used in ORDER BY, GROUP BY, or SELECT clauses. By embedding unsanitized HTTP query keys directly into backtick-quoted SQL identifiers (e.g., `article.${key}`), the application allows an attacker to manipulate the structure of the SQL statement itself rather than just its data payload. This constitutes a classic SQL Injection vulnerability where the injection vector is metadata—specifically column names—rather than traditional string-based input fields.
This architectural weakness enables unauthenticated attackers to execute arbitrary SQL commands against the underlying database. By crafting specific query strings, an attacker can inject malicious syntax that alters the intended logic of the query. Potential impacts include unauthorized data exfiltration through UNION SELECT statements, extraction of sensitive information from other tables such as user credentials or configuration settings, and potentially causing denial of service by executing resource-intensive queries or dropping tables if permissions allow. Since this affects list endpoints which are often publicly accessible without authentication, the attack surface is broad and easily exploitable by automated scanning tools targeting common API patterns.
From a classification perspective, this vulnerability aligns with CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection). It also maps to MITRE ATT&CK technique T1059.004: SQL Commands, specifically illustrating how attackers can leverage application logic flaws to bypass standard input validation mechanisms by targeting structural elements of the query rather than data values. The lack of allowlisting for column names represents a failure in secure coding practices regarding dynamic query construction.
To mitigate this vulnerability, applications must implement strict allowlists for all user-supplied identifiers used in SQL queries. In the context of ReactPress version 3.7.0 and later, developers have addressed this by validating that filter keys correspond to known, safe column names before interpolating them into the QueryBuilder conditions. For systems still running older versions or custom implementations using TypeORM or similar ORMs, it is critical to never trust user input for structural components of SQL statements such as table names, column names, sort orders, or groupings. Instead, developers should map allowed parameter values to predefined internal identifiers and reject any inputs that do not match the expected schema definitions. Additionally, applying principle of least privilege to database accounts used by the application can limit the damage if an injection attempt succeeds, ensuring that even successful exploitation cannot perform destructive actions like dropping tables or modifying system configurations.