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.

Incorrect Authorization vulnerability in ash-project ashsql allows a caller to bypass a scoping or authorization filter expressed as exists/2 over a relationship that declares both a limit (or frommany?) and a parent(...)-referencing filter or sort.

AshSql.Join.relatedquery/3 skips the caller-supplied exists predicate for such relationships and delegates it to limitfrommany/5. When the relationship's own filter or sort references parent(...), limitfrommany/5 takes a branch that drops both the limit and the predicate, emitting a bare correlated EXISTS with no predicate. The check then matches any record that has any related row. Most severely, when the expression backs a policy (for example authorizeif expr(exists(memberships, userid == ^actor(:id)))), the actor-scoping condition disappears and the policy passes for any actor with any related row.

This issue affects ashsql: from 0.4.1 before 0.7.1.