CVE-2026-80227: SQL string_trim removes only spaces, diverging from in-memory trimming in AshSql
Incorrect Comparison vulnerability in ash-project ashsql 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 stringtrim/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 ashsql: from 0.1.0 before 0.7.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ash_sqlto a version that resolves this vulnerability.Fixed in 0.7.1 - Configuration
Do not use AshSql string_trim/1 to gate trimmed uniqueness/equality when the application expects String.trim/1 semantics; instead, ensure the comparison normalizes tabs/newlines/carriage returns/form feeds consistently on both SQL and in-memory paths.
Elixir/AshSql comparisons that use string_trim/1 string_trim/1 SQL pushdown vs in-memory trimming behavior = Avoid relying on string_trim/1 for uniqueness/equality checks where DB and in-memory trimming differ
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using ash_sql versions from 0.1.0 before 0.7.1 are affected if they use string_trim/1 in Ash filters, validations, or identities. The practical impact applies where values containing tabs, newlines, carriage returns, or form-feed characters can reach those expressions.
What does an attacker need to do to exploit the inconsistency?
An attacker needs to submit a string padded with non-space whitespace characters such as a tab, newline, carriage return, or form feed. This can cause a database-pushed string_trim/1 check to produce a different result than the equivalent in-memory evaluation.
What should be done if upgrading is not immediately possible?
Avoid relying on string_trim/1 for security- or integrity-relevant equality, uniqueness, identity, or validation checks where non-space whitespace may be accepted. Normalize or reject tab, newline, carriage-return, and form-feed characters before those checks so database and in-memory behavior cannot diverge.
How can I determine whether an application may already be affected?
Review Ash filters, validations, and identities for use of string_trim/1, then test those paths with values padded by tabs, newlines, carriage returns, and form feeds. Compare behavior when the expression is evaluated through SQL versus in memory, especially for uniqueness and equality decisions.