Critical security update
Progress has published five critical MarkLogic Server vulnerability records affecting 11.x releases before 11.3.7 and 12.x releases before 12.1.0.[1][2][3][4][5]
Reporting cutoff: 2026-10-13T09:30:13Z
What the five flaws can allow
- CVE-2026-85947 (9.9): a remote attacker with forest-management privileges could create a persistent unauthorized administrator account.[1]
- CVE-2026-85948 (9.9): a remote attacker with manage-user-level privileges could exploit an XQuery injection flaw in a deprecated Management API package path to gain persistent unauthorized administrative control.[2]
- CVE-2026-85955 (9.9): a remote attacker with query-execution access could invoke an XQuery evaluation function without an additional required evaluation privilege, resulting in elevated server-side code execution.[3]
- CVE-2026-85956 (9.6): a remote attacker with delegated database-administrator privileges could perform backup or restore operations outside the authorized database scope.[4]
- CVE-2026-9191 (9.6): affected REST and XDBC evaluation paths do not sufficiently isolate user-supplied code from HTTP request, response and session state, which could permit unauthorized actions or compromise an authenticated session.[5]
Who should act
Organizations operating self-managed MarkLogic Server 11.x below 11.3.7 or 12.x below 12.1.0 should treat those deployments as affected by these five records.[1][5]
Progress describes MarkLogic 11.3.7 as a patch and security update to the 11.3 LTS line, and MarkLogic 12.1.0 as a feature and security update to the 12 innovation line; both release notes list September 10, 2026 as the release date.[6][7]
Practical response checklist
Practical guidance: use normal backup, staging, compatibility testing and change control rather than applying an emergency production change blindly.[6][7]
- Inventory first. Record the exact MarkLogic version on every node, container image, standby system and disaster-recovery copy. Map enabled REST/XDBC evaluation paths and delegated forest, database and user-management privileges.[1][2][4][5]
- Preserve evidence. Before changing the environment, retain supported configuration and version inventories plus relevant security, administrator, backup and restore audit records.[1][4]
- Read the compatibility notes. The 11.3.7 and 12.1.0 release notes say user-supplied code in named REST and XDBC evaluation paths now runs in an isolated context, while some installed extensions, transforms and invoke paths remain unisolated by design.[6][7]
- Upgrade through the supported path. Move affected 11.x deployments to 11.3.7 or later and affected 12.x deployments to 12.1.0 or later, after testing representative application queries, integrations, authentication, backup and restore behavior.[1][5][6][7]
- Verify the live runtime. Confirm every active node and image reports the intended release, old workers are no longer serving traffic, and expected REST/XDBC, authentication, query, backup and restore workflows still function.[6][7]
Do not use public exploit code or probe production or third-party systems. If unexplained administrator creation, elevated evaluation activity, or out-of-scope backup or restore behavior appears, preserve logs and involve qualified incident response before deleting or rebuilding evidence.[1][3][4]
What remains unknown
The five reviewed Progress CNA records do not state that these vulnerabilities have been exploited in the wild, identify a victim, or provide a public proof of concept. That absence is not proof that exploitation has never occurred; it is only the limit of the official records reviewed at this reporting cutoff.[1][2][3][4][5]
Bottom line
If your organization runs MarkLogic 11.x or 12.x, check the exact version now. Systems below 11.3.7 or 12.1.0 are inside the affected ranges for these five critical records; plan the supported upgrade, test application compatibility, and verify the corrected release across every live and standby copy.[1][5][6][7]