As reported by The Hacker News, Progress Software disclosed 31 vulnerabilities in its MarkLogic Server NoSQL database on October 12 — five of them critical. Patches have been available since September 10 in MarkLogic 11.3.7 and 12.1.0, but no workarounds exist for customers who cannot upgrade, and no active exploitation has been confirmed.
The Core Problem: Privilege Escalation From Within
What makes this disclosure notable isn't the count — it's the pattern. Every critical flaw requires some degree of prior access, but each enables a lower-privileged user to break out of their delegated role and seize administrative control. This is a textbook privilege escalation scenario, and it's especially dangerous in environments where MarkLogic serves as a multi-tenant data backbone with numerous delegated database managers or application service accounts.
The two headline flaws — CVE-2026-85947 and CVE-2026-85948 — both allow a delegated manager to create persistent admin-level access. CVE-2026-85947 targets forest-management privileges, letting an attacker attach a forest to a database of their choosing and establish a backdoor admin account. CVE-2026-85948 exploits an XQuery injection in a deprecated Management API path, turning manage-user-level access into full admin persistence.
Critical Vulnerability Summary
| CVE | CVSS | Prerequisite | Impact |
|---|---|---|---|
| CVE-2026-85947 | 9.9 | Forest-management privileges | Persistent admin account creation |
| CVE-2026-85948 | 9.9 | Manage-user-level privileges | Admin control via XQuery injection |
| CVE-2026-85955 | 9.9 | Query execution + xdmp:eval-in | Code execution with elevated permissions |
| CVE-2026-85956 | 9.6 | Delegated DB-admin privileges | Unauthorized forest backup/restore across databases |
| CVE-2026-9191 | 9.6 | REST/XDBC evaluation paths | Unauthorized actions, session compromise |
Who Is Most at Risk
The fact that no workaround exists means upgrading is the only remediation path. Organizations that deferred patching because they applied the August fixes are still fully exposed.
Shield53 Recommendations
Immediate Actions
- Upgrade now: Move to MarkLogic 11.3.7 (LTS) or 12.1.0. Do not assume prior August patches provide any coverage for this batch.
- Audit delegated roles: Review all forest-scoped administrative grants and delegated database-administrator assignments. Revoke any that are overly broad or no longer needed. The fix for CVE-2026-85947 specifically changes what a forest-scoped grant can do — verify your existing grants against the new behavior.
- Inventory deprecated API usage: Search your environment for calls to deprecated Management API paths. Migrate away from them — they're the vector for CVE-2026-85948 and are unlikely to receive further hardening.
- Restrict xdmp:eval-in: Identify which accounts hold this privilege and remove it from any service account or delegated user that doesn't explicitly require it. CVE-2026-85955 turns this into a code execution foothold.
- Hunt for indicators of prior exploitation: Even though active exploitation hasn't been confirmed, the persistence mechanism in CVE-2026-85947 and 85948 means a compromised account could have been backdoored before patching. Review for unexpected admin accounts, unusual forest-to-database attachments, and anomalous Management API calls in your audit logs.
Broader Considerations
This disclosure reinforces a hard truth: delegation without rigorous scoping is an attack surface. MarkLogic's delegated administration model is powerful for operational efficiency, but each of these critical flaws exploits the gap between what a delegated role should do and what it can do. Organizations should treat any system with hierarchical privilege delegation — not just MarkLogic — as needing regular privilege audits, not just patch cycles.
Also notable: Progress released patches a month before disclosure but provided no workaround. If your vendor releases a patch with no advisory context, that's not a signal to wait — it's a signal that the vulnerability is serious enough to fix before the details go public. Build your SLAs around vendor patch availability, not disclosure dates.
