CVE-2026-110911 in Wheels
Summary
by MITRE • 10/15/2026
Wheels 1.1.8 through 4.1.1 allows SQL injection when caller-supplied quoted values are parsed again as SQL by dynamic finders (such as findOneByEmail), the query builder's where(property, value) and where(property, operator, value), string/UUID-key lookup paths (findByKey, updateByKey, deleteByKey and findOrCreateBy...), and validatesUniquenessOf. The parser incorrectly treats a doubled single quote as the end of a literal. Applications passing request data to these APIs can expose authentication, password-reset or token lookups, and data to unauthorized access; numeric-column values are not affected. There is a similar concern for query-builder whereBetween() in 4.0.0 through 4.1.1: string/date bounds can alter SQL on MySQL/MariaDB with backslash escaping enabled. This is fixed in 4.1.2.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The Wheels framework, a Model-View-Controller (MVC) application for ColdFusion and Lucee CFML, contains critical input validation flaws that allow attackers to perform SQL injection attacks through multiple entry points within its dynamic query generation mechanisms. The vulnerability affects versions 1.1.8 through 4.1.1 of the framework. These flaws stem from an incorrect parsing logic where caller-supplied quoted values are re-parsed as raw SQL by various internal methods. Specifically, the issue arises because the parser incorrectly interprets a doubled single quote sequence as the termination point for a string literal rather than recognizing it as an escaped character within the value itself. This fundamental misunderstanding of input sanitization allows malicious actors to break out of intended query contexts and inject arbitrary SQL commands.
The scope of this vulnerability is broad, impacting several key API methods used for data retrieval and manipulation. Dynamic finders such as findOneByEmail are susceptible because they construct queries based on user-provided identifiers without adequate protection against injection techniques that exploit the quote parsing error. Similarly, the query builder's where method, when invoked with two or three arguments to specify property-value pairs or property-operator-value conditions, fails to properly escape inputs before inclusion in the SQL statement. Furthermore, string and UUID-key lookup paths including findByKey, updateByKey, deleteByKey, and findOrCreateBy methods are also vulnerable as they rely on similar internal parsing logic that mishandles special characters within keys used for database lookups.
The operational impact of these vulnerabilities is severe, potentially leading to unauthorized access to sensitive application data and authentication mechanisms. Since the affected APIs often handle user credentials and session tokens, an attacker could exploit this flaw to bypass login screens by manipulating SQL conditions in password-reset or token lookup queries. This capability allows for complete account takeover without valid credentials. Additionally, attackers can extract arbitrary data from the underlying database, leading to significant confidentiality breaches. It is important to note that numeric-column values are not affected by these specific injection vectors because they do not involve string literal parsing issues related to quote handling; however, any field accepting string input remains at risk if passed through the vulnerable methods listed above.
A secondary but related vulnerability exists within the query-builder's whereBetween method in versions 4.0.0 through 4.1.1. This specific flaw allows for SQL alteration when dealing with string or date bounds on MySQL and MariaDB databases that have backslash escaping enabled. In these environments, an attacker can manipulate the boundary values to alter the structure of the generated SQL query, potentially leading to data leakage or unauthorized modifications similar to standard injection attacks but exploiting a different parsing edge case related to escape character handling in specific database configurations.
To mitigate these risks, organizations using Wheels must upgrade immediately to version 4.1.2 or later, where these parsing errors have been corrected and input validation has been strengthened. For applications unable to update the framework instantly, developers should implement strict input validation on all user-supplied data before passing it to any dynamic finder or query builder method. This includes ensuring that string inputs are properly escaped using database-specific functions rather than relying solely on the framework's internal parsing logic during development phases. Additionally, employing parameterized queries where possible and avoiding direct concatenation of user input into SQL strings provides an additional layer of defense against injection attacks.
From a classification perspective, this vulnerability aligns with CWE-89: Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The exploitation technique involves manipulating the structure of the query through crafted inputs that exploit parsing ambiguities, which corresponds to ATT&CK tactic T1059: Command and Scripting Interpreter if interpreted broadly within application logic abuse, or more accurately T1190: Exploit Public-Facing Application when targeting web-facing endpoints. The failure lies in the input validation layer (CWE-20) where special characters are not correctly neutralized before being processed by the SQL interpreter embedded within the framework's ORM layer.