Between MarkLogic 11.3.6 and MarkLogic 11.3.4
- Last Updated: August 5, 2026
- 4 minute read
- MarkLogic Server
- Version 11.0
- Documentation
This section summarizes product changes in MarkLogic 11.3.6 that can cause compatibility issues for applications developed using MarkLogic 11.3.4 and earlier.
This section also includes issues introduced in the superseded MarkLogic 11.3.5 release.
MarkLogic 11.3.6 includes security fixes that change how certain privileges, amps, and execution contexts are evaluated compared to MarkLogic 11.3.4 and earlier. Applications that relied on unintentionally permissive behavior in these areas may be affected. Before upgrading production systems, test custom REST resources, transforms, SPARQL queries, Optic queries, and any workflows that depend on elevated privileges.
SQL xdmp_eval() and related functions now execute with ignore-amps in POST /v1/rows (CVE-2026-7329)
The SQL functions xdmp_eval(), xdmp_eval_in(), and related execution functions (available through SQL, GraphQL, SPARQL, and Optic through POST /v1/rows) were previously callable by any user with the rest-reader role with amped privileges, bypassing the xdbc-eval privilege gate enforced by POST /v1/eval. In MarkLogic 11.3.6, these functions remain available but now execute with the ignore-amps flag, which strips any amped privileges from the evaluation context. Privilege escalation through this path is no longer possible.
Spark Connector and Flux jobs that read data through POST /v1/rows may return different results if they previously relied on amped privileges. Applications using the Java Client API, Node.js Client API, or REST Client API that call these functions through POST /v1/rows with amped privileges will also be affected.
If your application calls xdmp_eval(), xdmp_eval_in(), or related SQL execution functions through POST /v1/rows and relies on elevated (amped) privileges, then those privileges will no longer apply after upgrading to MarkLogic 11.3.6. Review your queries and grant explicit privileges to the calling user, or use POST /v1/eval with the appropriate role assignments instead.
rest-admin can no longer set document-transform-out globally (CVE-2026-7327)
Users with the rest-admin role could previously set the document-transform-out server property through PUT /v1/config/properties, causing a named transform to automatically apply on every document read for all users, including administrators. In MarkLogic 11.3.6, rest-admin users who attempt to set document-transform-out receive a security exception (SEC-PRIV). This capability now requires an admin-level user.
Kafka and NiFi connector pipelines that apply server-side transforms during ingestion using a rest-admin identity may fail with SEC-PRIV errors. If your application uses a rest-admin account to configure document-transform-out as part of a legitimate workflow, then update your deployment or automation scripts to perform this configuration step using an admin-level user instead.
User-requested transforms are not affected and continue to run as the calling user.
Default REST transforms now run as rest-transform-user (CVE-2026-7327)
Beginning in MarkLogic 11.3.6, default REST transforms configured through document-transform-out no longer run as the calling user. They now execute as the built-in rest-transform-user to preserve the intended security isolation introduced by this fix.
-
This change applies only to default REST transforms configured on the server.
-
User-requested transforms are not affected. They continue to run as the calling user.
-
The
rest-transform-userintentionally has restricted privileges and document access.
Default REST transforms are no longer compatible with multi-statement transactions (CVE-2026-7327)
Due to the execution change introduced by the fix for CVE-2026-7327, default REST transforms can no longer be used within multi-statement transactions. The rest-transform-user execution model requires user-identity semantics that are incompatible with the same-statement execution required by multi-statement transactions.
Choose one of the following recommended actions:
-
Use an explicitly requested transform instead of a default REST transform within the transaction, OR
-
Restructure the transaction flow so that the default REST transform executes outside the multi-statement transaction.
REST PATCH replace-library @at restricted to /ext/ modules only (CVE-2026-8709)
The replace-library @at attribute in REST document PATCH descriptors previously accepted any module path. In MarkLogic 11.3.6, this attribute must begin with /ext/. Any value with a different prefix is rejected with RESTAPI-INVALIDREQ (HTTP 400).
Applications using the Java Client API, Node.js Client API, or REST Client API that issue PATCH operations whose replace-library @at attribute has a prefix other than /ext/ will receive HTTP 400 errors. If your application uses REST PATCH with custom replacement library modules stored outside the /ext/ path (for example, /my-app/patch/replacer.sjs), then move those modules into /ext/ before upgrading, and update any PATCH descriptor documents that reference the old paths. Modules already under /ext/ are unaffected.
HTTP requests with both Content-Length and Transfer-Encoding headers are rejected (CVE-2026-9190)
MarkLogic Server previously accepted HTTP requests that included both Content-Length and Transfer-Encoding headers simultaneously, which violates RFC 9112, Section 6.3.3 and enables HTTP request smuggling attacks.
In MarkLogic 11.3.6, any request that includes both headers receives HTTP 400 Bad Request. All standard HTTP clients (cURL, Java HTTP client, Python requests, and so on) send only one of these headers and are unaffected.
If you use a custom HTTP client, legacy middleware, or a hand-crafted load balancer configuration that sends both headers simultaneously, then update it to include either Transfer-Encoding: chunked or Content-Length but not both, as required by RFC 9112.
Selected command-line options for mlcp export and copy jobs and Hadoop Connector custom LexiconFunction expressions are restricted (CVE-2026-9193)
mlcp and the Hadoop Connector now validate user-supplied input to prevent XQuery injection. Two areas are affected:
- mlcp export and copy job command-line options: The following mlcp export and copy job options now validate their values:
-query_filter,-document_selector,-collection_filter,-directory_filter, and-path_namespace. Export and copy jobs that previously passed nonstandard expressions to any of these options may fail after upgrading. See Export Command Line Options and Copy Command Line Options in MarkLogic Content Pump (mlcp) for the standard format that each option accepts. - Hadoop Connector custom
LexiconFunctionoverrides: If your Hadoop Connector jobs implement a customLexiconFunction(overridinggetLexiconQuery()), then only the default valuects:and-query()is now allowed. Any form of custom override is rejected. The MarkLogic Hadoop Connector was deprecated in MarkLogic 10.0-5.
Any nonstandard expressions will be rejected, causing the following error codes: HADOOP-BADQUERY, HADOOP-BADDOCSELECTOR, HADOOP-BADNSBINDINGS.
Before upgrading, review any mlcp export and copy jobs that pass nonstandard values to the affected command-line options and any Hadoop Connector jobs that use custom LexiconFunction implementations. Contact Progress Support if you need assistance.