A severe vulnerability discovered in Marten, a highly popular .NET transactional document store and event store library, could allow attackers to execute arbitrary database commands and read sensitive server records.
The security hole, tracked as CVE-2026-45288, carries a CVSS severity score of 9.8. Because Marten is actively relied upon by .NET developers to turn PostgreSQL into a fully fledged ACID-compliant document database and event store, this vulnerability poses an immediate risk to applications exposing full-text search parameters to untrusted input.
The flaw lies deep within Marten’s full-text search engine API components, specifically affecting the FullTextWhereFragment class.
When developers implement advanced text searching, Marten provides a regConfig parameter to define the text-search configuration (such as language dictionaries like “english” or “simple”). However, researchers discovered that Marten’s internal engine handled this parameter via direct string interpolation into the generated SQL query rather than executing a parameterized or validated database query.
The affected underlying query construction code was revealed to render the SQL WHERE-clause string as follows:
Because _regConfig is placed directly inside the string literals, any endpoint or application query string (e.g., ?lang=) that maps user input directly into that parameter turns into a direct SQL injection sink.
An attacker who identifies an application routing raw input into a vulnerable Marten search API can break completely out of the intended full-text search function. By appending custom PostgreSQL commands, an adversary can achieve:
- Data Exfiltration and Destruction: Executing unauthorized UPDATE or DELETE statements on business-critical collections.
- Schema Subversion: Modifying underlying database architectures via Data Definition Language (DDL) injections.
- Denial of Service (DoS): Triggering forced query delays using pg_sleep()-style payloads to completely tie up database connection pools.
The ultimate blast radius of the exploit depends entirely on the privileges and database roles assigned to the connection string utilized by the host .NET application.
The flaw specifically threatens any application calling the following asynchronous lookup methods or syntax extensions when passing an untrusted variable to regConfig:
- IQuerySession.SearchAsync<T>(string searchTerm, string regConfig, …)
- IQuerySession.PlainTextSearchAsync<T>(…)
- IQuerySession.PhraseSearchAsync<T>(…)
- IQuerySession.WebStyleSearchAsync<T>(…)
- IQuerySession.PrefixSearchAsync<T>(…)
- The matching IQueryable<T>.Where(x => x.Search(term, regConfig)) LINQ extension methods.
The Marten maintainers have quickly addressed the vulnerability in Marten version 8.36.1 and later via patch pull request #4343.
The remediation updates the FullTextWhereFragment logic to strictly validate the incoming regConfig argument against a defensive regular expression before appending it to the query engine:
This regex limits the parameter strictly to a standard, clean PostgreSQL identifier (optionally schema-qualified) and throws an ArgumentException if any unexpected or malicious characters are detected.
For engineering teams unable to deploy an immediate package upgrade to production due to verification cycles, the advisory outlines two distinct workarounds that must be applied at the application validation boundary:
- Hard-Code Configuration: Lock the regConfig parameter to a strict compile-time constant string literal (such as “english” or “simple”) and remove any capability for the API layer to accept this configuration dynamically from incoming web requests.
- Implement Manual Input Filtering: If your application genuinely requires dynamic language configurations from end-users, you must manually validate the request input at your controller boundary. Cross-reference the user input against a hardcoded internal allowlist of standard PostgreSQL text-search configurations or validate it against the exact regex utilized by the official patch before invoking Marten’s search APIs.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.