Summary
The get_filter_string function in src/alerts/alerts_utils.rs does not properly escape user-provided values when building SQL filter strings. Specifically, in list_condition_expr, the inner_value parameter is directly interpolated into SQL expressions (e.g., ARRAY[{inner_value}]) without escaping or sanitization, allowing crafted input to break out of the ARRAY context and inject arbitrary SQL.
Steps to Reproduce / Exploit
A user-supplied condition value such as 1] OR 1=1; -- would be embedded verbatim, producing:
which alters the query logic.
The resulting filter string is then directly concatenated into WHERE clauses (e.g., in the log context query builder added in PR #1687), rather than being passed as a parameterized binding.
Affected Files
src/alerts/alerts_utils.rs — get_filter_string, list_condition_expr, scalar_condition_expr
Recommended Fix
- Escape all user-supplied string values before interpolation (e.g., escape single quotes, bracket characters used in ARRAY literals).
- Or refactor to use parameterized / prepared query execution instead of raw string concatenation.
References
/cc @nikhilsinhaparseable
Summary
The
get_filter_stringfunction insrc/alerts/alerts_utils.rsdoes not properly escape user-provided values when building SQL filter strings. Specifically, inlist_condition_expr, theinner_valueparameter is directly interpolated into SQL expressions (e.g.,ARRAY[{inner_value}]) without escaping or sanitization, allowing crafted input to break out of the ARRAY context and inject arbitrary SQL.Steps to Reproduce / Exploit
A user-supplied condition value such as
1] OR 1=1; --would be embedded verbatim, producing:which alters the query logic.
The resulting filter string is then directly concatenated into WHERE clauses (e.g., in the log context query builder added in PR #1687), rather than being passed as a parameterized binding.
Affected Files
src/alerts/alerts_utils.rs—get_filter_string,list_condition_expr,scalar_condition_exprRecommended Fix
References
/cc @nikhilsinhaparseable