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).
string_trim/1 compiles to REGEXP_REPLACE 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.
string_trim/1 compiles to REGEXP_REPLACE 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.
Advisories
No advisories yet.
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Sun, 30 Aug 2026 12:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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). string_trim/1 compiles to REGEXP_REPLACE 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. | |
| Title | SQL string_trim removes only spaces, diverging from in-memory trimming in AshSql | |
| First Time appeared |
Ash-project
Ash-project ash Sql |
|
| Weaknesses | CWE-697 | |
| CPEs | cpe:2.3:a:ash-project:ash_sql:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Ash-project
Ash-project ash Sql |
|
| References |
| |
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: EEF
Published:
Updated: 2026-08-30T11:53:35.548Z
Reserved: 2026-08-30T05:45:01.813Z
Link: CVE-2026-80227
No data.
Status : Received
Published: 2026-08-30T12:17:18.710
Modified: 2026-08-30T12:17:18.710
Link: CVE-2026-80227
No data.
OpenCVE Enrichment
Updated: 2026-08-30T13:30:05Z
Weaknesses