GHSA-vmw2-qwm8-x84c Marten has an injection vulnerability in its full-text search regConfig parameter

• NuGet Marten: < 8.37.0 → fixed in 8.37.0

Summary Marten's full-text search APIs interpolated the user-supplied `regConfig` parameter directly into the generated SQL without parameterization or validation, making every code path that exposes `regConfig` to untrusted input a SQL injection sink. Affected APIs • `IQuerySession.SearchAsync(string searchTerm, string regConfig, ...)` • `IQuerySession.PlainTextSearchAsync(...)` • `IQuerySession.PhraseSearchAsync(...)` • `IQuerySession.WebStyleSearchAsync(...)` • `IQuerySession.PrefixSearchAsync(...)` • `IQueryable.Where(x => x.Search(term, regConfig))` and the matching `PlainTextSearch` / `PhraseSearch` / `WebStyleSearch` / `PrefixSearch` extension methods Details In the affected versions, `FullTextWhereFragment` renders the WHERE-clause SQL by string interpolation: ```csharp private string Sql => $"to_tsvector('{_regConfig}'::regconfig, {_dataConfig}) @@ {_searchFunction}('{_regConfig}'::regconfig, ?)"; ``` `_regConfig` arrives unchanged from the public API surface above. Any value containing a single quote terminates the SQL literal and lets an attacker append arbitrary PostgreSQL. Confirmed exploit shapes (with `regConfig` set to attacker-controlled input) | Goal | Payload | | --- | --- | | Time-based blind | `english'::text); SELECT pg_sleep(5); --` | | Information disclosure | `english'; SELECT version(); --` | | DDL execution | `english'; DROP TABLE mt_doc_article; --` | All five overloads listed above produced SQL containing the verbatim payload. Impact • Confidentiality: an attacker can append arbitrary `SELECT` statements and exfiltrate database contents through error channels, response timing, or — if the application surfaces query results — directly. • Integrity / Availability: DDL, `UPDATE`, `DELETE`, and `pg_sleep`-style denial-of-service payloads succeed under the same vector. Concrete impact depends on the database role used by the Marten connection string. • Precondition: the calling application must forward attacker-controlled input into the `regConfig` parameter (e.g. a `?lang=` query string mapped to `regConfig`). Applications that hard-code `regConfig` to a compile-time constant are not exploitable. Patches Fixed in Marten 8.36.1 (and forward) by #4343. `FullTextWhereFragment` now validates `regConfig` against `^[a-zA-Z_][a-zA-Z0-9_]*(\.[a-zA-Z_][a-zA-Z0-9_]*)?$` (a simple PostgreSQL identifier, optionally schema-qualified, capped at `NAMEDATALEN-1` per side) and throws `ArgumentException` for anything else. The default value (`"english"`), schema-qualified configs (`"pg_catalog.english"`), and the standard PostgreSQL text-search configurations all continue to work. Workarounds If users cannot upgrade immediately, do one of the following at the application boundary: 1. Hard-code `regConfig` to a compile-time constant (`"english"`, `"simple"`, …) and never accept it from request input. 2. Validate any externally-sourced `regConfig` value before passing it to Marten — e.g. against the same regex as the patch (`^[a-zA-Z_][a-zA-Z0-9_]*(\.[a-zA-Z_][a-zA-Z0-9_]*)?$`) or against an allowlist of PostgreSQL configurations the application actually uses. 3. Drop the `regConfig` argument from the call site so Marten falls back to the safe default. Resources • Patch PR: JasperFx/marten#4343 • Patched file: `FullTextWhereFragment.cs` • Regression tests: `full_text_regconfig_sql_injection.cs` • CWE-89: Credit Reported privately to the JasperFx team with a working proof of concept covering all five affected overloads.