mirth-connect-security-poc

PoCs funcionais para três vulnerabilidades do NextGen Connect 4.5.2.

CVSS 3.1 e 4.0 são padrões diferentes; as pontuações emparelhadas não são uma comparação de antes e depois.

Todos os três foram reproduzidos contra:

A NextGen relatou de forma privada que o problema de XSLT foi corrigido na 4.7.1 e os problemas de injeção SQL e de Lote XML foram corrigidos na 4.7.2. O aviso da CISA ICSMA-26-253-01 considera a 4.7.1 e anteriores como afetadas e recomenda a 4.7.2 ou posterior. Versões após a 4.5 são proprietárias, portanto não há imagem corrigida pública a partir da qual este repositório possa fornecer o mesmo tipo de controle negativo reproduzível usado para uma versão de patch de código aberto.

O que um atacante obtém

CVE-2026-82583: exposição do banco de dados e de segredos de integração

Um ponto de apoio autenticado na API administrativa torna-se acesso a dados que a conta não deveria exportar. O exploit empacotado grava a linha ativa PERSON_PASSWORD sob public_html e prova que o arquivo resultante é baixável sem autenticação. O passo que importa é ir de uma ação restrita da API para um arquivo em disco que não precisa mais da sessão do atacante.

Em um ambiente de integração real, o banco de dados pode descrever canais, endpoints e credenciais usadas para alcançar bancos de dados, servidores SFTP, retransmissores de e-mail, APIs e outros sistemas clínicos. Um teste controlado separado recuperou uma senha de conector deliberadamente plantada a partir do XML de canal exportado. Isso torna a primitiva útil para mapeamento de ambiente e roubo de segredos; o uso de qualquer credencial recuperada contra um sistema downstream não foi testado e não é alegado.

O braço opcional de negação de serviço congela o banco de dados Derby empacotado. Chamadas de API respaldadas pelo DB então expiram, a mesma injeção não consegue descongelar seu próprio ponto de entrada, e uma reinicialização do processo é necessária. Este é um ônus prático de recuperação para instalações respaldadas pelo Derby, não prova de que bancos de dados de produção externos se comportem da mesma forma.

CVE-2026-78224: divulgação não autenticada de arquivos do servidor e interrupção de canal

Uma vez que um canal XSLT afetado é implantado, o atacante não precisa de conta Mirth. O XML de entrada faz o serviço ler um arquivo local do alvo e enviar seu conteúdo para um callback controlado pelo atacante. Isso é útil mesmo quando a resposta normal do canal não contém os dados transformados e o atacante não consegue ler o histórico de mensagens.

O cliente autônomo aceita uma URI file: de linha única escolhida pelo chamador. Arquivos como identificadores de host, tokens, fragmentos de configuração ou credenciais são praticamente valiosos se a conta de serviço do Mirth puder lê-los e o servidor puder alcançar o callback. A prova empacotada usa apenas um canário gerado e não alega recuperação universal arbitrária de arquivos, transporte multilinha ou acesso além da conta de serviço.

Uma entidade externa lenta também ocupa o canal vítima padrão de thread única. Isso pode atrasar ou parar a interface clínica específica mapeada para esse canal até que a entidade seja liberada. O canal de controle e a API administrativa permanecem saudáveis, então isso é uma interrupção local ao canal, não uma indisponibilidade de todo o servidor.

CVE-2026-82578: exfiltração cega de arquivos por meio de entrada em lote

Quando um modo de lote XML afetado está habilitado, um remetente não autenticado pode usar o corpo bruto do lote para acionar o mesmo tipo de divulgação de arquivo de saída. O servidor retorna HTTP 500, mas o atacante já tem o conteúdo do arquivo exclusivo do alvo por meio do callback OOB. Isso torna a falha praticamente útil como um caminho de exfiltração cega mesmo quando testes apenas de código de resposta descartariam a requisição como uma falha de parser.

O processamento em lote está desativado por padrão, o modo de divisão deve alcançar o parser respaldado por XPath, e a saída do servidor é necessária. Este repositório não alega uma negação de serviço demonstrada para CVE-2026-82578.

Executar

Requisitos: Bash, Docker, Linux x86-64 e acesso à rede para o pull inicial da imagem. Ambas as imagens são fixadas por digest. Nenhuma porta do host é publicada; o alvo e o atacante se comunicam apenas em uma bridge Docker interna específica da tarefa.

Ou execute um único achado:

Cada invocação cria contêineres com nomes exclusivos e uma rede bridge, registra evidence/current-run.log e remove seus próprios recursos de laboratório ao sair. Os arquivos evidence/vulnerable-4.5.2.log versionados são transcrições de uma reprodução em Linux x86-64.

O que é e o que não é alegado

• A injeção SQL é demonstrada por meio do ponto de entrada REST real e do banco de dados Derby empacotado. O PoC exporta a linha ativa PERSON_PASSWORD e recupera o arquivo sem autenticação. Seu braço opcional de laboratório invoca SYSCS_FREEZE_DATABASE, após o qual as chamadas de API respaldadas pelo DB param de responder até que o alvo reinicie.
• O PoC de XSLT usa uma transformação de identidade fixa, instalada pelo administrador. O atacante controla apenas a mensagem de entrada não autenticada. Os conteúdos dos arquivos retornam por meio de um callback de DTD externo. Seu cliente autônomo aceita uma URI file: de linha única local ao alvo; o wrapper de laboratório usa um canário aleatório e asserção exata. A mesma execução prova a indisponibilidade local ao canal com um segundo canal saudável e API administrativa, e então verifica a recuperação.
• O PoC de Lote XML habilita o modo de lote XML comum do produto, Element Name. O atacante controla apenas o corpo do lote não autenticado. Seu cliente autônomo tem o mesmo modo --file-uri e a limitação OOB de linha única.
• Nenhum produto de saúde downstream, registro de paciente ou sistema de terceiros foi testado. Referências a possíveis PHI ou credenciais downstream descrevem consequências de implantação, não vítimas adicionais demonstradas.
• O candidato de caminho de exportação no checkout de pesquisa está intencionalmente ausente. A API é projetada para exportação do lado do servidor e o material fornecido não provou uma violação portável de fronteira de privilégio ou uma cadeia completa de execução de código.

Segurança

Execute apenas em um laboratório descartável de sua propriedade. O PoC de SQL congela deliberadamente o banco de dados alvo; a recuperação exige reiniciar o alvo. Os PoCs de XXE leem um canário montado por padrão, mas seus clientes autônomos aceitam URLs de listener arbitrárias e URIs de arquivo de linha única locais ao alvo. Nunca os direcione a sistemas sem autorização.

Mitigação

Segundo a CISA, atualize para o Connect 4.7.2 ou posterior. Onde uma atualização imediata não for possível, restrinja a API administrativa a redes de gerenciamento confiáveis, remova steps XSLT desnecessários, desative o processamento em lote XML onde não for necessário e bloqueie a saída desnecessária do servidor. Essas medidas reduzem a exposição, mas não reparam o código vulnerável.

Crédito

Os achados 1 e 3 devem ser creditados a Abhinav Agarwal. O achado 2 foi descoberto independentemente por Abhinav Agarwal e relatado pela primeira vez à NextGen por Youngdu. A NextGen coordenou as correções e a atribuição de CVE.

Uso defensivo pretendido

Este repositório tem como objetivo ajudar defensores a transformar texto de aviso em comportamento observável e testável. Em uma cópia isolada de um ambiente, defensores podem usá-lo para:

• determinar se o comportamento público da 4.5.2 está presente e entender os exatos pré-requisitos de configuração;
• validar que os controles do plano de gerenciamento impedem que contas não confiáveis alcancem a operação do Database Connector;
• confirmar que a filtragem de saída bloqueia o caminho de callback XXE testado;
• construir detecções para requisições suspeitas a _getTables, procedimentos inesperados de exportação ou congelamento do Derby, novos arquivos sob public_html, XML de entrada contendo um DOCTYPE e callbacks originados do Mirth após erros de listener;
• priorizar a rotação de credenciais de conector quando um plano administrativo afetado pode ter sido comprometido; e
• reexecutar as mesmas asserções contra uma build corrigida fornecida pelo fornecedor como um controle negativo local, mesmo que essa build não possa ser distribuída aqui.

Cada PoC é executado em um contêiner, fixa suas imagens por digest e falha de forma segura a menos que um canário aleatório retorne. Um defensor pode reproduzir a fronteira de segurança real em vez de aceitar uma captura de tela ou um número de severidade pela fé. Ele existe para ajudar as pessoas a descobrir o que estão executando, testá-lo e confirmar que um patch funcionou. Ele não está aqui para ser apontado para um hospital.