Between MarkLogic 12.1.0 and MarkLogic 12.0.3

This section summarizes product changes in MarkLogic 12.1.0 that can cause compatibility issues for applications developed using MarkLogic 12.0.3 and earlier.

User-supplied code execution is isolated from HTTP request, response, and session state (CVE-2026-9191)

MarkLogic Server now runs user-supplied code executed through REST and XDBC evaluation paths in an isolated context. Affected paths include /v1/eval, /eval, SPARQL, SQL, Optic/Rows, GraphQL, search evaluation/string evaluation, and REST patch processing. In those paths, request, response, and session built-ins now raise XDMP-ISOLATED. Installed REST extensions or transforms and /v1/invoke or XDBC /invoke remain unisolated by design.

Existing code in those paths will fail if it reads or changes request headers, fields, bodies, client details, session state, login or logout state, response controls, redirects, or request logs. Pre-commit triggers reached through an isolated transaction can fail for the same reason. Older mlcp versions are also incompatible and fail on xdmp:get-request-header("x-forwarded-for").

Inventory code executed through the affected APIs and move request, response, and session handling into a trusted outer layer, a supported REST extension/transform, or a non-isolated invoke path where appropriate. Upgrade mlcp to the version matching MarkLogic 12.1.0 before or with the MarkLogic Server upgrade. If an older mlcp version must be used temporarily, then set -restrict_hosts=true and test the resulting performance and fastload behavior.

Older mlcp versions can fail with XDMP-ISOLATED errors referencing xdmp:get-request-header("x-forwarded-for"). Using -restrict_hosts=true can reduce performance and affect fastload behavior and should be considered a temporary compatibility workaround.

XML external entity processing is disabled by default (CVE-2026-85970)

Starting in MarkLogic 12.1.0, external entity processing is disabled by default for XML parsing. Many externally sourced parsing paths are explicitly hardened, and some internally sourced paths remain hardened regardless of compatibility settings.

Applications or stylesheets that intentionally rely on external DTDs, external entities, or filesystem/network entity resolution may no longer receive expanded content after upgrading. Depending on the parsing context, the reference may be ignored or the operation may fail.

Remove dependencies on external entity resolution. If fully trusted content temporarily requires legacy behavior after upgrading, then use the Enable XML External Entities trace event only on the affected app server and only as a short-term compatibility escape hatch. Do not assume this re-enables all hardened internal parsing paths.

Forest attachment requires authorization for both the forest and the target database (CVE-2026-85947)

Forest attachment is now authorized against both the forest being attached and the target database receiving it. A forest-scoped administrative grant is no longer sufficient by itself to attach that forest to a caller-selected database.

Delegated automation that attaches forests using an identity authorized only for the forest will receive an authorization failure after upgrading.

Before upgrading, run forest attachment under an identity authorized for both the forest and the target database and review delegated forest and database privilege assignments.

Backup and restore enforce the actual database and forest scope (CVE-2026-85956)

Backup and restore requests are now authorized against the actual databases and forests named in the request rather than against only the database identified in the request URL.

Automation that previously performed backup or restore work across database boundaries using an identity scoped only to the URL database will now be rejected with an authorization failure.

Use an identity authorized for every database and forest actually touched by the operation and update any automation to stay within the correct owning-database boundary.

xdmp:eval-in() requires both evaluation privileges (CVE-2026-85955)

The xdmp:eval-in() function now requires both xdmp-eval-in and xdmp-eval. Previously, xdmp-eval-in alone was sufficient.

Applications or roles that call xdmp:eval-in() while holding only xdmp-eval-in will receive a privilege failure after upgrading. REST calls that use ?database= only to select a database context are not affected unless server-side code then calls xdmp:eval-in().

Audit roles that hold xdmp-eval-in, grant xdmp-eval only to trusted roles that legitimately require dynamic evaluation, and plan migration away from the deprecated xdmp:eval-in() function where possible.

Functions passed to helper APIs no longer inherit amp privileges (CVE-2026-85954)

Amps that leaked privileges into the execution of user-supplied code across the board have been removed. Wherever that code runs, amps from the REST API layer that previously leaked into that execution have been removed.

As a result, you may no longer have privileges that you previously had access to, because that access was incorrect. Review your code, as it may have been relying on privileges it did not correctly have.

Before upgrading, grant the explicit privileges that your application actually requires and replace caller-controlled dynamic function, module, or expression selection with allowlisted logic where feasible.

IMDS access requires a cloud-metadata privilege on affected Linux-based cloud deployments (CVE-2026-85952)

MarkLogic 12.1.0 adds cloud-agnostic IMDS protection on the shipped Linux-based cloud-detection path. Requests to IMDS endpoints are denied unless the caller holds cloud-http-protected or the legacy ec2-http-protected. The new cloud-protected-access role bundles cloud-http-protected, and existing ec2-protected-access and ec2-http-protected assignments continue to work.

After upgrading, service accounts or application code that legitimately query IMDS without either privilege will receive an authorization failure. On custom RPM-based Linux installations, the protection depends on curl being installed. Progress-provided AMIs, Docker images, and other packaged deployment artifacts already include it.

Grant a role containing cloud-http-protected or ec2-http-protected only to trusted identities that legitimately need IMDS access. Use cloud-protected-access for new assignments. For custom RPM-based Linux deployments, verify that curl is installed before or during upgrade.

Azure IMDS access requires a protected privilege (CVE-2026-85951)

On Azure-hosted deployments, access to the instance metadata service (IMDS) through xdmp:http-* is now blocked unless the caller holds a protected IMDS privilege. MarkLogic 12.1.0 introduces the cloud-agnostic cloud-http-protected privilege and cloud-protected-access role, while preserving the ec2-http-protected privilege and ec2-protected-access role for backward compatibility. Either privilege permits IMDS access.

After upgrading, Azure-hosted applications, extensions, or service accounts that legitimately query IMDS and do not hold either privilege will be denied access.

Before upgrading, identify every trusted identity that legitimately needs IMDS access. Following the upgrade, grant either the existing ec2-http-protected privilege or the new cloud-http-protected privilege (directly or through cloud-protected-access).

Existing ec2-http-protected grants continue to work, so reassignment is not required solely for compatibility.

Sensitive request headers require a new privilege (CVE-2026-85950)

Reading Authorization or Proxy-Authorization through xdmp:get-request-header() now requires the xdmp-get-request-header-sensitive execute privilege. In addition, xdmp:get-request-header-names() no longer returns those header names to callers that do not hold the privilege. No built-in role holds this privilege by default.

REST extensions, transforms, application-level Kerberos integrations, token-forwarding code, or other modules that read these headers will receive a privilege failure if the new privilege is absent. Code that only enumerates request headers may silently stop seeing Authorization and Proxy-Authorization.

Audit all code paths that read, forward, or test for these headers. Grant xdmp-get-request-header-sensitive only to trusted roles with a reviewed requirement to access raw authentication material.

FlexRep GET responses no longer return secrets (CVE-2026-85966)

Manage GET responses for FlexRep pull and target properties no longer return write-only secret values such as the stored password, client private key, and passphrase. Redacted GET responses can still be modified and sent back with PUT without clearing unchanged stored secrets.

Automation that reads or exports plaintext FlexRep secrets from GET responses will no longer find those values. Standard read-modify-write workflows that GET a configuration, edit non-secret fields, and PUT it back should continue to preserve existing secrets.

Stop relying on Manage GET responses to retrieve FlexRep secrets. Set or rotate those secrets through supported write or configuration workflows. Omit unchanged secret fields from PUT requests.

SAML assertions are validated more strictly (CVE-2026-85962)

For SAML-enabled deployments, MarkLogic Server now validates SAML assertions more strictly. The shipped changes restrict signature references to same-document references, validate NotBefore, and validate Issuer and Audience values against the configured identity-provider and service-provider settings when those values are configured.

After upgrading, SAML authentication can fail if an assertion uses a disallowed reference form, arrives before its valid time window, or does not match the configured SAML identity values. Correctly configured, standards-compliant assertions continue to work.

Before upgrading, test SAML authentication against the production identity provider, verify the configured identity-provider and service-provider values, confirm the signing certificate configuration, and ensure clocks are synchronized across the deployment.

Query Console rejects cross-origin eval requests (CVE-2026-85960)

Query Console no longer relies on a predictable cross-site request forgery (CSRF) token for eval operations and now uses Origin/Referer validation to reject cross-origin eval requests.

Browser automation or integrations that intentionally submit Query Console eval requests from another origin will be rejected. Normal same-origin Query Console use is unaffected.

Move automation to a supported API or keep it same-origin with Query Console.

Ping Identity and other OAuth configurations enforce iss and aud (CVE-2026-85958)

Issuer and audience validation now applies to affected Ping Identity and other OAuth resource-server configurations. Those checks previously applied to Microsoft Entra and AWS Cognito but not to the affected vendor types.

Authentication fails when a token's issuer or audience does not match the MarkLogic Server configuration or when a token issued for some other client or service is presented to MarkLogic Server.

Before upgrading, validate the identity provider (IdP) token claims and MarkLogic Server OAuth configuration. Then, before production cutover, test all affected login flows.

S3 defaults from HTTP to HTTPS (CVE-2026-85975)

The default S3 protocol changes from HTTP to HTTPS.

HTTP-only S3-compatible endpoints, endpoints with invalid or untrusted certificates, and deployments that never tested TLS for S3 may fail to connect after upgrading.

Before upgrading, enable and test HTTPS for every S3 or S3-compatible endpoint, install the required trusted certificates, and validate all production and failover paths.

New and rotated ErrorLog.txt and AuditLog.txt files use mode 0640 (CVE-2026-85971)

New and rotated ErrorLog.txt and AuditLog.txt files are created with mode 0640 instead of 0666. Existing files keep their current permissions until they are recreated or rotated.

Monitoring agents, support scripts, log collectors, or container sidecars that do not run as the MarkLogic Server user or approved group may receive operating-system permission failures after a log file is created or rotated.

Grant approved log readers the necessary MarkLogic Server group membership or equivalent operating-system access control lists (ACLs), and verify access after rotation and restart.

InfoStudio is removed and ticket-system artifacts change on upgrade (CVE-2026-85953)

InfoStudio is removed in MarkLogic 12.1.0. The info: and infodev: Admin API modules and the helper collector and transformer plugins under /Assets/plugins/marklogic/appservices/ are removed. The asynchronous ticket capability behind /manage/v2/tickets is preserved through a new ticket-system implementation with new security artifacts.

After upgrading, application code that imports or calls info: or infodev: modules or depends on the removed InfoStudio plugin paths will fail.

Upgrading also creates new ticket-system security artifacts. If your environment already defines manage-ticket-internal, manage-ticket-admin-internal, manage-ticket-task-runner, manage-ticket-admin-user, or manage-ticket-operations, then the upgrade can fail until those naming conflicts are resolved.

Existing /manage/v2/tickets integrations continue to work. On upgraded systems, an existing infostudio-user role is retained without its old privileges so that legacy ticket documents remain queryable.

Clusters containing legacy asynchronous Management API operation tickets can generate XDMP-MODNOTFOUND notices referencing removed InfoStudio modules after upgrade. These notices occur because legacy InfoStudio ticket-maintenance tasks and triggers remain in the configuration after their modules were removed. They are harmless and do not affect cluster stability, data, or core database functionality.

To update the stale module paths and prevent subsequent notices, run the following query once in Query Console, using the App-Services database and a user with the manage-admin role:

xquery version "1.0-ml";

import module namespace tkt =
  "http://marklogic.com/manage/ticket-system"
  at "/MarkLogic/manage/lib/ticket-system.xqy";

declare namespace info =
  "http://marklogic.com/appservices/infostudio";

let $ticket-id :=
  tkt:ticket-create(
    <info:annotation>
      Dummy ticket created to update ticket maintenance paths after upgrade.
    </info:annotation>
  )
let $_ := tkt:ticket-set-status($ticket-id, "completed")
return $ticket-id

Before upgrading, remove remaining InfoStudio dependencies; audit your Security database for naming conflicts with the new ticket-system roles, user, and privilege; and rename or remove conflicts. Do not remove or rewrite /manage/v2/tickets integrations solely because InfoStudio is being removed.

OpsDirector is removed (CVE-2026-85963)

OpsDirector is removed in MarkLogic 12.1.0. Remaining OpsDirector APIs and functionality are no longer available. Remaining OpsDirector integrations stop working.

If OpsDirector logging was configured at finest, then, before upgrading, reduce or disable it to avoid excessive log output during the upgrade process.

Before upgrading, remove OpsDirector dependencies.

/manage/v2/packages and related package export surfaces are removed (CVE-2026-85948)

The deprecated /manage/v2/packages REST API is removed in MarkLogic 12.1.0 with no flag or fallback to re-enable it. The related package export surface is also removed, including view=package on GET /manage/v2/databases/{id|name} and GET /manage/v2/servers/{id|name}.

Scripts, private forks, or runbooks that create, validate, compare, install, revert, or export packages through /manage/v2/packages or the related view=package query options will fail after upgrading.

Before upgrading, migrate to /manage/v3 (Configuration Management API), ml-gradle, or supported per-resource Manage API workflows. Audit custom automation and private forks for both /manage/v2/packages and view=package usage.

Optic API fragment query default behavior has changed

In MarkLogic 12.0.3 and earlier, the default behavior of op.fromSearch() and op.fromSearchDocs() was equivalent to specifying fragment: "any", which returns all matching fragments (document fragments, property fragments, and lock fragments). In MarkLogic 12.1.0, the default has changed to fragment: "document", which returns only document fragments and excludes property and lock fragments.

If your application depends on the previous behavior of retrieving all fragment types by default, then you must explicitly set the fragment option to "any" in your Optic queries to maintain backward compatibility.

AWS IAM secret values are removed from trace output (CVE-2026-85949)

When the affected IAM trace path is enabled, AWS secret key and session-token values are no longer written in plaintext by that trace output.

Diagnostic procedures, support bundles, or custom log parsers that previously expected those secret values in trace output will no longer see them. Normal AWS functionality is unchanged.

Update troubleshooting and log-processing procedures so that they do not rely on secrets appearing in trace output.

Query Console rejects unsafe filesystem paths (CVE-2026-85964)

Query Console now validates filesystem paths supplied to file-access operations and rejects paths that resolve outside the allowed directories, closing a path-traversal exposure.

Custom Query Console content that relied on unsupported traversal patterns or arbitrary server filesystem paths will fail validation after upgrading. Supported Query Console usage is not expected to change.

Update Query Console code to use only supported non-traversing relative paths and remove any dependency on arbitrary server filesystem reads through Query Console.

XML entity expansion is limited

MarkLogic 12.1.0 enforces limits on XML entity expansion. XML documents that exceed the limit fail with XDMP-DOCMAXENTITY. Applications that ingest XML containing large or repeatedly expanded entities should be tested before upgrade and may require content changes to remain compatible.

Default TLS cipher configuration excludes weak ciphers

MarkLogic 12.1.0 removes low-strength TLS ciphers from the default cipher configuration used by affected TLS-enabled connection paths.

Legacy XDBC, ODBC, and other TLS-enabled clients that rely on deprecated or weak cipher suites may fail to negotiate TLS connections after upgrading. Modern TLS clients are not expected to be affected.

Before upgrading, test XDBC, ODBC, and other TLS-enabled client connections against the target release. If a legacy client cannot be upgraded immediately, then explicitly configure an appropriate cipher list for your environment.

Password-based Kerberos verifies initial credentials (CVE-2026-85972)

In the password-based Kerberos external-security path (authentication: kerberos with app server basic or digest authentication), MarkLogic Server now verifies the KDC-issued initial credentials against the configured service principal and keytab. If no keytab is available, then MarkLogic Server logs a warning and skips the verification rather than hard-failing.

Only deployments using this password-based Kerberos path are expected to see a customer-visible change. Incorrect KDC, DNS, service-principal, or keytab configuration can now cause authentication failure in that path. Deployments using the normal kerberos-ticket/SPNEGO path are not expected to see a behavior change from this fix.

Before upgrading, verify KDC, DNS, service-principal, and keytab configuration for password-based Kerberos deployments.

No compatibility action is required for environments that use only kerberos-ticket/SPNEGO.