Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-10-15T04:18:22.813Z",
  "pubdate": "2026-10-15T04:18:22.813Z",
  "executiveSummary": "Wheels versions 1.1.8 through 4.1.1 are susceptible to SQL injection vulnerabilities stemming from improper handling of caller-supplied quoted values within dynamic finders and query builder methods.\nThe vulnerability allows unauthorized attackers to manipulate SQL queries by injecting malicious input into functions like findOneByEmail, where(), and validatesUniquenessOf.\nThis flaw can lead to critical security compromises, including the bypass of authentication mechanisms, unauthorized password resets, exposure of sensitive tokens, and potential extraction of sensitive application data.\nAn additional vulnerability affects the whereBetween() method in versions 4.0.0 through 4.1.1, where string or date bounds can be exploited to alter SQL statements specifically on MySQL or MariaDB instances configured with backslash escaping enabled.\nThe primary risk involves unauthorized data access or manipulation, potentially leading to full application compromise depending on the context of the vulnerable query execution.\nExploitation generally requires the application to pass untrusted request data directly into the affected API methods without sufficient server-side sanitization or parameterized query enforcement.",
  "technicalDetails": "The core of this vulnerability lies in an improper parsing logic within the Wheels framework's query generation process. When user-supplied values are processed, the parser fails to correctly interpret escaped characters, specifically treating doubled single quotes as the termination of a literal string rather than an escaped character within the literal.\nThis behavior facilitates SQL injection, as an attacker can craft inputs that break out of the intended string context to append arbitrary SQL commands. Affected components include dynamic finders (e.g., findOneByEmail), the query builder methods where(property, value) and where(property, operator, value), string/UUID-key lookups (findByKey, updateByKey, deleteByKey, findOrCreateBy), and the validation routine validatesUniquenessOf.\nIn a typical attack flow, an application takes raw input from a request—such as a URL parameter or POST body—and passes it directly to a dynamic finder or query method. By providing a payload containing single quotes, the attacker forces the framework's parser to incorrectly close the current literal and begin interpreting the remainder of the input as SQL directives, such as UNION statements or boolean-based blind injection conditions.\nFurthermore, versions 4.0.0 through 4.1.1 contain a specific vulnerability within the whereBetween() function. On MySQL and MariaDB databases where backslash escaping (\\) is enabled, the framework fails to properly handle string or date bounds. An attacker can use backslashes to escape intended delimiters or manipulate the underlying SQL query structure, leading to unauthorized data retrieval.\nThese vulnerabilities do not affect numeric-column lookups, as the underlying SQL typing prevents the inclusion of string-terminating characters. However, for string-based operations, the framework effectively permits the manipulation of the WHERE clause, allowing for the exfiltration of database contents, authentication bypass, or the modification of application logic.\nThe exploitation path does not necessarily require high-level authentication, as the vulnerable methods are often invoked during initial request processing for login or data retrieval. The impact is significant because these methods are foundational to data access patterns within the framework, placing sensitive operations like password verification and token lookups at risk of injection-based subversion."
}