Critical MarkLogic Server Privilege Escalation: Delegated Manager-to-Admin Flaws — Patch 11.3.7 / 12.1.0 Now

Progress Software has disclosed 31 vulnerabilities in MarkLogic Server — its enterprise multi-model NoSQL database — and five of them are rated critical. The two that should keep defenders up at night are privilege escalation flaws: an account holding only delegated management privileges (the kind routinely handed to app owners and junior DBAs) can escalate to full administrator control of the server.

Progress published the full set of advisories on October 12, 2026, but the fixes have been shipping since September 10, 2026 in MarkLogic 11.3.7 and MarkLogic 12.1.0. That one-month gap between patch availability and public disclosure is exactly the window sophisticated attackers use for patch-diffing: reverse-engineering the fix to identify the bug before slow patchers catch up. If your MarkLogic clusters are still running anything earlier than 11.3.7 (on the 11.x train) or 12.1.0 (on the 12.x train), treat this as an urgent remediation item.

MarkLogic is not a toy database sitting on a developer's laptop. It powers publishing platforms, government intelligence systems, financial data hubs, and healthcare content repositories. Full administrative control of a MarkLogic cluster means control of the security database — users, roles, privileges, external authentication configuration, and every document the cluster holds, including content protected by element-level security.

Technical Analysis

Affected Products and Versions

• Product: Progress MarkLogic Server (all supported platforms — Linux/RHEL and Windows Server deployments)
• Affected versions: MarkLogic 11.x releases prior to 11.3.7, and MarkLogic 12.x releases prior to 12.1.0 (i.e., the 12.0.x line)
• Fixed versions: MarkLogic 11.3.7 and MarkLogic 12.1.0, released September 10, 2026
• Disclosure: October 12, 2026 — 31 vulnerabilities total, five rated critical

CVE identifiers for the individual flaws are enumerated in Progress's official security advisory and release notes; organizations should map the exact CVEs for the two privilege-escalation issues from the vendor advisory rather than secondary reporting, and track them in their vulnerability management platform.

How the Privilege Escalation Works (Defender's View)

MarkLogic implements a granular role-based security model. In mature deployments, full admin access is deliberately withheld from most operators. Instead, teams are given delegated administration roles — for example, the ability to manage users within specific compartments, administer particular app servers, or perform manage-level tasks via the Admin UI (default port 8001) or the Management REST API (/manage/v2) without holding the keys to the entire cluster.

The two critical flaws break that trust boundary. An authenticated account holding only one of these limited management roles can abuse the vulnerable management path to escalate to effective full administrator. From a defender's perspective, the attack chain looks like this:

1. Access requirement: The attacker needs an authenticated MarkLogic account with at least some delegated management capability — not anonymous access. That means the primary exposure is (a) malicious insiders, (b) compromised delegated accounts (phished credentials, leaked service accounts, contractors with stale access), and (c) attackers who have already landed in the environment and harvested a low-privilege MarkLogic credential from configuration files, CI/CD secrets, or browser sessions.
2. Escalation: Through the vulnerable management functionality, the attacker elevates to full admin — which in MarkLogic means the ability to create users, grant the admin role, modify the security database, reconfigure app servers, and disable or manipulate auditing.
3. Persistence: Full admin control enables durable persistence: creation of new admin-role users, modification of external authentication (LDAP/Kerberos) settings, deployment of backdoored modules into app servers, and exfiltration of the entire content database. Because the escalation produces legitimate-looking role assignments, a post-compromise admin user can survive for months if nobody audits role membership.

This is the classic privilege escalation → persistence → data theft pattern, executed entirely through authenticated administrative functionality — which is why it tends to be quiet in logs unless you are specifically auditing security-database changes.

Exploitation Status

As of this writing, there are no public reports of in-the-wild exploitation and no confirmation of CISA KEV listing. However, three factors raise the risk materially:

• The patches have been public for over a month, giving motivated actors ample time to diff 11.3.6/12.0.x against 11.3.7/12.1.0 and isolate the vulnerable code paths.
• Exploitation requires only an authenticated, low-privilege delegated account — a low bar for insider threats and for attackers already inside the network.
• MarkLogic clusters typically hold high-value, consolidated enterprise data, making them a premium target.

Do not wait for a KEV entry to act.

Detection & Response

The most reliable detection surface for this class of attack is MarkLogic's own audit log combined with network-layer monitoring of the management interfaces. If audit logging is not enabled on your clusters, enable it today — it is your primary forensic record of who changed what in the security database. Audit logs default to /var/opt/MarkLogic/Logs/AuditLog.txt on Linux and C:\Program Files\MarkLogic\Data\Logs\ on Windows.

Sigma Rules

---
title: MarkLogic Admin Role Assignment or Security User Modification in Audit Log
id: 3f8c2a71-6b4e-4d19-9a25-7e1c0b5f8a31
status: experimental
description: Detects MarkLogic audit events indicating a user was granted the admin role or a security user was created/modified. On servers vulnerable to the October 2026 delegated-manager privilege escalation flaws, unexpected admin grants are the primary post-exploitation artifact. Requires MarkLogic audit events forwarded to the SIEM.
references:
  - https://thehackernews.com/2026/10/two-critical-marklogic-flaws-could-give.html
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/10/14
tags:
  - attack.privilege_escalation
  - attack.persistence
  - attack.t1078
  - attack.t1136
logsource:
  product: linux
  service: marklogic
detection:
  selection_event:
    - '<role-assignment>'
    - 'user-add'
    - 'user-change'
  selection_role:
    - '<role-name>admin</role-name>'
    - 'role="admin"'
  condition: selection_event and selection_role
falsepositives:
  - Legitimate DBA activity granting admin roles during onboarding or break-glass events — baseline expected grantors and alert on deviation
level: high
---
title: MarkLogic Management Interface Access from Non-Management Source
id: 8a1d5e42-0c93-4b7f-a6d8-2f4e9c1b7d60
status: experimental
description: Detects HTTP access to the MarkLogic Admin UI or Management REST API (ports 8001/8002, /manage/v2 paths) originating from hosts outside the approved management network. Delegated-manager exploitation of the October 2026 flaws requires an authenticated session to management endpoints; restricting and alerting on source networks limits the blast radius of a compromised low-privilege account.
references:
  - https://thehackernews.com/2026/10/two-critical-marklogic-flaws-could-give.html
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/10/14
tags:
  - attack.initial_access
  - attack.t1078
logsource:
  category: proxy
detection:
  selection_path:
    cs-uri|contains:
      - '/manage/v2'
      - '/qconsole'
  selection_port:
    dst-port:
      - 8001
      - 8002
  filter_mgmt_subnet:
    c-ip|startswith:
      - '10.10.20.'
  condition: (selection_path or selection_port) and not filter_mgmt_subnet
falsepositives:
  - Monitoring systems, load-balancer health checks, or backup tooling polling management endpoints — tune the filter to your actual management and monitoring ranges
level: medium
---
title: MarkLogic Server Process Spawning Command Shell
id: 5c7b91f3-2a64-4e08-b3d9-8c0f6a2d5e17
status: experimental
description: Detects the MarkLogic server daemon spawning a command shell or script interpreter. MarkLogic does not launch interactive shells in normal operation; this pattern indicates post-exploitation activity such as an attacker with admin control deploying payloads through app-server modules or task execution.
references:
  - https://thehackernews.com/2026/10/two-critical-marklogic-flaws-could-give.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/14
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\MarkLogic.exe'
      - '\MarkLogicService.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare maintenance scripts invoked by administrators through XQuery server-side execution — investigate rather than suppress
level: critical

KQL Hunting (Microsoft Sentinel / Defender)

These queries assume MarkLogic audit logs are forwarded to Sentinel via Syslog/CEF (fluentd, rsyslog, or the AMA agent can tail AuditLog.txt), and that endpoint network telemetry is available. The first query hunts for the post-exploitation artifact — admin role grants and security user changes. The second surfaces unexpected management-interface chatter.

// Hunt: MarkLogic audit events showing admin role grants or security user changes
// Requires AuditLog.txt forwarded via Syslog/CEF
Syslog
| where TimeGenerated > ago(14d)
| where SyslogMessage has_any ("role-assignment", "user-add", "user-change")
| where SyslogMessage has "admin"
| extend HostName = Computer
| project TimeGenerated, HostName, ProcessName, SyslogMessage
| order by TimeGenerated desc

// Hunt: Unexpected inbound connections to MarkLogic management ports (8001/8002)
// Baseline your approved admin/jump hosts in the watchlist or inline list below
let ApprovedAdminHosts = dynamic(["jumpbox01", "soc-admin-02"]);
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemotePort in (8001, 8002)
| where InitiatingProcessFileName !in~ ("firefox", "chrome", "msedge") // focus on non-browser and unexpected sources first
| where DeviceName !in~ (ApprovedAdminHosts)
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort
| order by ConnectionCount desc

Velociraptor VQL

Use this artifact for rapid fleet-wide triage: identify hosts running MarkLogic, confirm the management ports are listening, and pull the most recent security-relevant lines from the audit log — all in one collection. Run it across your database estate to find both unpatched exposure and suspicious recent role assignments.

-- Hunt: MarkLogic exposure and recent admin role assignments
-- Targets Linux MarkLogic deployments; adjust paths for Windows

LET processes = SELECT Pid, Name, Exe, CommandLine, Username
FROM pslist()
WHERE Name =~ '(?i)marklogic' OR Exe =~ '(?i)marklogic'

LET listeners = SELECT Pid, Name, Laddr
FROM netstat()
WHERE Laddr.Port in (7997, 7998, 7999, 8000, 8001, 8002, 8010, 8040, 8041, 8042)
  AND Status = 'LISTEN'

LET audit_hits = SELECT
    '/var/opt/MarkLogic/Logs/AuditLog.txt' AS SourceFile,
    parse_string_with_regex(string=Line,
      regex='^(?P<Timestamp>[^ ]+ [^ ]+)') AS Parsed,
    Line
FROM parse_lines(filename='/var/opt/MarkLogic/Logs/AuditLog.txt', accessor='file')
WHERE Line =~ '(?i)(role-assignment|user-add|user-change)'
  AND Line =~ '(?i)admin'
LIMIT 100

SELECT * FROM processes
UNION ALL SELECT NULL, NULL, NULL, NULL, NULL FROM audit_hits

For production hunts, split the three LET blocks into separate artifacts — one for exposure (process + listeners), one for audit-log role grants — so results are easier to pivot on in the notebook view.

Remediation and Verification Script

The following Bash script audits a MarkLogic host for: installed version versus the fixed releases, whether the management ports are exposed, which users currently hold the admin role, and whether auditing is enabled. Run it on every cluster host. Requires curl and a read-only manage-level credential for the API checks.

#!/bin/bash
# MarkLogic October 2026 delegated-admin privilege escalation - audit & verify script
# Usage: ./marklogic_audit.sh [mgmt_host] [mgmt_port] [user]

HOST="${1:-localhost}"
PORT="${2:-8002}"
USER="${3:-manage-readonly}"
PROTO="http"; [ "$PORT" = "8002" ] && PROTO="https"
FIXED_11="11.3.7"; FIXED_12="12.1.0"

echo "=== [1] Installed MarkLogic version ==="
if command -v rpm >/dev/null 2>&1; then
  rpm -q MarkLogic 2>/dev/null || echo "MarkLogic RPM not found"
fi
# Cross-check via Admin API timestamp endpoint (returns server build info on some configs)
curl -sk --anyauth -u "$USER" "${PROTO}://${HOST}:${PORT}/admin/v1/timestamp" | head -5

echo ""
echo "=== [2] Listening management ports (expect 8001/8002 bound to mgmt interface only) ==="
ss -tlnp 2>/dev/null | grep -E ':(7997|7998|7999|8000|8001|8002)' || netstat -tlnp 2>/dev/null | grep -E ':(7997|7998|7999|8000|8001|8002)'

echo ""
echo "=== [3] Users holding the admin role (review EVERY entry) ==="
for u in $(curl -sk --anyauth -u "$USER" "${PROTO}://${HOST}:${PORT}/manage/v2/users?format=json" \
    | grep -o '"nameref":"[^"]*"' | cut -d'"' -f4); do
  ROLES=$(curl -sk --anyauth -u "$USER" "${PROTO}://${HOST}:${PORT}/manage/v2/users/${u}/properties?format=json" | grep -o '"role":\[[^]]*\]')
  echo "$ROLES" | grep -q '"admin"' && echo "  [!!] ADMIN ROLE: ${u} -> ${ROLES}"
done

echo ""
echo "=== [4] Audit enabled? (audit-enabled must be true on every group) ==="
curl -sk --anyauth -u "$USER" "${PROTO}://${HOST}:${PORT}/manage/v2/groups/properties?format=json" | grep -o '"audit-enabled":[^,}]*'

echo ""
echo "=== [5] Recent admin-role assignments in audit log ==="
grep -h -i 'role-assignment' /var/opt/MarkLogic/Logs/AuditLog.txt 2>/dev/null | grep -i 'admin' | tail -20

echo ""
echo "=== Version gate ==="
echo "Fixed releases: ${FIXED_11} (11.x train) / ${FIXED_12} (12.x train). Anything earlier is VULNERABLE to the Oct 2026 delegated-admin escalation set. Upgrade immediately via Progress's official download portal."

Remediation

1. Patch immediately. Upgrade all MarkLogic 11.x clusters to 11.3.7 and all 12.x clusters to 12.1.0 or later. These builds have been available since September 10, 2026; given the public disclosure on October 12, assume exploit development is underway. Upgrade every node in a cluster — a single unpatched node behind a load balancer re-exposes the management plane.
2. Pull the authoritative CVE list from Progress. Review the official Progress MarkLogic security advisory and release notes for 11.3.7/12.1.0 to map all 31 CVEs (including the two critical privilege-escalation issues) into your vulnerability scanner and ticketing system: https://www.progress.com/marklogic and the Progress Knowledge Base security advisories page. Do not rely on third-party CVE aggregators for the definitive mappings.
3. Audit every delegated account and every admin-role holder — today. The entire value of these flaws to an attacker is a compromised delegated account. Enumerate all users holding admin, and all users holding delegated management roles (manage-level, security, compartment admin). Remove stale contractor, service, and test accounts. Rotate credentials for every account with management-plane access, prioritizing any that have authenticated to ports 8001/8002 in the last 90 days.
4. Restrict the management plane at the network layer. The Admin UI (8001) and Management REST API (8002, and 8001 if you still serve it over HTTP) should be reachable only from a dedicated management subnet or jump host — never from general user VLANs, application servers, or the internet. Enforce with host firewall rules and network ACLs, and verify with an external port scan.
5. Enable and centralize audit logging. Turn on MarkLogic auditing for security events (role assignment, user creation/modification, privilege changes, external security changes) on every group, and forward AuditLog.txt to your SIEM with retention aligned to your IR requirements. Without this, you cannot answer the question that matters most after patching: did anyone escalate before we fixed it?
6. Hunt retroactively. Before assuming a clean bill of health, review 60–90 days of audit logs and management-endpoint access logs for admin role grants that cannot be tied to an approved change ticket, and for management API sessions from unexpected source IPs or user agents. Any unexplained admin grant on an unpatched server should be treated as a potential compromise and escalated to IR — including credential resets across the security database and review of deployed modules for tampering.
7. Enforce least privilege going forward. These CVEs are a textbook argument for shrinking the delegated-admin population. Re-justify every management role quarterly, use compartment-level roles instead of cluster-wide ones wherever possible, and require MFA on any authentication path that reaches the management endpoints (front the Admin UI with an identity-aware proxy if your IdP supports it).

The uncomfortable truth about delegated-admin flaws is that they convert "low-privilege breach" into "full database compromise" in a single step. The patch is the easy part; the role audit and the retroactive hunt are where you find out whether someone got there first.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub