Am I affected?
Description
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.
Weaknesses & attack patterns
Weakness
CWE-943
·
Improper Neutralization of Special Elements in Data Query Logic
in catalog →
MITRE ↗
Attack patterns
CAPEC-116
·
Excavation
MITRE ↗
Affected — Hex / ash_sql Hex.pm ↗ Repository ↗
modules · source files · routines
Affected — GitHub / ash-project/ash_sql Repository ↗
modules · source files · routines
Configurations
An application must pass untrusted input as the search term of contains/2, string_starts_with/2, or string_ends_with/2 (for example a user-controlled substring search).
References
GHSA-5jgp-7mhc-6qqh ↗
vendor-advisory
EEF-CVE-2026-78691 ↗
related
Credits
CVSS breakdown
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N