Progress Software has disclosed 31 new security vulnerabilities in MarkLogic Server, its flagship enterprise database platform, including five flaws rated critical. The most serious ones let users with only limited, delegated privileges climb all the way to full administrative control of the server. Patches have existed since September 10 in MarkLogic 11.3.7 and 12.1.0, but the company only published the details on October 12, 2026, which means anyone still on an older release is now running a database whose weaknesses are public.
In short
What happened: Progress published 31 MarkLogic Server CVEs on October 12, 2026. Five are critical (three scored 9.9, two scored 9.6), and 24 more are rated high.
The danger: Two of the critical flaws turn a partially privileged account, for example someone who can only manage forests or users, into a persistent server administrator.
Who is affected: MarkLogic 11.x before 11.3.7 and MarkLogic 12.x before 12.1.0. The August patch releases (11.3.6 and 12.0.3) are not enough.
What to do: Upgrade 11.x to 11.3.7 or 12.x to 12.1.0, review delegated privilege assignments before and after, and audit roles holding the xdmp-eval-in privilege.
What Progress disclosed
Progress released the full batch of 31 vulnerabilities on October 12, 2026, with fixes that shipped quietly on September 10, roughly 32 days before the disclosure. That gap, known as coordinated disclosure, is common: it gives customers time to patch before the technical details become public. The trade-off is that now that the details are out, attackers can read the same advisory notes.
This is the second large MarkLogic security batch in just over two months. On August 5, Progress disclosed 10 flaws, seven of them critical, including CVE-2026-9192, a 9.8-rated bug that let an unauthenticated remote attacker bypass password verification on the ODBC App Server. Between the two batches, 41 of the 49 MarkLogic-related CVEs in the U.S. National Vulnerability Database come from these two disclosures alone. MarkLogic’s earlier releases also carried quiet security fixes: the release notes for 11.3.1, 11.3.2, and 11.3.4 mention vulnerability patches without naming CVEs.
One important nuance: Progress says its records show no evidence that any of the 31 flaws has been exploited in the wild, and none appeared in CISA’s Known Exploited Vulnerabilities catalog as of October 13. That is reassuring, but it is not a reason to wait. The fixes were available for a month before the announcement, and patching is the only supported fix, because Progress lists no workarounds for customers who cannot upgrade immediately.
The five critical flaws
Three of the critical flaws score 9.9 on the CVSS scale and two score 9.6. None is a simple remote attack: for each one, the attacker must already hold some privilege or be able to run code on the server. What makes them critical is what a small foothold can turn into.
| CVE | Score | What the attacker needs | What it could allow |
|---|---|---|---|
| CVE-2026-85947 | 9.9 | Forest-management privileges | Create a persistent administrator account, potentially gaining complete control of the server |
| CVE-2026-85948 | 9.9 | Manage-user-level privileges | Persistent administrative control through an XQuery injection flaw in a deprecated Management API path |
| CVE-2026-85955 | 9.9 | Query-execution access plus the xdmp-eval-in privilege | Run server-side code with elevated permissions |
| CVE-2026-85956 | 9.6 | Delegated database-administrator privileges | Back up or restore forests outside its own database, exposing what Progress calls security-critical data |
| CVE-2026-9191 | 9.6 | The ability to run code through certain REST and XDBC evaluation paths | Perform unauthorized actions or compromise an authenticated session |
Four of the five were reported by outside researchers through Bugcrowd, a sign that Progress’s bounty program is doing real work. A researcher using the handle rexnets is credited with three of them (CVE-2026-85947, CVE-2026-85948, and CVE-2026-85956), and another, WaltWhitehat, reported CVE-2026-9191.
Why delegated administrators are the scary part
The headline risk is privilege escalation from accounts that were deliberately given limited power. Large organizations routinely delegate narrow administrative duties, letting a team manage one database’s users or one group of forests without touching the rest of the cluster. These flaws break that boundary.
CVE-2026-85947 is the clearest example. In MarkLogic, a forest is a collection of documents attached to a database. The fix note reveals the problem: a forest-scoped administrative grant used to be enough on its own to attach a forest to a database of the account’s choosing. After the upgrade, that grant alone no longer suffices. The vulnerability turned that over-broad permission into a route to creating a persistent administrator account.
The other flaws work the same theme from different angles: an XQuery injection in a legacy Management API path, an eval-in privilege that granted more than intended, and backup/restore operations that reached outside the database they were scoped to. The pattern should prompt every MarkLogic shop to review who holds delegated forest and database privileges, because the trust model those assignments assumed was wrong.
It is also worth noting a sober detail in Progress’s notes: they do not say whether upgrading removes an administrator account created through CVE-2026-85947 before the upgrade. If such an account exists, patching the server without checking the user list could leave the attacker in place.
The other 26 flaws
Beyond the five criticals, 24 flaws are rated high and two medium. The highest-rated high, CVE-2026-85954 at 8.6, lets an attacker gain more privileges than granted by passing crafted values to certain XQuery functions. Several of the rest only matter in specific configurations:
- SAML deployments: an unauthenticated remote attacker could get the server to accept an assertion it should reject (CVE-2026-85962); on 11.x, the SAML parser could also process external DTDs or entities (CVE-2026-85957).
- OAuth: an attacker could use a token the server should not accept (CVE-2026-85958). The fix adds issuer and audience checks for Ping Identity and other OAuth configurations.
- Password-based Kerberos: in certain setups, a network-positioned attacker could impersonate the Kerberos authentication service (CVE-2026-85972).
- Cloud hosting: an authenticated attacker could reach internal cloud services and pull cloud credentials on Azure (CVE-2026-85951) and on Linux cloud deployments (CVE-2026-85952).
- Diagnostic logs: the server could write security-sensitive data to logs (CVE-2026-85949, CVE-2026-85961), including AWS secret keys and session tokens in plaintext when a specific IAM trace path was enabled.
- Amazon S3: connections to S3 could default to cleartext (CVE-2026-85975).
- Query Console: tricking a logged-in user into opening a malicious page could run server-side code with that user’s permissions (CVE-2026-85960); an authenticated user could also read arbitrary server files (CVE-2026-85964).
- Legacy components: OpsDirector, a deprecated feature, could let an unauthenticated remote attacker reach internal services or forge trusted requests (CVE-2026-85963); legacy InfoStudio modules could expose server files (CVE-2026-85953).
The remainder includes three memory-safety flaws, a cross-site scripting flaw, HTTP response splitting in Query Console, inconsistent TLS hostname checks on some outbound connections, and cleartext cluster-management traffic on 12.x.
What the upgrade changes
Progress urges customers to read the upgrade notes for 11.3.7 and 12.1.0 before upgrading, because the releases change behavior in ways that can break existing code, tools, and automation. The 11.3.7 notes list behavior changes tied to 22 of the flaws, and the 12.1.0 notes to 21. Changes to plan for:
- mlcp: older versions of MarkLogic Content Pump fail against the new releases with an XDMP-ISOLATED error. Use mlcp 11.3.7 or 12.1.0; older versions can run with -restrict_hosts set to true at some performance cost.
- Removed features: the /manage/v2/packages API, InfoStudio, and OpsDirector are gone entirely.
- New defaults: XML external entity processing is off by default, S3 connections default to HTTPS, and rotated log files are created with mode 0640 instead of 0666.
- Privileges: xdmp:eval-in() now requires both the xdmp-eval-in and xdmp-eval privileges. Reading Authorization headers needs a new privilege that no built-in role holds. Forest attachment, backup, and restore are now checked against every forest and database they touch.
- Platform: MarkLogic 11.3.7 no longer supports Amazon Linux 2.
Some gaps remain after the upgrade. Existing ErrorLog.txt and AuditLog.txt files keep their old permissions until rotated or recreated, the Kerberos fix needs a keytab (without one the server logs a warning and skips the new check), and one flaw (CVE-2026-85959) meant successful logins were not always recorded in the audit log, which could have limited customers’ ability to detect unauthorized access.
What to do now
- Upgrade. MarkLogic 11.x goes to 11.3.7, MarkLogic 12.x to 12.1.0. Note that 11.3 is the long-term support line, while 12 is what Progress calls an innovation release, and there is no patched 12.0 release. Read the upgrade notes first; the behavior changes are real.
- Review delegated privileges before and after. Audit forest-scoped grants, database administrator assignments, and every role holding xdmp-eval-in. The upgrade notes explicitly tell customers to do this.
- Check for rogue accounts. Because upgrading may not remove an administrator account created via CVE-2026-85947, review the full user and role list for accounts you cannot explain.
- Rotate secrets and review logs. Given the plaintext-secret logging flaws and the audit-log gap in CVE-2026-85959, rotate credentials that passed through affected systems and look for unusual activity.
- Patch the tooling too. Update mlcp to a matching version and retire anything depending on the removed /manage/v2/packages API, InfoStudio, or OpsDirector.
This is the same playbook every recent enterprise disclosure has demanded: the GitLab CVE-2026-97229 emergency patch, the Atlassian CVE-2026-21589 file-access flaw, the SonicWall SMA 1000 SSRF flaw, and the FortiMail zero-day all followed the same arc, patch first, verify nothing was left behind second.
Frequently asked questions
Are the MarkLogic vulnerabilities being exploited in the wild?
Progress says its records show no evidence of exploitation, and none of the 31 flaws was listed in CISA’s Known Exploited Vulnerabilities catalog as of October 13, 2026. That said, the technical details are now public, so unpatched servers are exposed to anyone who reads the advisories.
Which MarkLogic versions are affected?
All MarkLogic 11.x releases before 11.3.7 and all 12.x releases before 12.1.0. The fixes were first available on September 10, 2026, but the August patch releases (11.3.6 and 12.0.3) are still vulnerable to the new batch.
Can I work around the flaws without upgrading?
No. Progress’s CVE records and upgrade notes list no workarounds, so upgrading is the only supported fix. Because the upgrade changes behavior (removed features, new privilege requirements, mlcp compatibility), test it against a staging cluster first.
What is the worst flaw in the batch?
CVE-2026-85947, scored 9.9, lets an account with forest-management privileges create a persistent administrator account, potentially giving complete control of the server. CVE-2026-85948 (9.9) and CVE-2026-85955 (9.9) offer similar escalation paths from manage-user and query-execution privileges.
Should I check for signs of a past compromise?
Yes. Review the user and role list for unexplained administrator accounts, audit delegated privilege assignments, rotate secrets that may have been written to diagnostic logs in plaintext, and keep in mind that successful logins were not always recorded in the audit log (CVE-2026-85959) before the patch.