ash_sql CVE-2026-78691

Exploitation requires that the target application passes user-controlled string input directly - without stripping or rejecting backslash characters - to ash_sql's contains/2, string_starts_with/2, or string_ends_with/2 filter functions on a column backed by a SQL LIKE expression. The attacker must supply a backslash immediately preceding a % or _ character (e.g., \%) to defeat the escape helper, or a trailing lone backslash to trigger the DoS variant. Authentication requirements are entirely determined by the host application's own access controls; ash_sql itself imposes none, and the provided CVSS PR:N confirms no privilege elevation is needed within the library layer. Exploitation is structurally limited to LIKE pattern manipulation - the query remains parameterized, preventing breakout to arbitrary SQL. Applications that do not expose these three filter functions to user-supplied input are unaffected, as are versions 0.7.1 and later.

The CVSS 4.0 score of 2.1 (Very Low) accurately reflects the narrow blast radius: the search value stays parameterized, so this cannot escalate to arbitrary SQL execution. Real-world impact is bounded to three concrete outcomes: widening a LIKE match to retrieve unintended rows (limited information disclosure), bypassing a negated contains() guard in application-layer access checks, or crashing a query with a trailing lone backslash (low-severity DoS). The DoS path may be the most operationally impactful, as it requires only a single character and can be triggered repeatedly. EPSS data is not available for independent comparison. The vulnerability is not listed in CISA KEV and no public exploit code has been identified, consistent with limited active exploitation. One notable inconsistency: the provided CVSS 4.0 vector assigns AV:L (Local), which conflicts with a user-supplied search-term attack surface that is almost certainly network-reachable in typical Ash application deployments - verify the AV metric with the EEF reporter before using the vendor score for prioritization. AT:P (attack requirement present) is well-grounded: only applications that pass raw user input to the three affected filter functions are exposed.

An attacker submits the search string \% (backslash followed by percent) to any application endpoint that feeds user input into an ash_sql contains/2 filter - for example, a product search or user lookup form; the broken escape logic in AshSql.Expr transforms this into \\%, which the underlying SQL engine interprets as a literal backslash plus an unescaped wildcard, causing the query to match far more rows than intended and potentially leaking records the application was designed to restrict. For the availability variant, submitting a search string that ends with a lone backslash produces a malformed LIKE pattern that the database rejects with a syntax error, crashing the query for that request. No public exploit code was identified at time of analysis, but the technique is trivially derivable from the public description and commit diff.