MarkLogic: privilégio delegado precisa continuar delegado depois de cada operação

A Progress divulgou 31 vulnerabilidades do MarkLogic Server em 12 de outubro de 2026, com correções disponíveis desde 10 de setembro nas versões 11.3.7 e 12.1.0.[3] Cinco falhas são críticas, e algumas permitem transformar permissões delegadas em administração persistente.[3] O ponto de engenharia não é apenas instalar uma versão nova: é verificar se as fronteiras de autorização continuam existindo depois de uma operação administrativa.

O que muda para quem desenvolve

A CVE-2026-85947 permite criar uma conta administrativa persistente a partir de privilégios de gerenciamento de forests, conjuntos de documentos associados a bancos.[3] A CVE-2026-85948 permite resultado semelhante por injeção XQuery em um caminho obsoleto da Management API, usando permissões de gerenciamento de usuários.[3] As cinco falhas críticas exigem alguma permissão prévia ou capacidade de executar código.[3]

Isso torna insuficiente uma avaliação limitada a acessos anônimos. Minha recomendação é modelar também o que um usuário autenticado consegue alcançar além de sua atribuição. Uma conta que administra somente um banco não deveria conseguir restaurar dados de outro ou criar um administrador global.

O upgrade também altera comportamento: remove APIs legadas, desabilita entidades XML externas por padrão, passa conexões S3 para HTTPS e acrescenta verificações de autorização.[3] A atualização de segurança, portanto, precisa entrar no planejamento de compatibilidade das aplicações.

Como aplicar

Primeiro, confirme a versão do servidor e dos clientes de carga. As versões 11.3.6 e 12.0.3 não corrigem esse novo conjunto; na linha 12, a correção indicada é 12.1.0.[3] Versões antigas do MarkLogic Content Pump podem falhar com XDMP-ISOLATED após a mudança.[3]

Prepare uma matriz pequena de testes por papel: leitura, consulta, criação de usuários, administração de forests e backup. Para cada operação, escreva tanto o resultado permitido quanto o resultado que deve ser negado. Execute o roteiro em uma cópia de homologação, com dados fictícios e contas de menor privilégio. Não use uma conta global para testar tudo, porque ela não representa a fronteira que precisa ser validada.

Inclua integrações de autenticação e armazenamento no aceite. A correção Kerberos depende de keytab; sem ele, o servidor avisa e não executa a nova verificação.[3] Revise ainda permissões dos logs existentes, que não são automaticamente endurecidas até rotação ou recriação.[3]

Registre incompatibilidades encontradas antes de promover a mudança, mas não transforme homologação em adiamento sem prazo. Defina responsável e data para resolver cada bloqueio.

Cuidados e limites

A documentação resumida pela reportagem não esclarece se o upgrade remove uma conta administrativa criada anteriormente por exploração.[3] Os avisos também não informam exploração confirmada nem workaround para quem não pode atualizar.[3]

Por isso, eu separaria atualização e investigação. Revise contas, papéis e mudanças administrativas conforme o risco do ambiente, sem afirmar que uma conta desconhecida prova exploração. Uma versão corrigida protege um caminho vulnerável; a confiança no estado atual exige evidência adicional.

Fonte

[3] Fonte: The Hacker News