CVE-2026-7329: Progress MarkLogic Server Privilege Escalation
TL;DR - Critical MarkLogic flaw lets a low-privileged authenticated REST user escalate to administrator. - Affects versions before 11.3.6 and 12.0.3 in SQL, SPARQL, and Optic REST query interfaces. - Patch is available; no confirmed public PoC or in-the-wild exploitation was identified in available sources.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-7329 |
| CVSS score | 9.9 |
| Attack vector | Unknown from available NVD API response; likely network-reachable via REST interfaces, but defenders should treat the official vector as not yet retrieved |
| Auth required | Yes. Authenticated low-privileged REST role required |
| Patch available | Yes |
| Vendor | Progress Software |
| Product | Progress MarkLogic Server |
| Affected interfaces | SQL REST, SPARQL REST, Optic REST query interfaces |
| Fixed versions | 11.3.6 and 12.0.3 |
CVE-2026-7329 is a critical improper privilege management vulnerability in Progress MarkLogic Server. According to the NVD description, the issue affects the SQL, SPARQL, and Optic REST query interfaces and allows an authenticated user with a low-privileged REST role to escalate privileges to administrator.
For defenders, the important operational takeaway is that this is not an unauthenticated internet worm scenario, but it is still high impact. Any environment where users, apps, analysts, or service accounts have access to MarkLogic REST query interfaces should treat this as urgent because compromise of a lower-tier account can become full administrative control of the MarkLogic environment.
What Is This Vulnerability?
The root cause is described as improper privilege management in MarkLogic’s REST query interfaces. In practical terms, that means authorization boundaries are not being enforced correctly when handling requests through the SQL, SPARQL, or Optic APIs. A user who should be constrained by a low-privileged REST role can apparently trigger code paths or operations that execute with administrator-level privileges.
This matters because MarkLogic often sits in front of sensitive datasets and supports application logic, search, analytics, semantic data handling, and document workflows. If role checks are weakened at the REST layer, an attacker does not necessarily need a memory corruption bug or code execution chain to cause major damage. A privilege escalation to administrator can enable direct access to protected content, changes to security settings, execution of privileged operations, and broader abuse of the server’s trust relationships.
The vulnerability description does not include a public low-level exploit narrative, and the vendor bulletin text was not recoverable from the available fetch in this research session. Because of that, defenders should avoid assuming a more specific mechanism than the evidence supports. The source-backed conclusion is that authorization handling in the affected REST query interfaces is flawed enough to permit escalation from a low-privileged authenticated REST user to administrator.
Technical Notes
Affected surfaces explicitly named in the NVD description:
- SQL REST query interface
- SPARQL REST query interface
- Optic REST query interface
A simplified risk model for defenders is:
Initial access requirement:
Valid MarkLogic account with a low-privileged REST role
Exploitation result:
Administrator privilege level within MarkLogic Server
Potential impact:
- privileged operations
- unauthorized data access
- security configuration changes
Who Is Affected?
The available source material identifies the vulnerable product as Progress MarkLogic Server. The affected version ranges, quoted from the NVD-backed description, are:
- Progress MarkLogic Server before 11.3.6
- Progress MarkLogic Server before 12.0.3
That means systems running 11.3.x earlier than 11.3.6 are affected, and systems running 12.0.x earlier than 12.0.3 are affected. Based on the evidence provided, those are the only version boundaries that can be stated confidently. If you are on one of those branches and below the fixed release, you should assume exposure if the relevant REST interfaces are enabled and reachable by authenticated users.
It is also important to think about who is operationally affected, not just what software version is affected. Environments at higher risk include those where MarkLogic is integrated with multiple internal applications, where service accounts have broad access to REST query endpoints, or where developers and analysts can submit SQL, SPARQL, or Optic queries. In those deployments, the attack precondition of “authenticated low-privileged user” may be easier to meet than it first appears.
If you are running an older branch not mentioned in the available description, the status is unknown from the supplied sources. In that situation, defenders should not invent compatibility assumptions. Instead, verify directly with Progress support or the vendor advisory and treat unpatched systems conservatively until the scope is confirmed.
Technical Notes
You can verify the installed MarkLogic version locally before scoping remediation:
rpm -qa | grep -i marklogic
Or query package metadata on supported Linux systems:
dnf info MarkLogic
# or
yum info MarkLogic
If you maintain an asset inventory, search for:
Product: MarkLogic Server
Version: < 11.3.6 on 11.3.x
Version: < 12.0.3 on 12.0.x
CVSS Score Breakdown
The reported base score is 9.9, which places this issue in the critical range. However, an important caveat applies: the NVD tool output available for this article did not include the vector string. That means the exact component values for attack complexity, privileges required, user interaction, scope, and impact metrics were not retrievable from the exposed API response used here.
Even without the full vector, the score and description tell defenders a lot. A 9.9 score on an authenticated privilege escalation suggests that the downstream impact is extremely high. The vulnerability enables elevation to administrator and unauthorized data access, both of which strongly support severe confidentiality and integrity impact. Depending on how MarkLogic is used in your environment, availability impact could also be significant if an attacker with admin rights can alter cluster behavior, security policy, or content services.
The missing vector should not delay action. From a triage standpoint, defenders should treat this as a critical auth-to-admin escalation on a network-exposed application service. If your risk process requires a formal vector before emergency patching, note the gap explicitly but proceed based on the published base score, affected interfaces, and vendor-fixed versions.
A practical interpretation of likely score drivers is:
| CVSS factor | What we know |
|---|---|
| Attack vector | Not present in the available NVD API response |
| Privileges required | Authenticated low-privileged REST role required |
| User interaction | Not stated in available sources |
| Confidentiality impact | High, due to unauthorized data access |
| Integrity impact | High, due to privileged operations |
| Availability impact | Unknown from description, but admin access can create serious operational risk |
Exploitation Status
At the time of writing, there is no confirmed evidence in the retrieved sources that CVE-2026-7329 is being exploited in the wild. The CVE is not listed in CISA’s Known Exploited Vulnerabilities catalog, which is a useful but incomplete signal. Absence from KEV does not mean “safe”; it means there is no CISA-listed confirmation at this time.
There is also no credible CVE-specific public proof of concept identified in the available research inputs. No vendor-linked exploit write-up, GitHub proof of concept, or other primary-source exploit material was found in the supplied context. That said, once fixed versions and affected interfaces are publicly known, exploit development often follows. For an authenticated privilege escalation in a widely used enterprise platform, the window between disclosure and practical reproduction can be short.
So the evidence-based status is:
- Public PoC: none confirmed in available sources
- Active exploitation in the wild: none confirmed in available sources
- CISA KEV: no
In the absence of confirmed exploitation, defenders should still assume moderate near-term exploitability because the bug affects well-defined REST interfaces and has a very high severity rating. Patch prioritization should be based on exposure and account sprawl, not only on whether a public exploit has appeared.
Technical Notes
Operational watch items for the next several days:
- Sudden use of SQL, SPARQL, or Optic REST endpoints by accounts that historically did not access them
- Privileged administrative actions immediately following lower-privileged query activity
- Security role changes, user creation, or configuration changes from unexpected REST users
How to Detect It
Detection for CVE-2026-7329 should focus on two themes: unexpected use of the affected REST query interfaces and evidence that a low-privileged account performed actions consistent with administrative capability. Because the public technical details are limited, defenders should build behavior-based detection rather than waiting for a vendor-authored signature.
Start by identifying the normal baseline for MarkLogic REST users, service accounts, and application identities. Which principals are expected to access SQL, SPARQL, or Optic endpoints? Which hosts usually submit those queries? Which accounts should never perform admin-equivalent tasks? The goal is to catch privilege boundary violations even if you do not yet know the exact exploit request shape.
Then review MarkLogic logs, reverse proxy logs, API gateway logs, and identity provider telemetry together. You want correlation, not isolated entries: a lower-tier user hits a query interface, then shortly afterward performs actions or reaches endpoints usually reserved for admins. Even if application logging is sparse, network and auth logs may still reveal an anomalous sequence.
Technical Notes
Example URI patterns to monitor in HTTP logs, reverse proxies, or WAF telemetry:
/MarkLogic/sql
/MarkLogic/sparql
/MarkLogic/optic
Example generic detection logic in Splunk-style syntax for suspicious access to affected interfaces:
index=web OR index=proxy OR index=app
(
uri_path="/MarkLogic/sql" OR
uri_path="/MarkLogic/sparql" OR
uri_path="/MarkLogic/optic"
)
| stats count min(_time) as first_seen max(_time) as last_seen by user src_ip uri_path http_method status
| sort - count
Example follow-on correlation search for possible auth-to-admin abuse:
(
index=web uri_path IN ("/MarkLogic/sql","/MarkLogic/sparql","/MarkLogic/optic")
) OR (
index=app action IN ("admin_change","role_change","user_create","privileged_operation")
)
| transaction user maxspan=15m
| search eventcount>1
If you use a network IDS and terminate TLS upstream where inspection is possible, alert on unusual POST activity to the named endpoints from non-admin application tiers:
alert tcp $HOME_NET any -> $HTTP_SERVERS $HTTP_PORTS (
msg:"Possible MarkLogic query interface access";
flow:to_server,established;
content:"POST"; http_method;
pcre:"/\/MarkLogic\/(sql|sparql|optic)/U";
sid:10007329; rev:1;
)
If endpoint or application audit logs expose role or privilege changes, specifically look for:
- role assignment changes
- user administration events
- database or security config changes
- content access from accounts that previously had only query privileges
Mitigation and Patching
The primary remediation is to upgrade to the fixed releases identified in the available sources:
- Upgrade MarkLogic Server 11.3.x to 11.3.6
- Upgrade MarkLogic Server 12.0.x to 12.0.3
Do not defer patching simply because the attack requires authentication. In many enterprise deployments, “authenticated low-privileged user” includes service accounts, CI/CD credentials, data integration users, and application identities that are easier to obtain than an administrator account. If MarkLogic is internet reachable, partner accessible, or broadly exposed on internal networks, the urgency is higher.
If you cannot patch immediately, reduce exposure around the affected REST interfaces. Limit network access to MarkLogic from only approved application hosts, restrict which identities can access SQL, SPARQL, and Optic endpoints, review role assignments for REST users, and increase logging around query interfaces and administrative actions. These are workarounds, not fixes, because the flaw is in privilege management itself.
You should also rotate or review credentials for lower-privileged accounts with REST access if there is any suspicion of compromise. Since successful exploitation can elevate to administrator, post-exploitation review should include configuration integrity checks, user and role audits, and verification of sensitive data access.
Technical Notes
Example package upgrade workflow on RHEL-compatible systems after obtaining the vendor package:
sudo systemctl stop MarkLogic
sudo dnf upgrade ./MarkLogic-11.3.6*.rpm
sudo systemctl start MarkLogic
For 12.0.x environments:
sudo systemctl stop MarkLogic
sudo dnf upgrade ./MarkLogic-12.0.3*.rpm
sudo systemctl start MarkLogic
If your platform uses yum:
sudo systemctl stop MarkLogic
sudo yum localupdate MarkLogic-11.3.6*.rpm
sudo systemctl start MarkLogic
Temporary exposure reduction steps if patching must wait:
1. Restrict network access to MarkLogic REST services with firewall or security group rules.
2. Disable or tightly limit access to SQL, SPARQL, and Optic REST interfaces where operationally possible.
3. Remove unnecessary low-privileged REST roles and review service account permissions.
4. Enable heightened logging for query interface access and admin actions.
Example firewall control on Linux to limit access to trusted app subnets only:
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.10.20.0/24" port protocol="tcp" port="8000" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port protocol="tcp" port="8000" drop'
sudo firewall-cmd --reload
Before and after patching, verify the running version:
rpm -qa | grep -i marklogic
References
The strongest available primary reference is the vendor advisory URL surfaced by the NVD record. In this research session, that page returned a Progress Customer Community application shell rather than directly exposing the bulletin text, so defenders may need to access it through the vendor portal or a browser session.
A second useful vendor source is the MarkLogic 11 release notes page, which confirms that 11.3.6 is a security patch release and that customers on 11.3.5 should upgrade to 11.3.6. While the retrieved release note content did not explicitly name CVE-2026-7329 in the visible fetch, it supports the fixed-version guidance.
- NVD entry for CVE-2026-7329
- Progress advisory: https://community.progress.com/s/article/Marklogic-Critical-Security-Alert-Bulletin-August-2026
- Progress MarkLogic 11 release notes: https://docs.progress.com/bundle/marklogic-server-whats-new-11/page/topics/release-notes.html
For further information on privilege management vulnerabilities, you can also check our articles on CVE-2026-6207 and CVE-2026-16242.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.