Marten Full-Text Search SQL Injection via Unparameterized regConfig

Vulnerability Description

This is a classic first-order SQL injection vulnerability arising from unsafe string interpolation in the FullTextWhereFragment class. The root cause is the direct embedding of the regConfig parameter (PostgreSQL text search configuration name) into a parameterized SQL template without escaping or parameterization. The vulnerable code path: $"to_tsvector('{_regConfig}'::regconfig, ...)" treats user input as a SQL literal, allowing quote-escape termination. Impact is severe: an attacker controlling regConfig can execute arbitrary PostgreSQL commands with the privileges of the application's database user, including data exfiltration, modification, deletion, or denial of service.

PoC Significance

The disclosed PoC payloads (time-based blind SQL injection via pg_sleep() and information disclosure via version()) are reliable and require minimal preconditions—only network access to an application accepting untrusted input in any of the five exposed APIs. These payloads prove the vulnerability is exploitable without authentication bypass and don't depend on specific PostgreSQL extensions. The PoC demonstrates both proof-of-presence (blind exfiltration) and proof-of-concept exploitation, making it immediately actionable for threat actors.

Detection Guidance

Log Indicators: Search application logs and PostgreSQL slow-query logs for:

• Unusual pg_sleep(), pg_catalog, or system function calls in query patterns
• Requests with regConfig parameters containing ', --, ;, or URL-encoded variants (%27, %2D%2D)
• PostgreSQL error logs showing syntax errors with incomplete SQL fragments (sign of quote injection)

Network Signatures: Monitor for:

• HTTP/API requests with regConfig parameters deviating from expected PostgreSQL config names (e.g., english, simple, french)
• Payloads matching regex: regConfig=.*['";\-\-] or containing database function calls

Vulnerability Scanning: Marten applications using versions prior to patched release are exploitable if search APIs are exposed to untrusted input (web endpoints, APIs, message queues).

Mitigation Steps

Immediate Actions:

1. Patch: Upgrade to the patched Marten version (when released) that uses parameterized queries or allowlist validation for regConfig
2. Input Allowlist: If patching is delayed, enforce strict allowlist validation on regConfig input to only permit known PostgreSQL text search configurations (english, simple, french, german, spanish, etc.) via regex ^[a-z_]+$
3. Network Segmentation: Restrict database user permissions to least-privilege; remove EXECUTE and CREATE permissions if not required
4. WAF Rules: Block requests where regConfig contains SQL metacharacters or unexpected characters

Long-term:

• Conduct code review for similar string interpolation anti-patterns in LINQ/ORM layers
• Implement static analysis tooling to flag unchecked user input in SQL generation contexts

Risk Assessment

Likelihood of Exploitation: High. This is a easily-discoverable, low-barrier-to-entry vulnerability requiring only network access; no authentication or special knowledge of Marten internals is needed. PoC payloads are straightforward. Threat actor interest will be immediate upon disclosure.

In-the-Wild Risk: Critical for organizations using Marten with public-facing APIs or multi-tenant inputs; moderate risk for internal tools if search APIs are accessible from less-trusted network segments. The vulnerability affects all Marten versions prior to patching; adoption rates across .NET ecosystem make this a wide-impact issue.

Incident Response Priority: Treat as P1—execute immediate inventory of Marten deployments and apply patches/workarounds within 24–48 hours.