CVE-2026-75513 in Marten
Summary
by MITRE • 09/17/2026
Marten is a .NET Transactional Document DB and Event Store on PostgreSQL. From version 7.0.0 until 9.13.0, several Marten LINQ and tenant-management paths interpolate runtime, potentially attacker-controlled strings into single-quoted SQL literals without escaping or parameterization. The primary confirmed vector is a dictionary indexer key used by Where filters in src/Marten/Linq/Members/Dictionaries/DictionaryItemMember.cs. Additional affected sinks include SelectParser.cs, DatabaseScopedTenantPartitions.cs, and DeleteAllForTenant.cs reached through IEventStore.DeleteProjectionProgressAsync, while DictionaryContainsKeyFilter.cs (Newtonsoft serializer only; System.Text.Json is not affected) handles ContainsKey calls. Events/Daemon/Internals/EventLoader.cs contains a related per-tenant partition-pruning literal that the advisory identifies as a defense-in-depth sink. A crafted single quote can escape the generated literal, enabling filter or multi-tenant authorization bypass and blind data exfiltration, and deployments that permit semicolon-batched Npgsql statements may also allow data modification. This issue is fixed in version 9.13.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
Marten, a transactional document database and event store built on PostgreSQL, suffered from significant SQL injection vulnerabilities affecting versions ranging from 7.0.0 through 9.13.0. The core technical flaw resides in the library's LINQ query translation engine and tenant management subsystems, which improperly handled string interpolation for runtime values that were potentially controlled by an attacker. Specifically, these components interpolated user-supplied strings directly into single-quoted SQL literals without applying necessary escaping or utilizing parameterized queries. This architectural weakness allowed malicious actors to manipulate the structure of generated SQL statements, bypassing intended security controls and data access restrictions inherent in the application layer.
The primary attack vector identified involves dictionary indexer keys utilized within Where filters located in the DictionaryItemMember.cs module. By supplying a crafted single quote character as part of a filter key or value, an attacker could escape the surrounding string literal context. This technique enables classic SQL injection patterns where subsequent clauses can be appended to the original query. Additional vulnerable sinks include SelectParser.cs and DatabaseScopedTenantPartitions.cs, which are accessible through methods such as IEventStore.DeleteProjectionProgressAsync. Furthermore, DictionaryContainsKeyFilter.cs presents a vulnerability specifically when using the Newtonsoft serializer, although this specific path is not affected in environments relying solely on System.Text.Json. A related defense-in-depth sink exists within EventLoader.cs regarding per-tenant partition-pruning logic, indicating that multiple layers of query construction were susceptible to similar injection techniques.
The operational impact of these vulnerabilities is severe, encompassing both unauthorized data access and potential system compromise. The ability to escape SQL literals facilitates filter bypasses, allowing attackers to retrieve data they should not have access to based on application-level permissions. More critically, the vulnerability enables blind data exfiltration, where sensitive information can be extracted even without direct error feedback from the database server. In deployments configured with Npgsql settings that permit semicolon-batched statements, an attacker could execute multiple SQL commands in a single request. This capability extends the impact beyond read-only operations to include arbitrary data modification and potential destruction of records within the PostgreSQL backend.
This issue is classified under CWE-89 as Improper Neutralization of Special Elements used in an SQL Command, reflecting the failure to properly sanitize user input before its inclusion in database queries. From a tactical perspective, this aligns with ATT&CK technique T1059.004, specifically command and scripting interpretation via SQL commands, which adversaries use to interact directly with backend databases for data staging or exfiltration. The vulnerability highlights the risks associated with dynamic query generation frameworks that rely on string concatenation rather than parameterization. To mitigate this risk, organizations must upgrade Marten to version 9.13.0 or later immediately. Additionally, database administrators should ensure that Npgsql connection strings are configured to disable batched statement execution by setting BatchSize to one or disabling the feature entirely if not strictly required for performance optimization, thereby neutralizing the ability to execute multiple commands in a single injection payload even if other vulnerabilities exist.