MarkLogic Server: 31 vulnerabilità, cinque critiche. Aggiornare a 11.3.7 o 12.1.0

• Progress ha divulgato 31 falle in MarkLogic Server, cinque critiche (CVSS 9.9 e 9.6)
• Due permettono a account con privilegi delegati di ottenere il controllo amministrativo
• Colpite le versioni 11.x prima di 11.3.7 e 12.x prima di 12.1.0; nessun workaround
• Nessuna risulta sfruttata o nel catalogo KEV della CISA al 13 ottobre

Il 12 ottobre Progress Software ha reso pubbliche 31 vulnerabilità nel database MarkLogic Server. Cinque sono classificate come critiche. Secondo l’azienda, due di queste consentirebbero a un account con soli privilegi di gestione delegati di ottenere il controllo amministrativo del server. Le correzioni sono disponibili dal 10 settembre.

Versioni colpite e correzioni

• MarkLogic 11.x precedenti alla 11.3.7: aggiornare a 11.3.7.
• MarkLogic 12.x precedenti alla 12.1.0: aggiornare a 12.1.0.

La linea 11.3 è quella a supporto a lungo termine (LTS). La linea 12 è definita da Progress «innovation release» e non ha una versione 12.0 corretta: la soluzione è la 12.1.0, che aggiunge anche nuove funzioni. Chi ha installato le correzioni per le 10 vulnerabilità di agosto (11.3.6 e 12.0.3) è comunque esposto ai nuovi difetti.

I record CVE e le note di aggiornamento non indicano sfruttamento in attacchi. Al 13 ottobre nessuna delle 31 risultava nel catalogo KEV della CISA. Non sono indicati workaround per chi non può aggiornare subito.

Le vulnerabilità critiche

Tre hanno punteggio CVSS 9.9 su 10, due 9.6. In tutti i casi l’attaccante deve già disporre di un privilegio o della possibilità di eseguire codice sul server. Due riguardano i «forest», cioè insiemi di documenti collegati a un database.

La correzione di CVE-2026-85947 chiarisce il problema: un’autorizzazione amministrativa limitata a un forest non basta più, da sola, per collegarlo a un database a scelta dell’account. Le note raccomandano di rivedere le assegnazioni di privilegi delegati su forest e database prima dell’aggiornamento e di verificare i ruoli che hanno xdmp-eval-in.

Quattro delle cinque critiche sono state segnalate tramite Bugcrowd. Il ricercatore «rexnets» è accreditato per CVE-2026-85947, CVE-2026-85948 e CVE-2026-85956; «WaltWhitehat» per CVE-2026-9191.

Le altre falle

Delle restanti, 24 sono alte e due medie. La più grave, CVE-2026-85954 (8.6), permetterebbe di ottenere più privilegi del dovuto passando valori a certe funzioni XQuery. Molte dipendono dalla configurazione:

• SAML: un attaccante remoto non autenticato potrebbe far accettare un’asserzione che andrebbe respinta (CVE-2026-85962); su 11.x il parser può elaborare DTD o entità esterne (CVE-2026-85957).
• OAuth: possibile uso di un token che non dovrebbe essere accettato (CVE-2026-85958).
• Kerberos con password: un attaccante in posizione di rete potrebbe impersonare il servizio di autenticazione (CVE-2026-85972).
• Cloud: un utente autenticato potrebbe raggiungere servizi interni e ottenere credenziali cloud su Azure (CVE-2026-85951) e su Linux (CVE-2026-85952).
• Log diagnostici: informazioni sensibili scritte nei log (CVE-2026-85949, CVE-2026-85961 su Azure); con il tracciamento IAM attivo, chiavi segrete e token di sessione AWS finivano in chiaro.
• Amazon S3: connessioni in chiaro per impostazione predefinita (CVE-2026-85975).
• Query Console: esecuzione di codice lato server con i permessi di un utente connesso che apra una pagina malevola (CVE-2026-85960); lettura di file arbitrari da parte di un utente autenticato (CVE-2026-85964).
• Componenti legacy: OpsDirector (CVE-2026-85963) e moduli InfoStudio (CVE-2026-85953).

Completano l’elenco tre problemi di sicurezza della memoria, un cross-site scripting, un HTTP response splitting in Query Console, controlli incoerenti del nome host TLS e traffico di gestione del cluster in chiaro su 12.x. Con CVE-2026-85959, inoltre, gli accessi riusciti non sempre venivano registrati nell’audit log, il che può ostacolare il rilevamento di accessi non autorizzati.

Cosa cambia con l’aggiornamento

Progress invita a leggere le note di aggiornamento e le incompatibilità note prima di procedere. Alcune modifiche possono rompere codice o automazioni:

• Le vecchie versioni di MarkLogic Content Pump (mlcp) falliscono con errore XDMP-ISOLATED; si raccomanda mlcp 11.3.7 o 12.1.0.
• Rimossi l’API /manage/v2/packages, InfoStudio e OpsDirector.
• Elaborazione di entità XML esterne disattivata, S3 su HTTPS, file ErrorLog.txt e AuditLog.txt creati con modo 0640.
• xdmp:eval-in() richiede sia xdmp-eval-in sia xdmp-eval; la lettura degli header Authorization richiede un nuovo privilegio che nessun ruolo predefinito possiede.
• Le risposte di configurazione FlexRep non restituiscono più password e chiavi private memorizzate.
• MarkLogic 11.3.7 non supporta Amazon Linux 2.
• L’aggiornamento può fallire se esistono già ruoli, utenti o privilegi con uno dei cinque nomi usati dal nuovo sistema di ticket.

Per CVE-2026-85954 le note avvertono che potrebbero venire meno privilegi prima disponibili, perché quell’accesso era errato. I file di log esistenti mantengono i vecchi permessi finché non vengono ruotati o ricreati. La correzione Kerberos richiede un keytab: senza, il server registra un avviso e salta il nuovo controllo. Non è chiaro se l’aggiornamento rimuova un account amministratore creato tramite CVE-2026-85947 prima dell’upgrade.

Il secondo lotto in 68 giorni

È il secondo lotto per MarkLogic dopo quello del 5 agosto: 10 falle, sette critiche, tra cui CVE-2026-9192 (9.8), che consente a un attaccante remoto non autenticato di aggirare la verifica della password sull’ODBC App Server. Anche allora le correzioni (rilasciate il 1° e il 6 luglio) sono arrivate prima della pubblicazione dei CVE, con un intervallo di 35 e 30 giorni; stavolta 32.

Fonte: The Hacker News · Foto: The Hacker News