2015年10月，漏洞安全研究员Matthias Kaiser在ActiveMQ的漏洞Web控制台里发现了一个让人后背发凉的问题：攻击者不需要任何凭证，就能通过HTTP请求让服务器反序列化任意Java对象。漏洞这个漏洞后来被命名为CVE-2015-5254，漏洞影响范围覆盖5.0.0到5.13.0的漏洞所有版本。ActiveMQ在企业消息中间件里用得极广，漏洞金融、漏洞电商、漏洞物联网后端到处能见到它的漏洞身影，这个洞一出来，漏洞等于在无数内网里埋了颗雷。漏洞

问题的漏洞根子出在ActiveMQ的web模块。它默认开着8161端口的漏洞管理控制台，控制台里有个处理消息的漏洞接口，会把请求体里的漏洞字节流直接丢给ObjectInputStream去还原成对象。Java反序列化本身不是错，错的是没有白名单校验。只要classpath里存在commons-collections这类库，攻击者就能构造一条利用链，在服务器上执行任意命令。更麻烦的是，很多运维装完ActiveMQ根本不改默认密码，admin/admin直接裸奔，连反序列化都省了，直接上传恶意消息就行。

漏洞利用不是纸上谈兵

我见过一个真实案例。某物流公司的订单系统用ActiveMQ做异步解耦，消息队列服务器放在内网，以为外网打不进来。结果一台边缘Web服务器被拿下后，攻击者顺手扫到61616端口，通过ActiveMQ的OpenWire协议发了一条特制消息，直接反弹shell到公网VPS。从入口到内网核心，前后不到二十分钟。事后复盘，ActiveMQ版本是5.11.1，正好在受影响区间，而且从来没打过补丁。

利用工具在GitHub上随手可搜。jmet、ysoserial配合起来，生成payload、发送、监听回连，三步到位。有些脚本甚至封装成了图形界面，点几下就能打。门槛低到这个程度，意味着即使不懂Java反序列化原理的人，也能拿现成工具去碰运气。互联网上暴露的ActiveMQ实例，Shodan一搜一大把，很多还挂着默认端口和弱口令。

修复不只是升级版本

Apache官方在5.13.1版本里加了强制序列化白名单，但升级不是万能药。老系统依赖旧版本客户端，贸然升级可能断掉消息通道。更实际的做法是分层处理：先把61616和8161端口从公网撤下来，用防火墙或安全组限制源IP；再改掉默认口令，控制台能关就关；如果业务允许，在JVM层面加-Djava.security.manager配合安全策略，或者用SerializationFilter做类过滤。这些措施叠加起来，比单纯追版本号靠谱得多。

还有个容易被忽略的点：ActiveMQ的fileserver组件也曾出过目录遍历漏洞，CVE-2016-3088。攻击者可以先上传webshell到文件服务器，再通过反序列化触发执行。两个漏洞串起来打，杀伤力翻倍。所以修ActiveMQ不能只盯着一个CVE，得把整个组件的攻击面都过一遍。

我的判断

ActiveMQ的漏洞史基本就是Java反序列化漏洞的缩影。从2015年到今天，类似的洞在WebLogic、JBoss、Jenkins上反复出现，根源都是同一个：把不可信数据丢进反序列化接口。厂商补丁出得不算慢，但企业侧的实际修复率低得可怜。很多团队觉得消息队列在内网就安全，这种假设在攻防对抗里早就破产了。内网横向移动的成本，比大多数人想象的低得多。

如果你手上还有ActiveMQ在跑，别只看版本号。去查一下61616端口谁在连，8161控制台能不能从办公网访问，日志里有没有异常的ObjectMessage。这些动作比等一个CVE公告实在。

(责任编辑：休闲)