Progress published 31 MarkLogic flaws 32 days after the fixes shipped, and the August fixes miss them

The fixes were dated 10 September. The flaws were published 32 days later

Progress Software's release notes date MarkLogic Server 11.3.7 and 12.1.0 to 10 September 2026. Its security bulletin and the CVE records for 31 MarkLogic flaws are dated 12 October 2026. That is 32 days (derived) in which a fixed release existed and the flaws were not published. The bulletin lists the August fixes, 11.3.6 and 12.0.3, as affected, so a customer who installed those is not covered. By Progress's own scores, five of the 31 are Critical (three at 9.9, two at 9.6), 24 are High and 2 are Medium, which sums to 31 (derived from the CVE records).

What that does not establish matters most. Progress's bulletin, its upgrade notes and its CVE records say nothing about whether any of the 31 has been exploited, and none lists a workaround. The bulletin adds its own warning: "the absence of indicators does not establish that exploitation has not occurred". At 11:43 BST on 13 October none of the 31 was in the CISA Known Exploited Vulnerabilities catalogue (version 2026.10.08, released on 8 October), and no report of exploitation by any other source turned up in the searches made for this briefing. Absence from a list is not proof of absence. It is a timestamp.

Progress's CVE text says two of the five critical flaws let an attacker who already holds forest-management or manage-user-level privileges gain persistent administrator control. That is the sentence that travels, and the sections below test each label in it. The August fixes do not contain these corrections, the 12 line has no patched 12.0 release, and Progress's pages do not say whether anyone used the flaws between 10 September and 12 October, or before.

How this was read. The primary sources are Progress's own pages: the October bulletin and the August one on its customer community (they render only in a browser), the MarkLogic 11 and 12 release notes, upgrade notes and fixed-issue lists on docs.progress.com, and its Supported Versions page. The CVE records were read at CVE.org and NVD, the catalogue at CISA, and the Cyber Essentials requirements at the NCSC. The Hacker News article that prompted this briefing could not be fetched directly, because its site returned a bot check that was not bypassed. It was read from an Internet Archive capture taken at 09:21 UTC on 13 October and used only as a pointer. Every figure from it that appears here was re-checked against Progress. All sources were read between 11:16 and 11:45 BST on Tuesday 13 October 2026.

The coverage's claims, checked against Progress's pages

Every headline claim in the coverage of this story was checked against Progress's own pages. Most hold. Two wording points do not, and the table says which.

Claims in the coverage, what Progress's pages say, and whether the claim holds. Progress's bulletin of 12 October 2026, its release notes, upgrade notes and Supported Versions page, CVE.org, NVD and the CISA file, read 13 October 2026.

Claim	What Progress's pages say	Holds?
31 flaws published on 12 October	Bulletin dated Oct 12, 2026. All 31 CVE.org records show published on 12 October between 15:32 and 16:56 UTC.	Yes
Five critical: three at 9.9, two at 9.6	Progress's own CVSS 3.1 scores: CVE-2026-85947, 85948 and 85955 at 9.9; CVE-2026-85956 and CVE-2026-9191 at 9.6. The bulletin does not count them.	Yes. The count is derived.
Fixes available since 10 September	Both release notes say "Released: September 10, 2026" for 11.3.7 and 12.1.0.	Yes
11.3 is long-term support, 12 is an innovation release with no patched 12.0	Supported Versions: 11.3 LTS, 12.0 and 12.1 Innovation. The bulletin maps 12.0 to 12.0.3 to 12.1. The 12 release notes list no later 12.0 release.	Yes, as read on 13 October
The August fixes are not enough	The bulletin lists 11.0 to 11.3.6 and 12.0 to 12.0.3 as affected.	Yes
Two flaws let an account with some management privileges take admin control	CVE-2026-85947: forest-management privileges, "a persistent, unauthorized administrator account". CVE-2026-85948: manage-user-level privileges, "persistent unauthorized administrative control".	Yes, two. "Delegated manager" is the coverage's label, not Progress's
Each critical flaw needs a privilege or a way to run code	Four CVE texts name a privilege. CVE-2026-9191 says "an attacker able to execute code through an affected path", but its CVSS vector scores privileges required as none and user interaction as required.	Partly. The text and the vector disagree for one
None in CISA's catalogue	File version 2026.10.08, released 8 October. None of the 41 MarkLogic CVEs of 2026, read at 11:43 BST on 13 October.	Yes, at that time
No exploitation statement and no workaround	None in the bulletin, the upgrade notes or the CVE.org records, which carry no workaround field for any of the 31.	Yes
A forest-scoped grant is no longer enough, and roles holding an eval privilege should be audited	The 11.3.7 and 12.1.0 upgrade notes say both, in the sections for CVE-2026-85947 and CVE-2026-85955.	Yes

The wording point is the label. "Delegated" appears in Progress's upgrade notes for the forest flaw ("delegated automation", "delegated forest and database privilege assignments") and in the CVE text for the backup and restore flaw ("delegated database-administrator privileges"). For the second admin-control flaw, Progress's CVE says manage-user-level privileges and does not use the word. So "delegated manager to admin" is a fair shorthand for the first and the coverage's gloss on the second.

The five critical flaws: what Progress says the attacker already has

Progress's CVE text for each critical flaw names what the attacker needs first and what they get. The third column is what the 11.3.7 and 12.1.0 upgrade notes say changed in the product, which is the most precise statement of what was wrong. All five vectors are scored with scope changed, which the CVSS 3.1 specification defines as a flaw that "impacts resources in components beyond its security scope" (derived from the vectors).

The five critical MarkLogic flaws, from Progress's CVE records and bulletin of 12 October 2026 and its 11.3.7 and 12.1.0 upgrade notes. Scores are Progress's own CVSS 3.1 base scores.

CVE and score	Needs, and gets (Progress's CVE text)	What the upgrade notes change
CVE-2026-85947, 9.9	Needs forest-management privileges. Gets "a persistent, unauthorized administrator account", "potentially resulting in complete unauthorized administrative control of the server".	Attaching a forest is authorised against the forest and the target database. "A forest-scoped administrative grant is no longer sufficient by itself to attach that forest to a caller-selected database."
CVE-2026-85948, 9.9	Needs manage-user-level privileges. Gets "persistent unauthorized administrative control", through an injection flaw in a deprecated Management API package path.	The deprecated packages interface is removed "with no flag or fallback to re-enable it". Automation that used it will fail.
CVE-2026-85955, 9.9	Needs query-execution access, then calls an evaluation function without the additional evaluation privilege. Gets server-side code execution with elevated permissions.	The function now needs both evaluation privileges. Roles holding only the narrower one fail, and Progress says to audit them.
CVE-2026-85956, 9.6	Needs delegated database-administrator privileges. Gets backup or restore on forests outside the authorised database, and "unauthorized access to or modification of security-critical data".	Backup and restore are authorised against the databases and forests named in the request, "rather than against only the database identified in the request URL".
CVE-2026-9191, 9.6	Text: an attacker "able to execute code through an affected path". Vector: no privileges, user interaction required. Gets unauthorised actions or a compromised authenticated session.	Code run through REST and XDBC evaluation paths is isolated from request, response and session state. Code that read or changed them will fail.

Two of the five describe administrator control. Progress's word for the result is "persistent", and it does not define it beyond account creation or ongoing control. The upgrade notes explain how the check was repaired. They do not say whether upgrading removes or flags an administrator account created through the flaw before the upgrade, and the bulletin offers no clean-up step. Inference, labelled: a fix to an authorisation check protects accounts that do not yet exist, so an organisation that was exposed has to look for the ones that do.

Stated and not stated: the record, line by line

The table sets what Progress's pages state against what none of them states. "Not stated" means not found in the bulletin, the release and upgrade notes, the fixed-issue lists, the Supported Versions page or the CVE records. It does not mean the information does not exist.

What Progress's pages state about the 31 flaws, and what they do not, read 13 October 2026.

The question	Stated	Not stated
Has any been exploited?	Nothing, except the warning that missing indicators prove nothing. The CISA catalogue lists none of the 41 MarkLogic CVEs of 2026 (version 2026.10.08, read 11:43 BST).	Any statement of exploitation or non-exploitation by Progress. No threat-intelligence report was found in the searches made.
Is there a workaround?	Upgrade to 11.3.7 or 12.1. The only workaround wording is a temporary setting for older mlcp clients after upgrading, which is a compatibility step.	Any mitigation for a customer who cannot upgrade yet.
Who holds the privileges?	The CVE text names them: forest-management, manage-user-level, query-execution, delegated database-administrator.	How many accounts hold them in practice, or how common delegated grants are. No source says.
How many servers are exposed?	Progress's [hardening page](https://docs.progress.com/bundle/marklogic-server-secure-12/page/topics/securing-your-production-deployment/infrastructure-hardening/port-management.html), updated 6 October, says to keep the Admin Interface and development tool ports (8000, 8001, 8002) behind a corporate firewall.	Any count of internet-exposed MarkLogic servers. Searches found none, and none is given or guessed here.
Does the cleartext cluster flaw need a network position?	CVE-2026-85973 (12.x only, 7.4): "A network-positioned attacker could intercept or modify" cluster-management traffic. The vector scores network access and high complexity.	Which position counts, whether real clusters cross untrusted networks, or any setting to change after upgrading. It is absent from the upgrade notes.
Does upgrading remove an admin account already created?	The fix changes an authorisation check.	Any removal, flag or clean-up step.
What did the notes say before 12 October?	The release notes call 11.3.7 "a patch and security update" and 12.1.0 "a feature and security update". Both pages show Last Updated: October 12, 2026.	What either page said between 10 September and 12 October. No earlier capture was found.
Do retired releases contain the flaws?	"Retired MarkLogic Server releases were not included in the complete assessment and do not receive fixes."	Whether 10.x or 9.x is affected. The August bulletin had listed 10.x and earlier as affected.
Who has been patched already?	"Customers using MarkLogic Server on Progress Data Cloud were patched and are no longer vulnerable to these issues."	Whether any other managed or marketplace deployment has been upgraded, or when.

One more computed fact bears on the timeline, with its limit stated. The CVE.org records show 30 of the 31 IDs reserved on 4 September 2026, six days before the fixed releases and 38 days before publication (derived), and CVE-2026-9191 reserved on 21 May. A reservation shows that an ID existed. It does not show what Progress knew, or when.

Four labels that sound like containment

"Delegated", "forest-scoped", "least privilege". The NCSC's secure administration guidance says "Just enough Administration is another way of describing the concept of least privilege" (NCSC). That holds only if the product enforces the scope on every object an operation touches. Progress's upgrade notes describe two places where it did not: forest attachment was authorised against the forest but not against the database receiving it, and backup and restore were authorised against the database in the request URL but not the forests the request named. A grant labelled forest-scoped described what it was meant to cover. The check decided what it did cover. This site's briefing on a Veeam role documented as read-only found a similar shape in another product: a role documented as read-only was all the attacker needed.

"Authenticated". Four of the five critical CVE texts need an account, which sounds like a gate. Progress's vectors score all four as low privileges required. The CVSS 3.1 specification defines low as "basic user capabilities that could normally affect only settings and files owned by a user". Whether a forest-management or manage-user-level grant fits that definition is a judgement, and the score rests on it (inference): the lower the privilege required, the higher the base score. Progress's pages do not say how many accounts hold these privileges anywhere, and an estate that delegates management widely may have many that qualify. The gate is also thinner than the word: 14 of the 31 vectors score privileges required as none (derived), including 13 of the 26 rated High or Medium. One example is CVE-2026-85962, 7.5, where in deployments that use SAML authentication an unauthenticated remote attacker could cause the server to accept an assertion that should be rejected.

"Critical" and "High". The band orders flaws by the impact assumed once the precondition is met. It does not order them by how many accounts or networks meet the precondition. The 26 flaws below the critical line ship in the same two releases, so nothing is gained by upgrading for the five and leaving the rest.

"LTS" and "innovation release". Progress calls 11.3.7 "a patch and security update to the MarkLogic 11.3 LTS release", and 12.1.0 "a feature and security update to the MarkLogic 12 innovation release". On the 12 line there is no patch: the bulletin maps every 12.0 release to 12.1. Progress's Supported Versions page lists 12.0 as Active with 12.0.3 as its latest release, and the bulletin lists 12.0.3 as affected, so "Active" and "latest in its line" are not the same as fixed. On the 11 line the same page shows each innovation release (11.0, 11.1, 11.2) marked Retired in the month its successor shipped (derived from the table), a pattern and not a promise. It shows no retirement date for 12.0 on 13 October, 33 days after 12.1.0. Nor is "patch" a small word: the 11.3.7 upgrade notes tie behaviour changes to 22 CVEs and the 12.1.0 notes to 21 (derived counts), and 11.3.7 removes a deprecated Management API interface, InfoStudio and OpsDirector and drops Amazon Linux 2.

Which release fixes what, by line, to scale

The figure puts every date on one scale: the 11.3 line on the left, the 12 line on the right, Progress's two bulletins as bands, and the 32 days on the axis. Read it for what sits on the wrong side of each band. 11.3.6 and 12.0.3 were fixes for the August flaws and are the affected releases for the October ones.

Which line a server is on decides how large the move is. 11.3.6 to 11.3.7 stays inside a long-term support line. 12.0.3 to 12.1.0 changes release line, and Progress's release notes describe 12.1.0 as adding Optic and vector features and OAuth 2.0 sign-in for its management tools. The retired lines are the hard case. Progress says retired releases "do not receive fixes" and were not fully assessed, and the August bulletin had listed them as affected. The same problem, a fix that exists only for newer lines, is the subject of this site's briefing on Apache Struts end-of-life branches.

The other 26: configuration decides

Progress scored 24 of the remaining flaws High and two Medium, with the highest at 8.6. The groupings below are this briefing's, made from Progress's CVE text, and they sum to 26 (derived). Many apply only where a named feature or platform is in use, and Progress's wording on each is the condition.

The 26 non-critical flaws grouped by what Progress's CVE text says they affect. Scores are Progress's CVSS 3.1 base scores. Counts and ranges are derived.

Group and count	Scores	What Progress says it depends on
Authentication and identity (4)	7.4 to 7.5	SAML assertions (85962) in deployments that use SAML. A token that should be rejected (85958), with the notes naming Ping Identity and other OAuth configurations. Kerberos service identity (85972) in certain password-based configurations. An external-entity setting in the SAML parser (85957), 11.x only.
Privilege and access control (4)	7.7 to 8.6	The highest, CVE-2026-85954 at 8.6: values passed to certain higher-order functions are evaluated in an elevated context. Authentication material of higher-privileged users (85950). Security-sensitive information readable with limited management permissions (85966). Legacy InfoStudio modules (85953).
Cloud and request forgery (3)	7.5 to 8.5	Azure (85951) and Linux-based cloud (85952): an authenticated attacker reaching internal cloud services. The deprecated OpsDirector (85963): an unauthenticated remote attacker. OpsDirector is removed in 11.3.7 and 12.1.0.
Logging and audit (4)	7.1 to 8.1	Secrets in diagnostic logs under certain configurations (85949), and on Azure (85961). Successful authentication events not consistently recorded in audit logs (85959). Over-permissive log file permissions (85971): existing logs keep them until rotated.
Query Console web flaws (4)	5.4 to 7.7	Predictable CSRF tokens (85960), an unsafe file path (85964), cross-site scripting (85967, Medium), HTTP response splitting (85976, Medium).
Transport and TLS (3)	7.4 to 7.5	Cleartext cluster-management traffic (85973), 12.x only. Inconsistent TLS hostname checks on some outbound connections (85974). Cleartext S3 by default (85975). Each text says a network-positioned attacker.
XML processing (1)	7.1	External entity processing enabled by default in multiple server paths (85970).
Memory safety (3)	7.1 to 8.0	Use after free in the JavaScript engine integration (85965). Out-of-bounds read (85968), 12.x only. Out-of-bounds write (85969).

One row changes the response. CVE-2026-85959 says successful authentication events were not consistently recorded in audit logs. That is the log a team would read to look for misuse of the first group, so the evidence for a review is itself on the list, and Progress's own caution about indicators applies.

What the 32 days mean for a customer who patches on disclosure

The August batch followed the same order. 11.3.6 is dated 1 July and 12.0.3 is dated 6 July, and Progress's first bulletin is dated 5 August, 35 and 30 days later (derived). The second bulletin came 68 days after the first (derived), and 36 days after the first bulletin Progress shipped the releases that fix the second set. Two batches are two data points, and Progress states no policy on the lag. But in both, the fix came first and the explanation after.

Patching clocks for the 10 September release, counted from the release and from the 12 October disclosure. Cyber Essentials v3.3 (April 2026) and the NCSC's update-by-default guidance. Dates are derived.

Clock	From the release, 10 September	From the disclosure, 12 October
Cyber Essentials v3.3: 14 days	24 September (Thursday). Passed 18 days before the bulletin and 19 days before this read.	26 October (Monday), 13 days after this read
NCSC best practice, internet-facing: 5 days	15 September	17 October
NCSC best practice, operating systems and applications: 7 days	17 September	19 October
NCSC best practice, internal or air-gapped: 14 days	24 September	26 October

Cyber Essentials v3.3 requires updates to be installed "within 14 days" of release where the update fixes vulnerabilities the vendor describes as critical or high risk, or that score CVSS 3 base 7 or above, or where "there are no details of the level of vulnerabilities that the update fixes provided by the vendor". Its caution adds that a single update covering any critical or high-risk issue must be installed within 14 days. The document counts from release. It does not say what an assessor should do when the vendor describes the severity weeks later. The NCSC's update-by-default guidance counts from publication of the update, says the timescales "apply to all updates, regardless of the vulnerability severity", and warns that vendors may "silently" update some vulnerabilities without public acknowledgement.

Inference, labelled. A customer whose process starts at the bulletin starts its clock 32 days after the release. Measured from release, the Cyber Essentials mark had passed 18 days before the bulletin appeared, so that customer would already have been past a release-based mark on the day it learned why. A customer who updates by default, as the NCSC advises, would not have been held by the lag, because the process never waited for the explanation. The NCSC also notes that once a vulnerability is fixed, attackers will often study the fix and try to write exploits for it. No source says that happened here.

The UK: Cyber Essentials, the NCSC, the ICO and the supplier

Who runs MarkLogic in the UK is not established. Progress's MarkLogic pages list financial services, healthcare, insurance, manufacturing, pharma and biotech, public sector and retail among the industries it serves (the site menu, read 13 October), and no source read for this briefing counts UK deployments, versions or internet-facing instances. Treat any list of sectors as a prompt to look at your own estate, not as a measure of exposure.

Cyber Essentials v3.3. The requirements (April 2026) apply the security update rule to servers and define software to include commercial off-the-shelf applications, so a database server on an in-scope host is covered. Software must be "licensed and supported", defined as software a vendor has committed to support with regular vulnerability fixes and a stated end date, and must be removed or taken out of scope behind a sub-set that blocks internet traffic when it becomes unsupported. Progress's page shows MarkLogic 10.0 retired from 1 April 2026 and its bulletin says it receives no fixes. Against the CE definition that looks like unsupported software (inference; an assessor decides). The user access control section aims to give each account "only those applications, computers and networks that the user needs" and requires special privileges to be removed when no longer required. That is the home for a delegated forest or database grant, and it says nothing about whether the product enforces the scope. A control that is only a role assignment is only as good as the check behind it.

NCSC guidance. On privilege, the secure system administration collection says "Administration interfaces are an attack surface" and advises isolating them with architectural controls, which is the same advice as Progress's own port guidance. Its log and audit page says monitoring administrators' activity will "enable you to identify misuse of administrative privileges", which is what the review in item 6 below depends on, and which CVE-2026-85959 weakens. The NCSC's patch wave blog of 1 May 2026 tells organisations to prepare to patch "quickly, more often, and at scale" and says patching alone will not always suffice where software is end of life.

The ICO. If a MarkLogic database holds personal data and an exposed flaw was used to read or change it, the UK GDPR duty to report certain breaches applies. The ICO's guide says a report must be made "within 72 hours of becoming aware of the breach, where feasible", where a risk to people is likely. Its data security guide says security measures must be appropriate to the risk and that you should ensure any processor you use also implements them. The 72 hours start on awareness, not on the date of a flaw, so a log review that finds an unexpected administrator account starts a clock.

Managed MarkLogic. Progress says customers on Progress Data Cloud were patched. For any other arrangement, an outsourced operator, a marketplace image, or an application vendor that embeds MarkLogic, put the questions in writing: which version runs, whether it has been upgraded to 11.3.7 or 12.1, on what date, who reviewed the delegated privilege assignments and the roles holding the evaluation privilege first, and whether administrator accounts and role changes were reviewed for the exposure period. If the supplier is a processor, the same questions go into the review of the contract.

What to do, in the order worth doing

Every item is drawn from Progress's bulletin and upgrade notes, the NCSC, Cyber Essentials or the ICO. Item 3 is what Progress's notes say to do before upgrading. Defender level only: nothing here needs a test of the flaws.

What could not be verified

• The Hacker News article. A direct fetch met a bot check, which was not bypassed. It was read from an Internet Archive capture of 13 October at 09:21 UTC, and every figure used here was re-checked against Progress, NVD, CVE.org and the CISA file.
• Exploitation. No statement by Progress and no threat-intelligence report was found. Several web searches, including one for exposure counts, found only third-party copies of the CVE records.
• Exposure. No count of internet-exposed MarkLogic servers was found, and none is given.
• What Progress's pages said before 12 October. Both release-notes pages show Last Updated: October 12, 2026, and no earlier capture was found.
• Retired lines. Whether 10.x or 9.x contains the flaws is not stated by Progress.
• Progress's life cycle policy. The Supported Versions table was read. The policy document linked from it opened only as a viewer page, so its definitions of Active, Sunset and Retired were not read.
• NVD analysis. NVD shows all 31 records as Received, with the scores from Progress as CNA. CISA's enrichment container had not appeared on CVE.org for any of them.
• Time-stamped. Sources were read between 11:16 and 11:45 BST on 13 October 2026. A catalogue entry, a page's wording or a new report could change within hours.

The question that exposes the gap

If a grant labelled forest-scoped could make an account an administrator, what was the label measuring: what the account was allowed to do, or what the product checked? And could anyone in your organisation list, before the end of today, every account that holds one?

Key facts