CVE-2026-78691: Unescaped backslash allows LIKE wildcard injection in AshSql string search
Improper Neutralization of Special Elements in Data Query Logic vulnerability in ash-project ashsql allows a user who supplies a search term to contains/2, stringstartswith/2, or stringendswith/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 ashsql: from 0.1.1-rc.10 before 0.7.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash_sqlto a version that resolves this vulnerability.Fixed in 0.7.1
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using affected ash_sql versions from 0.1.1-rc.10 before 0.7.1 are exposed where untrusted users can supply search terms to contains/2, string_starts_with/2, or string_ends_with/2.
What does an attacker need to exploit it?
An attacker needs control of a search value passed to one of the affected string-search functions. Supplying a backslash before SQL LIKE wildcard characters can leave % or _ active as pattern wildcards; a trailing lone backslash can also cause the query to fail.
Does this enable full SQL injection?
No. The search value remains parameterized, so the issue is limited to manipulation of SQL LIKE pattern semantics rather than injection of arbitrary SQL.
What is the remediation?
Upgrade ash_sql to version 0.7.1 or later. If upgrading is not immediately possible, avoid passing untrusted input directly to the affected functions or ensure backslashes are escaped before the value reaches their LIKE-pattern escaping logic.
How can this affect application behavior?
An attacker may widen search results to probe for values, bypass logic that relies on a negated contains(...) condition, or trigger query errors using a trailing backslash.