Progress issues fixes for 31 MarkLogic Server vulnerabilities

Progress Software has disclosed 31 vulnerabilities in its MarkLogic Server database, including five rated critical. The company released fixes on September 10 in MarkLogic 11.3.7 and MarkLogic 12.1.0, before publishing the CVE records on October 12.

Customers running MarkLogic 11.x before 11.3.7 should upgrade to 11.3.7. Those on MarkLogic 12.x before 12.1.0 should move to 12.1.0. MarkLogic 11.3 is the long-term support line, while the 12 series is an innovation release; Progress has not issued a patched 12.0 version.

Delegated privileges can become persistent control

Three of the critical issues have a CVSS score of 9.9 and two score 9.6. Progress says exploitation of each requires an existing privilege or a means to run code on the server, rather than anonymous access.

CVE-2026-85947 affects users with forest-management privileges and could enable creation of a persistent administrator account. CVE-2026-85948 could give an account with manage-user-level privileges persistent administrative control through XQuery injection in a deprecated Management API path.

The remaining critical findings are CVE-2026-85955, which could permit elevated server-side code execution for an account with query execution access and the xdmp-eval-in privilege; CVE-2026-85956, which concerns backup and restore of forests outside a delegated database; and CVE-2026-9191, involving certain REST and XDBC evaluation paths that could enable unauthorized actions or compromise an authenticated session.

A forest in MarkLogic is a collection of documents attached to a database. The fix for CVE-2026-85947 changes forest attachment checks so a forest-scoped administrative grant alone is no longer sufficient to attach a forest to a database selected by the account.

Configuration-dependent exposure and upgrade changes

Progress rated 24 of the other findings high and two medium. The highest of them, CVE-2026-85954 with a score of 8.6, could allow more privileges than intended through values passed to certain XQuery functions.

Other vulnerabilities apply in particular configurations, including SAML, OAuth, password-based Kerberos, Azure and Linux cloud deployments, Amazon S3 connections, Query Console, OpsDirector and InfoStudio. The upgrade notes state that AWS secret keys and session tokens could be written in plaintext when an affected IAM trace path was enabled. They also describe flaws that could expose sensitive information in diagnostic logs, accept inappropriate authentication tokens, or enable access to internal cloud services.

Both updated releases alter operational behaviour. XML external entity processing is disabled by default, S3 connections default to HTTPS, and newly created or rotated ErrorLog.txt and AuditLog.txt files use mode 0640 rather than 0666. Existing log files retain their old permissions until they are rotated or recreated.

Progress has removed the /manage/v2/packages API, InfoStudio and OpsDirector. The updated releases also require both xdmp-eval-in and xdmp-eval privileges for xdmp:eval-in(), add checks across every forest and database touched by attachment, backup and restore operations, and require a new privilege to read Authorization headers.

Patch testing needs to include prior remediation

Applying the fixes released for 10 MarkLogic flaws in August is insufficient: MarkLogic 11.3.6 and 12.0.3, which addressed that earlier batch, are affected by the newly disclosed issues. Progress says customers should review the incompatibility notes for 11.3.7 or 12.1.0 before deployment.

Older MarkLogic Content Pump versions can fail against the new releases with an XDMP-ISOLATED error. Progress recommends mlcp 11.3.7 or 12.1.0; older versions can use the -restrict_hosts setting, with a potential performance reduction. The company also warns that upgrades can fail where clusters already contain a role, user or privilege using one of five names introduced for a new ticket system.

Progress lists no workaround for organisations that cannot upgrade. The practical response is to inventory affected instances, review delegated forest and database rights and roles holding xdmp-eval-in, test application and automation dependencies, then deploy the appropriate supported release and examine administrative accounts and audit evidence for unauthorised changes.