作者 akihi白帽攻防录讲师某甲方网络安全工程师合合 SRC 年度第一、腾讯 SRC 连续三年前十单漏洞赏金 4w擅长 Web/App/PC 客户端漏洞挖掘。专注中间件安全、反序列化漏洞、代码审计。本文基于公开 CVE 信息与技术原理深度复盘供安全研究与防护参考。一、漏洞时间线2026 年 4 月Apache Tomcat 安全团队披露了一个 Critical 级别的漏洞 CVE-2026-34486。这个漏洞非常特殊——它不是一个新发现的漏洞而是由之前修复另一个漏洞时引入的回归缺陷。一行代码的位置变化让整个集群加密机制变成了 fail-open 的安全隐患。时间事件影响版本2026-03修复 CVE-2026-29146padding oracle——2026-04-09NVD 发布 CVE-2026-34486 详情10.1.x / 11.0.x2026-04-21安全团队发布技术分析——2026-04-28FreeBuf 发布中文分析——2026-08-04CISA 将其加入 KEV 已知被利用漏洞清单——2026-08-31安全厂商发布高优先级预警——这个漏洞的 CVSS 评分为 9.8Critical攻击复杂度低无需认证无需用户交互是典型的一键利用漏洞。CISA 在 8 月 4 日将其列入 KEV 清单确认已被实际利用。二、攻击链全景让我们先用一张流程图还原完整的攻击路径攻击者发现暴露在公网的 Tomcat 集群节点 │ ▼ 第一步发现 Tribes 集群通信端口 │ Tomcat Tribes 默认使用 TCP 4000 端口 │ 用于集群节点之间的消息同步 │ 正常情况下消息应该加密 ▼ 第二步分析加密机制 │ Tomcat 使用 EncryptInterceptor 加密集群消息 │ 正常流程加密消息 → 传输 → 解密 → 处理 │ 漏洞版本解密失败 → 消息仍然继续处理 ▼ 第三步构造恶意序列化消息 │ 攻击者不需要加密 │ 直接发送恶意 Java 序列化对象 │ 内容是精心构造的反序列化 payload ▼ 第四步发送到 TCP 4000 端口 │ 原始字节流直接发送到 NioReceiver │ EncryptInterceptor 尝试解密 │ 解密失败抛出 GeneralSecurityException ▼ 第五步fail-open 发生 │ catch 块记录了错误日志 │ 但是super.messageReceived(msg) 在 try 块外面 │ 消息没有被丢弃而是继续传递下去 ▼ 第六步到达反序列化层 │ 原始的恶意字节流进入 Tribes 消息处理 │ Java 反序列化执行 │ payload 中的恶意代码被执行 ▼ 攻击者获得远程代码执行权限 │ ├─ 在 Tomcat 服务器上执行任意命令 ├─ 读取/修改服务器上的文件 ├─ 横向移动到内网其他节点 └─ 完全控制整个集群关键结论这个漏洞的核心是一行代码的位置——super.messageReceived(msg)从 try 块里面移到了外面。从编译器的角度看代码完全正确但从安全的角度看这就是从 fail-close 变成了 fail-open。解密失败不再丢弃消息而是让原始字节流直接通过。三、Tomcat Tribes 原理3.1 什么是 Tomcat TribesApache Tomcat Tribes 是 Tomcat 的集群通信组件用于在多个 Tomcat 节点之间同步会话、配置和消息组件作用NioReceiver监听 TCP 端口默认 4000接收集群消息EncryptInterceptor加密/解密集群消息防止窃听和篡改DispatchChannel消息分发通道将消息分发给各个拦截器Deserialization将接收到的字节流反序列化为 Java 对象3.2 正常的加密流程正常情况下集群消息的处理流程发送端用密钥加密消息内容网络传输消息是密文即使被窃听也无法解读接收端EncryptInterceptor 尝试解密解密成功消息继续传递给下一个拦截器解密失败丢弃消息记录错误日志反序列化只有解密成功的消息才会被反序列化3.3 为什么需要加密集群通信消息中包含敏感信息// 集群消息中可能包含的数据 // - 用户会话数据Session // - 配置信息 // - 应用状态 // - 节点之间的认证凭证 // 如果不加密 // 1. 攻击者可以窃听集群通信 // 2. 攻击者可以伪造集群消息 // 3. 攻击者可以直接发送恶意序列化对象 // 4. 导致远程代码执行四、漏洞深度分析4.1 漏洞根因一行代码的位置根据安全团队的分析漏洞的根本原因是修复 CVE-2026-29146 时引入的回归// 修复前正确的代码 Override public void messageReceived(ChannelMessage msg) { try { // 尝试解密消息 byte[] decrypted decrypt(msg.getMessage()); msg.getMessage().transferFrom(decrypted); // 只有解密成功才继续处理 super.messageReceived(msg); } catch (GeneralSecurityException gse) { // 解密失败丢弃消息 log.error(Failed to decrypt message, gse); // 消息被丢弃不继续处理 } } // 漏洞版本错误的代码 Override public void messageReceived(ChannelMessage msg) { try { // 尝试解密消息 byte[] decrypted decrypt(msg.getMessage()); msg.getMessage().transferFrom(decrypted); } catch (GeneralSecurityException gse) { // 解密失败只记录日志 log.error(Failed to decrypt message, gse); // 注意super.messageReceived 不在 try 块里面了 } // 这行代码被移到了 try-catch 外面 // 无论解密成功还是失败都会执行 super.messageReceived(msg); } // 区别只有一个 // super.messageReceived(msg) 从 try 块里面移到了外面 // 从编译器看代码完全正确 // 但从安全看这就是 fail-open4.2 为什么会引入这个回归这个回归是在修复另一个漏洞 CVE-2026-29146 时引入的漏洞问题修复方式CVE-2026-29146CBC 模式存在 padding oracle改进解密逻辑CVE-2026-34486修复时把 super.messageReceived 移到了外面把这行代码移回 try 块里面这是一个典型的修复引入新漏洞的案例。开发者本意是好的——修复 padding oracle 漏洞但在修改代码时不小心改变了控制流导致了更严重的安全问题。4.3 攻击利用示例攻击者如何利用这个漏洞执行代码// 攻击步骤 // 1. 攻击者发现 Tomcat 集群的 TCP 4000 端口 nmap -sV target.com -p 4000 // 2. 构造恶意 Java 序列化 payload // 比如使用 CommonsCollections 链 ObjectOutputStream oos new ObjectOutputStream(socket.getOutputStream()); oos.writeObject(evilPayload); // 3. 直接发送原始字节流 // 不需要加密EncryptInterceptor 会尝试解密 // 解密失败但消息仍然继续处理 Socket s new Socket(target.com, 4000); OutputStream os s.getOutputStream(); os.write(serializedPayload); os.flush(); // 4. Tomcat 接收到消息 // EncryptInterceptor.messageReceived() 被调用 // decrypt() 抛出 GeneralSecurityException // catch 块记录错误 // super.messageReceived(msg) 仍然执行 // 消息到达反序列化层 // 恶意代码执行 // 实际影响 // - 远程代码执行RCE // - 读取服务器文件 // - 修改应用配置 // - 横向移动4.4 影响范围产品影响版本影响程度Apache Tomcat 10.1.x所有启用集群加密的版本未授权 RCEApache Tomcat 11.0.x所有启用集群加密的版本未授权 RCE利用端口TCP 4000Tribes 集群通信——利用条件启用了集群和加密拦截器——CISA KEV2026-08-04 列入确认被利用五、修复方案分析Apache Tomcat 在后续版本中修复了这个问题修复项修复方式代码位置把 super.messageReceived(msg) 移回 try 块里面异常处理解密失败时丢弃消息不继续处理安全默认fail-close失败时拒绝而不是放行5.1 安全编码原则// 安全编码的 fail-close 原则 // 不好的做法fail-open try { decrypt(data); } catch (Exception e) { log.error(decrypt failed, e); } // 即使失败也继续处理 process(data); // 好的做法fail-close try { decrypt(data); process(data); // 只有成功才处理 } catch (Exception e) { log.error(decrypt failed, dropping message, e); // 失败时丢弃消息不继续处理 return; } // 原则 // 安全相关的操作失败时应该拒绝 // 而不是放行 // 这就是 fail-close vs fail-open5.2 Tomcat 加固措施// Tomcat 安全加固 // 1. 及时更新 // 升级到修复了 CVE-2026-34486 的版本 // 2. 限制集群端口访问 // 不要让 TCP 4000 暴露在公网 // 只允许集群节点之间通信 iptables -A INPUT -p tcp --dport 4000 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 4000 -j DROP // 3. 禁用不必要的集群功能 // 如果不需要集群就不要启用 // 4. 监控异常流量 // 监控 TCP 4000 端口的连接 // 特别是来自公网的连接 // 5. 网络分段 // 集群通信放在内网 // 不要和公网直接通信六、SRC 审计启示录6.1 中间件安全审计清单在 SRC 挖洞过程中针对中间件的审计清单#检查项检测方法1是否有暴露的管理端口nmap 扫描常见端口2集群端口是否暴露公网检查 4000、8009 等端口3是否启用了不安全的反序列化发送序列化测试 payload4加密机制是否正确实现检查 fail-open / fail-close5是否有已知 CVE 未修复对比版本号和 CVE 列表6.2 常见中间件漏洞// 常见中间件漏洞 // 1. 反序列化漏洞 // WebLogic、WebSphere、JBoss、Tomcat // 发送恶意序列化对象执行代码 // 2. 管理接口未授权 // Tomcat Manager、JMX Console // 未授权访问部署 WAR 包 // 3. 集群通信漏洞 // 就是本次漏洞的类型 // 集群消息没有正确验证 // 4. 信息泄露 // 错误页面泄露版本信息 // 帮助攻击者精确匹配 CVE6.3 fail-open vs fail-close场景fail-open 风险fail-close 正确做法解密失败原始数据直接通过丢弃消息拒绝处理认证失败允许访问返回 403权限检查异常默认允许默认拒绝输入验证异常接受输入拒绝输入七、防护建议及时更新升级到修复了 CVE-2026-34486 的 Tomcat 版本端口限制TCP 4000 集群端口不要暴露公网只允许内网访问最小化服务不需要集群功能就不要启用监控告警监控集群端口的异常连接和流量网络分段集群通信放在安全内网段漏洞扫描定期扫描服务器上的中间件版本和已知漏洞八、总结CVE-2026-34486 是一个非常有教育意义的漏洞——它告诉我们安全是关于控制流的。一行代码的位置变化就可能从 fail-close 变成 fail-open从安全变成不安全。在 SRC 挖洞实践中补丁回归是一个高价值的审计方向看看最近修复的漏洞修复代码是否引入了新的问题特别是异常处理、控制流这些细节往往藏着最严重的安全隐患。