Marten LINQ Provider SQL Injection via Unescaped Dictionary-Key Filters (CVE-2026-75513)

A new GitHub Security Advisory (GHSA-rfx3-98h7-v3xp, CVE-2026-75513, CVSS 9.1) discloses a SQL injection vulnerability in Marten, a .NET document database and event store built on PostgreSQL. According to the advisory, several code paths in Marten's LINQ provider and tenant-management internals interpolate a runtime, potentially attacker-influenced value directly into generated SQL as an unescaped single-quoted string literal.

What was reported

The primary and PoC-confirmed vector is the key argument of a Dictionary<,> indexer used in a LINQ Where filter — e.g. Where(x => x.Attributes[key] == v) — a common "filter by attribute name" (EAV) pattern. The advisory demonstrates that a benign key like "nonexistent-key" returns zero rows, while a crafted key such as "nonexistent' = '' or 1=1 --" breaks out of the SQL literal and returns all rows. Additional affected sinks are listed, including DictionaryContainsKeyFilter (Newtonsoft serializer only), a constant string reaching SelectParser, tenant-id handling in DeleteAllForTenant, and tenant-id interpolation into partition DDL in DatabaseScopedTenantPartitions. The vendor's fix escapes embedded single quotes or, where possible, binds values as parameters, and the advisory notes it was reported privately by an external researcher with an executed proof-of-concept, with more sinks surfaced during a follow-up LINQ-wide audit.

Why it matters for defenders

Marten is used as an application-level document store and event store, so this isn't a perimeter-facing web vulnerability — exposure depends entirely on whether application code passes untrusted input into a dictionary-key filter, a ContainsKey check, a Select projection constant, or a tenant identifier. Per the advisory, successful exploitation of the primary vector yields filter and multi-tenant authorization bypass (reading other tenants' rows) and blind data exfiltration; where an application allows Npgsql's default ;-batched multi-statement commands, data modification is also possible. Multi-tenant SaaS applications built on Marten's tenancy features are the highest-risk population, since tenant-id sinks are explicitly called out.

What defenders should watch for now

• Inventory application code for LINQ queries against Marten documents that use a dictionary indexer key, ContainsKey, or a Select projection sourced from user-controlled input, and treat any such input path as untrusted until patched.
• Review multi-tenant deployments for any place a tenant identifier flows into projection teardown (DeleteProjectionProgressAsync) or partition provisioning — these are called out as sinks independent of the primary EAV vector.
• As an interim mitigation, per the advisory: avoid passing untrusted input as a dictionary indexer key/ContainsKey argument/Select constant or as a tenant id in teardown/provisioning paths, and disable Npgsql multi-statement command batching to reduce the impact of any successful injection.
• At the database layer, hunt for anomalous query patterns against mt_doc_* tables — unexpected OR 1=1-style conditions, unusually broad result sets from narrow filters, or cross-tenant row access in application logs — as a compensating detection while patching is rolled out.
• Prioritize upgrading to the patched Marten release referenced in the advisory, which escapes or parameterizes each identified sink.

This is developing, net-new intelligence based solely on the GitHub Security Advisory published today; details may be refined as the vendor and community respond. See the original advisory for full technical detail and remediation guidance: GHSA-rfx3-98h7-v3xp.