Incorrect Comparison vulnerability in ash-project ash_sql allows a user to pad a string field with tab, newline, carriage-return, or form-feed characters and pass a trimmed uniqueness or equality check in the database that the same expression would fail in memory (or the reverse).
stringtrim/1 compiles to REGEXPREPLACE patterns built from an Elixir string in which \s is the escape for a single space (codepoint 32), not a regex whitespace class. The generated SQL therefore removes only literal spaces and leaves tabs, newlines, carriage returns, and form feeds in place, whereas String.trim/1 in Elixir removes them all. Any Ash filter, validation, or identity that relies on string_trim/1 then behaves differently depending on whether Ash pushes the expression down to SQL or evaluates it in memory, so padded input can register a near-duplicate value or slip past a trimmed comparison.
This issue affects ash_sql: from 0.1.0 before 0.7.1.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80227.json",
"unresolved_ranges": [
{
"source": "AFFECTED_FIELD",
"extracted_events": [
{
"introduced": "dd092ed273dec7bd2194352f24a39229fc8ae68b"
},
{
"fixed": "1b11b5d8bc5321e2e6acac21594ef08f61986117"
}
]
}
],
"cna_assigner": "EEF",
"cwe_ids": [
"CWE-697"
]
}