Description

Wheels through 4.1.2 allows SQL injection on MySQL/MariaDB with backslash escaping enabled (NO_BACKSLASH_ESCAPES absent) when an application supplies request data to inline-literal paths. These include opt-in parameterize=false queries and IN lists, and positions in developer-written where strings that the parser does not bind, such as BETWEEN bounds, function arguments and LIKE ESCAPE literals. Doubling single quotes without accounting for backslash escapes allows a value to alter the query. Bound paths are not affected; whereBetween() is bound from 4.1.2. This is fixed in 4.2.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-10-16T04:18:30.353Z",
  "pubdate": "2026-10-16T04:18:30.353Z",
  "executiveSummary": "Wheels versions through 4.1.2 are susceptible to a critical SQL injection vulnerability when deployed against MySQL or MariaDB instances where the NO_BACKSLASH_ESCAPES mode is disabled.\nThe vulnerability arises from improper sanitization of user-supplied data within inline-literal query paths, including unparameterized queries, IN lists, and specific segments of manual WHERE strings like function arguments or LIKE ESCAPE literals.\nBy manipulating single quotes in the presence of backslash-enabled escaping, an unauthenticated attacker can influence query logic, potentially leading to unauthorized data exfiltration, modification, or bypass of application-level security controls.\nThe impact is significant, as it allows for arbitrary SQL command execution within the context of the database user. The risk is elevated in applications that rely on raw or inline-literal SQL fragments rather than parameterized bindings. Mitigation requires upgrading to version 4.2.0 or later, which addresses the underlying sanitization deficiencies, specifically within whereBetween() and related query builder methods.",
  "technicalDetails": "The root cause of this vulnerability is a flaw in the Wheels query construction logic when interacting with MySQL/MariaDB environments that permit backslash-based character escaping. In these environments, the default character escaping mechanisms used by the application do not adequately account for the backslash character's role in neutralizing or altering the behavior of subsequent single quotes.\nWhen an application utilizes inline-literal paths—defined as scenarios where data is embedded directly into the SQL statement rather than handled via prepared statements—the internal string-escaping routines for single quotes are bypassed or insufficient. Specifically, when the parser encounters developer-written WHERE strings, or opt-in parameterize=false queries, it fails to sanitize inputs destined for sensitive positions. These positions include BETWEEN bounds, function arguments, and literals used within LIKE ESCAPE clauses.\nThe exploitation flow proceeds as follows: An attacker provides crafted input containing specific sequences of single quotes and backslashes. Because the application logic doubles single quotes to escape them, but fails to check for existing backslashes in the input, the escaping mechanism is subverted. If the database engine treats the backslash as an escape character, it can 'consume' the closing single quote intended for the data, effectively escaping the escape character itself. This allows the attacker to 'break out' of the literal string context and inject arbitrary SQL syntax into the query stream.\nThis vulnerability specifically affects versions through 4.1.2. Bound paths, such as those used by standardized QueryBuilder methods, are generally safe; notably, the whereBetween() method was explicitly patched in version 4.1.2 to ensure proper binding, but other inline-literal paths remained exposed until the comprehensive fixes introduced in 4.2.0.\nThe attacker requires no specific authentication or elevated privileges, provided they can influence the input strings passed to vulnerable database interaction points. The attack surface includes any application feature that accepts user input and processes it through the affected inline-literal query construction methods. Post-exploitation, an attacker can manipulate the query structure to bypass authentication, dump sensitive database tables, or potentially perform administrative operations if the database service account possesses excessive privileges. The lack of parameterization in these specific code paths is the primary vector, making the reliance on manual sanitization inherently fragile in the face of varying database configuration modes like NO_BACKSLASH_ESCAPES."
}