CVE-2026-78691 in ash_sql
Summary
by MITRE • 08/30/2026
Improper Neutralization of Special Elements in Data Query Logic vulnerability in ash-project ash_sql allows a user who supplies a search term to contains/2, string_starts_with/2, or string_ends_with/2 to inject live SQL LIKE wildcards, turning a literal substring search into an attacker-controlled pattern match.
The escape helpers in AshSql.Expr prefix % and _ with a backslash but never escape a backslash already present in the input. Because backslash is the default LIKE escape character, the escaping defeats itself: the input \% becomes the pattern fragment \\%, where \\ is a literal backslash and the attacker's % remains a live wildcard. The search value stays parameterized, so this is confined to the LIKE pattern grammar rather than full SQL. An attacker can widen matches to probe values, slip past a negated contains(...) guard, or crash the query with a trailing lone backslash.
This issue affects ash_sql: from 0.1.1-rc.10 before 0.7.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability identified as Improper Neutralization of Special Elements in Data Query Logic within the AshSql component represents a classic injection flaw rooted in flawed input sanitization logic for SQL LIKE pattern matching operations. This issue specifically impacts functions such as contains/2, string_starts_with/2, and string_ends_with/2, which are designed to perform literal substring searches but inadvertently allow an attacker to inject live SQL wildcards when specific escape sequences are present in the user-supplied search term. The core technical flaw lies in the implementation of the escape helpers within AshSql.Expr, which attempt to neutralize special characters by prefixing percent signs and underscores with a backslash. However, this logic fails to account for backslashes already existing in the input data. Since the backslash serves as the default escape character in SQL LIKE clauses, an attacker can exploit this oversight by providing a search term containing a backslash followed by a wildcard character. The system processes this input by escaping the backslash itself, resulting in a pattern where the original backslash is treated as a literal character and the subsequent wildcard remains active and unescaped. This transformation effectively converts what should be a strict literal match into an attacker-controlled pattern match, allowing for significant deviation from intended query behavior.
From a technical perspective, this vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command or SQL Command, specifically falling under the sub-category of LIKE operator injection. The attack vector is confined to the grammar of the LIKE pattern rather than constituting full SQL injection because the search value remains parameterized and does not allow for arbitrary SQL statement construction. Nevertheless, the ability to manipulate the pattern matching logic poses substantial risks. An attacker can utilize this flaw to widen query matches significantly beyond their intended scope. For instance, by injecting a percent sign after escaping it improperly, an attacker can match any character sequence at that position in the database field. This capability enables data enumeration and probing of values that were not originally exposed or searchable through normal application interfaces. Furthermore, this mechanism allows attackers to bypass security controls such as negated contains guards, effectively slipping past filters designed to exclude certain search terms by altering the pattern semantics rather than breaking the query syntax.
The operational impact of this vulnerability extends beyond simple data leakage. In scenarios where an attacker supplies a trailing lone backslash without a subsequent wildcard character, the malformed escape sequence can cause the database engine to fail in parsing the LIKE clause correctly. This leads to query execution errors that may result in application crashes or denial-of-service conditions for users relying on search functionality. Additionally, the ability to manipulate pattern matching logic facilitates unauthorized data access by allowing attackers to infer information about stored values through error-based or time-based techniques derived from successful versus failed wildcard matches. The vulnerability affects versions of ash_sql ranging from 0.1.1-rc.10 up to but not including version 0.7.1, indicating a long-standing issue in the library's handling of special characters within search parameters that has persisted across multiple releases until the patch was applied.
Mitigation strategies must focus on correcting the escape logic to ensure idempotency and proper sequence handling. The primary remediation is to upgrade ash_sql to version 0.7.1 or later, where this escaping flaw has been addressed. For environments unable to immediately update, a defensive coding approach involves pre-processing input strings to double any existing backslashes before applying the standard escape routine for wildcards. This ensures that an attacker-provided backslash is treated as data rather than part of an escape sequence, thereby preventing the unintended activation of subsequent wildcard characters. Security teams should also audit other areas of the application where LIKE clauses are constructed dynamically from user input to ensure consistent and robust escaping mechanisms are in place across all query generation logic. Monitoring logs for unusual patterns in search queries or database errors related to malformed string literals can aid in detecting exploitation attempts while patches are being deployed.