文章总结： 本文深度分析ApacheTomcat高危漏洞CVE-2026-34486，其因修复CVE-2026-29146时一行代码调整导致EncryptInterceptor从fail-closed变为fail-open，使攻击者通过TCP4000端口发送未加密反序列化payload即可实现未授权RCE。影响Tomcat11.0.20/10.1.53/9.0.116版本，尤其威胁Kubernetes环境。文章提供漏洞复现步骤与官方PoC链接，建议及时升级至安全版本并加强网络隔离。 综合评分： 87 文章分类： 漏洞分析,WEB安全,应用安全,漏洞预警,红队
CVE-2026-34486 深度分析：一行代码引发的 RCE
陈默 陈默
默识信安
2026年5月15日 08:52 云南
在小说阅读器读本章
去阅读
免责声明
本文仅用于安全研究、学习和合法授权的环境测试。任何未经授权的网络攻击行为均违反法律法规，作者及公众号不承担任何法律责任。请严格遵守相关法律法规，仅在自有测试环境或获得明确书面授权后进行操作。
序
最近 Apache Tomcat 出了一个很有代表性的高危漏洞，编号 CVE-2026-34486（CVSS 7.5）。这个漏洞的戏剧性在于，它源于官方修复另一个加密问题时引入的回归。一行代码位置的调整，把原本应该严格保护集群通信的 EncryptInterceptor，从 fail-closed（失败关闭）变成了 fail-open（失败开放）。攻击者只要能 TCP 访问到 Tribes 默认的 4000 端口，就能直接发送未加密的反序列化 payload，实现未授权远程代码执行。
Striga.ai 的研究团队在安全评估中发现了这个问题，构造了完整利用链，并报告给了 Apache 官方。这个漏洞特别值得生产环境关注，因为很多团队配置 EncryptInterceptor 的初衷正是为了保护集群流量，结果却成了最大破绽。
Tomcat Tribes 和 EncryptInterceptor
Apache Tomcat 作为最常用的 Java Servlet 容器，很多企业都在用它来承载 Web 应用。当业务需要高可用时，通常会部署多个 Tomcat 节点组成集群。这时就需要一个组件来处理节点之间的通信和状态同步，这个组件就是 Tribes。
Tribes 负责成员发现、消息可靠传输以及会话复制等工作。它默认通过 TCP 4000 端口监听，绑定在所有网络接口上，消息格式包括 FLT2002 开头标识、ChannelData 实际内容和 TLF2003 结尾标识。默认情况下，这个通信通道没有强身份认证，主要依赖网络层隔离来保障安全。
EncryptInterceptor 则是 Tribes 拦截器链里负责加密的部分。它可以对节点间传输的数据进行 AES 加密（支持 GCM 等安全模式）。正常设计里，接收消息时必须先成功解密，才能继续后续处理；如果解密失败，应该直接丢弃消息，这就是典型的 fail-closed 机制。
漏洞根因：一行代码引发的回归
事情要从 CVE-2026-29146 说起。当时研究人员发现 EncryptInterceptor 在默认 CBC 模式下存在 padding oracle 攻击风险。官方在 2026 年 3 月 13 日提交修复时，对加密逻辑做了重构，同时调整了 EncryptInterceptor.java 中的 messageReceived 方法。
在早期安全版本中，解密逻辑包裹在 try 块里，只有解密成功才会调用 super.messageReceived(msg) 继续处理。一旦出现 GeneralSecurityException，就会记录错误日志并直接返回，消息被丢弃。代码大致是这样的：
public void messageReceived(ChannelMessage msg) {
try {
byte[] data = msg.getMessage().getBytes();
data = encryptionManager.decrypt(data);
XByteBuffer xbb = msg.getMessage();
xbb.clear();
xbb.append(data, 0, data.length);
super.messageReceived(msg); // 仅解密成功才继续
} catch (GeneralSecurityException gse) {
log.error(sm.getString("encryptInterceptor.decrypt.failed"), gse);
}
}
但在受影响版本里，super.messageReceived(msg) 被移到了 try-catch 外面。
解密失败时（攻击者发送未加密消息会触发 AEADBadTagException 或 BadPaddingException），日志只记录一条 SEVERE 错误，原始 attacker-controlled payload 却被原样传递，最终触发反序列化 RCE。Send 路径仍然是 fail-closed，而 Receive 路径变成了 fail-open，这种不对称是无意中引入的。
public void messageReceived(ChannelMessage msg) {
try {
byte[] data = msg.getMessage().getBytes();
data = encryptionManager.decrypt(data);
XByteBuffer xbb = msg.getMessage();
xbb.clear();
xbb.append(data, 0, data.length);
} catch (GeneralSecurityException gse) {
log.error(sm.getString("encryptInterceptor.decrypt.failed"), gse);
}
super.messageReceived(msg); // 无条件继续
}
漏洞影响范围
受影响的精确版本为：Apache Tomcat 11.0.20、10.1.53、9.0.116。Tomcat 8.5.x 不受影响。
只需要网络可达 4000 端口 + 服务器 classpath 中存在 gadget 库（例如 Commons Collections 3.x）。在 Kubernetes 环境中，如果没有 NetworkPolicy 隔离，同 Namespace 的任意 Pod 都能轻松访问其他 Pod 的 4000 端口，风险极大。攻击成功后可实现命令执行，隐蔽性高，仅留下一条解密失败日志。
复现过程
推荐直接使用 Striga.ai 官方 PoC 仓库：https://github.com/striga-ai/CVE-2026-34486
git clone https://github.com/striga-ai/CVE-2026-34486.git
cd CVE-2026-34486
bash run.sh
脚本会自动构建 Tomcat 11.0.20 环境、配置 EncryptInterceptor、生成 CC6 gadget（执行 touch /tmp/pwned），并发送构造好的 Tribes 协议包。同时容器内会出现 /tmp/pwned 文件，证明 RCE 已执行。
server.xml 配置示例（关键部分）：
<Interceptor className="org.apache.catalina.tribes.group.interceptors.EncryptInterceptor"
encryptionKey="your-secret-key-here"
algorithm="AES/GCM/NoPadding" />
攻击无需成为合法集群成员，协议构造简单（头部 + ChannelData（伪造 Member） + payload + 尾部）。
时间线梳理
- 2026 年 2 月：CVE-2026-29146 被报告
- 3 月 13 日：官方提交 padding oracle 修复，同时引入本次回归
- 3 月下旬：受影响版本陆续发布
- 3 月 25 日左右：Striga.ai 研究人员在评估中发现问题并报告
- 4 月 4 日：安全版本正式发布
- 4 月 9 日：CVE-2026-34486 公开，PoC 开始出现
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：默识信安 陈默 陈默《CVE-2026-34486 深度分析：一行代码引发的 RCE》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论