Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ: Authenticated users could perform RCE via Jolokia MBeans

Falha de code injection no bridge Jolokia (JMX-HTTP) do console web do Apache ActiveMQ Classic, que permite a um usuário já autenticado no broker executar código arbitrário na JVM do servidor. O CVSS de 8.8 reflete o impacto total (RCE), mas a exigência de credenciais válidas (PR:L) reduz a superfície real de exploração a instâncias com console Jolokia exposto e credenciais fracas, padrão ou vazadas. Está no catálogo KEV da CISA com exploração confirmada in-the-wild e prazo de correção até 30/04/2026.

O ActiveMQ Classic expõe o endpoint /api/jolokia/ no console web, que traduz chamadas HTTP em operações JMX contra os MBeans do broker (org.apache.activemq:*). A política de acesso padrão do Jolokia permite invocar operações exec em qualquer MBean dessa família, incluindo BrokerService.addNetworkConnector(String) e BrokerService.addConnector(String) — métodos pensados para configuração administrativa em tempo de execução, não para receber entrada de terceiros sem validação (CWE-20, Improper Input Validation).

Um atacante autenticado pode passar a esses métodos uma discovery URI manipulada que aciona o transporte VM com o parâmetro brokerConfig apontando para um contexto de aplicação Spring remoto, carregado via ResourceXmlApplicationContext. O problema de fundo (CWE-94, Code Injection) é que o Spring instancia todos os beans singleton do XML antes que o BrokerService valide a configuração recebida — ou seja, a validação de segurança do broker chega depois que o container Spring já executou os construtores e factory-methods dos beans declarados no XML.

Se o XML remoto declarar um bean cujo factory-method chame Runtime.exec() (ou equivalente), o código do atacante roda na JVM do broker durante a própria instanciação do contexto Spring — antes de qualquer checagem de sanidade da configuração. O atacante controla integralmente o conteúdo do XML servido remotamente e, portanto, os argumentos passados ao processo executado.

O vetor exige HTTP contra o console web do ActiveMQ (porta padrão do console, tipicamente 8161) com o endpoint Jolokia acessível e credenciais válidas de um usuário autenticado — não é uma falha pré-autenticação. O pré-requisito real de acesso autenticado é o fator que mais limita o alcance prático: ambientes com Jolokia desabilitado, console não exposto à rede, ou apenas com contas administrativas fortes e isoladas não são atingidos por esse vetor específico, mesmo que o binário esteja em versão vulnerável.

Com uma sessão autenticada, o ataque consiste em invocar via HTTP as operações exec de BrokerService.addNetworkConnector ou addConnector com uma URI de descoberta forjada que força o transporte VM a carregar um Spring XML hospedado pelo atacante. Como a instanciação dos beans do Spring ocorre antes da validação do broker, não é necessário que a configuração final seja "válida" — o código já foi executado no momento em que o container Spring monta o contexto.

O resultado final é execução arbitrária de código no contexto do processo do broker (normalmente com os mesmos privilégios do usuário de sistema que roda o ActiveMQ), o que costuma implicar controle total da instância de mensageria e, a partir dela, pivotagem lateral. A presença no catálogo KEV da CISA confirma exploração ativa observada em campo; a disponibilidade pública de PoC, módulo Metasploit e template Nuclei indica que a barreira técnica para reprodução é baixa para quem já possui uma credencial válida no console.

O anúncio oficial da ASF recomenda atualizar para a versão 5.19.4 (linha 5.x) ou 6.2.3 (linha 6.x). Há divergência entre fontes sobre o número exato do release da linha 5.x: a descrição da CVE e a página do NVD citam 5.19.4, enquanto o e-mail original do mantenedor da ASF na lista oss-security e o bug tracker da Red Hat citam 5.19.5 como a versão corrigida. Antes de considerar o ambiente corrigido, confirme no changelog/release notes oficial do projeto qual dessas duas é a versão que efetivamente contém o patch — não assuma pela CVE isoladamente.

Como controle compensatório quando a atualização não é imediata: restrinja ou desabilite o acesso ao endpoint Jolokia (/api/jolokia/) no console web, revise e restrinja a política de acesso do Jolokia para não permitir operações exec sobre MBeans org.apache.activemq:* de forma irrestrita, e isole o console administrativo do ActiveMQ da rede geral (acesso só por VPN/bastion, nunca exposto diretamente à internet). Reforçar credenciais (senhas fortes, rotação, MFA onde aplicável) reduz a chance de um atacante externo obter a autenticação necessária, mas não elimina o risco de um usuário interno com acesso legítimo abusar da falha — o controle definitivo é a atualização de versão combinada com a restrição de rede ao console.

Não funciona como mitigação: apenas trocar a senha do usuário administrativo sem também restringir a exposição de rede do console/Jolokia, já que qualquer conta autenticada — não apenas admin — pode ser suficiente dependendo da política de acesso configurada. Também não basta um WAF genérico na frente do console, pois a exploração ocorre via chamadas HTTP legítimas de API (Jolokia) que um WAF sem regras específicas para esse endpoint não vai diferenciar de uso administrativo normal.

Procure no log de acesso do console web por requisições POST ao endpoint /api/jolokia/ que invoquem os MBeans BrokerService com as operações addNetworkConnector ou addConnector, especialmente com parâmetros de discovery URI contendo referências a transporte VM (vm://) combinadas com brokerConfig apontando para URLs externas (http/https) de arquivos XML. Tráfego de saída do host do broker para servidores externos buscando arquivos .xml também é um indicador forte, já que o carregamento do Spring ApplicationContext remoto exige uma conexão de saída no momento da exploração.

Não há assinatura única e confiável, porque a chamada em si usa a API legítima do Jolokia — a diferenciação depende do conteúdo dos parâmetros da requisição (URI de discovery incomum, referência a domínios externos) e não de um padrão de tráfego malformado. Ambientes sem logging detalhado do payload das requisições ao Jolokia (não só a URL do endpoint, mas o corpo JSON da chamada MBean) terão dificuldade real de reconstruir se a exploração ocorreu.