The flaw is a failure to properly neutralize the backslash character in the input passed to AshSql’s LIKE predicate. The escaping helper prefixes % and _ with a backslash, but it leaves any pre‑existing backslashes untouched. Because backslash is the default LIKE escape character, a payload such as \\% expands to the literal string \\\\% – the first two backslashes denote a single literal backslash, and the following % is interpreted as a pattern wildcard. This turns a seemingly safe substring search into a wildcard containing search that an attacker can control. The search value remains bound as a parameter so the attack does not scale to full SQL injection, but it does allow the attacker to broaden matches, sidestep negated contains checks, or even cause the query to fail if a lone backslash terminates the pattern.

ash-project ash_sql versions from 0.1.1‑rc.10 up to but not including 0.7.1 are affected. The vulnerability is present in the string search predicates contains/2, string_starts_with/2, and string_ends_with/2.

The CVSS score of 2.1 indicates a low impact. The EPSS score is not available, and the vulnerability is not listed in CISA’s KEV catalogue. An attacker requires the ability to supply search terms to the affected functions, which typically means having access to the application’s interface or API. Because the flaw only affects the LIKE pattern grammar, the attack gains only limited capabilities: the attacker can broaden matches, bypass negated filters, or destabilize the query with malformed input. The overall risk is moderate to low but still warrants mitigation because it can be used for data enumeration or denial of service in high‑volume search contexts.