作者 akihi白帽攻防錄講師某甲方網(wǎng)絡(luò)安全工程師合合 SRC 年度第一、騰訊 SRC 連續(xù)三年前十單漏洞賞金 4w擅長(zhǎng) Web/App/PC 客戶端漏洞挖掘。專注中間件安全、反序列化漏洞、代碼審計(jì)。本文基于公開(kāi) CVE 信息與技術(shù)原理深度復(fù)盤供安全研究與防護(hù)參考。一、漏洞時(shí)間線2026 年 4 月Apache Tomcat 安全團(tuán)隊(duì)披露了一個(gè) Critical 級(jí)別的漏洞 CVE-2026-34486。這個(gè)漏洞非常特殊——它不是一個(gè)新發(fā)現(xiàn)的漏洞而是由之前修復(fù)另一個(gè)漏洞時(shí)引入的回歸缺陷。一行代碼的位置變化讓整個(gè)集群加密機(jī)制變成了 fail-open 的安全隱患。時(shí)間事件影響版本2026-03修復(fù) CVE-2026-29146padding oracle——2026-04-09NVD 發(fā)布 CVE-2026-34486 詳情10.1.x / 11.0.x2026-04-21安全團(tuán)隊(duì)發(fā)布技術(shù)分析——2026-04-28FreeBuf 發(fā)布中文分析——2026-08-04CISA 將其加入 KEV 已知被利用漏洞清單——2026-08-31安全廠商發(fā)布高優(yōu)先級(jí)預(yù)警——這個(gè)漏洞的 CVSS 評(píng)分為 9.8Critical攻擊復(fù)雜度低無(wú)需認(rèn)證無(wú)需用戶交互是典型的一鍵利用漏洞。CISA 在 8 月 4 日將其列入 KEV 清單確認(rèn)已被實(shí)際利用。二、攻擊鏈全景讓我們先用一張流程圖還原完整的攻擊路徑攻擊者發(fā)現(xiàn)暴露在公網(wǎng)的 Tomcat 集群節(jié)點(diǎn) │ ▼ 第一步發(fā)現(xiàn) Tribes 集群通信端口 │ Tomcat Tribes 默認(rèn)使用 TCP 4000 端口 │ 用于集群節(jié)點(diǎn)之間的消息同步 │ 正常情況下消息應(yīng)該加密 ▼ 第二步分析加密機(jī)制 │ Tomcat 使用 EncryptInterceptor 加密集群消息 │ 正常流程加密消息 → 傳輸 → 解密 → 處理 │ 漏洞版本解密失敗 → 消息仍然繼續(xù)處理 ▼ 第三步構(gòu)造惡意序列化消息 │ 攻擊者不需要加密 │ 直接發(fā)送惡意 Java 序列化對(duì)象 │ 內(nèi)容是精心構(gòu)造的反序列化 payload ▼ 第四步發(fā)送到 TCP 4000 端口 │ 原始字節(jié)流直接發(fā)送到 NioReceiver │ EncryptInterceptor 嘗試解密 │ 解密失敗拋出 GeneralSecurityException ▼ 第五步fail-open 發(fā)生 │ catch 塊記錄了錯(cuò)誤日志 │ 但是super.messageReceived(msg) 在 try 塊外面 │ 消息沒(méi)有被丟棄而是繼續(xù)傳遞下去 ▼ 第六步到達(dá)反序列化層 │ 原始的惡意字節(jié)流進(jìn)入 Tribes 消息處理 │ Java 反序列化執(zhí)行 │ payload 中的惡意代碼被執(zhí)行 ▼ 攻擊者獲得遠(yuǎn)程代碼執(zhí)行權(quán)限 │ ├─ 在 Tomcat 服務(wù)器上執(zhí)行任意命令 ├─ 讀取/修改服務(wù)器上的文件 ├─ 橫向移動(dòng)到內(nèi)網(wǎng)其他節(jié)點(diǎn) └─ 完全控制整個(gè)集群關(guān)鍵結(jié)論這個(gè)漏洞的核心是一行代碼的位置——super.messageReceived(msg)從 try 塊里面移到了外面。從編譯器的角度看代碼完全正確但從安全的角度看這就是從 fail-close 變成了 fail-open。解密失敗不再丟棄消息而是讓原始字節(jié)流直接通過(guò)。三、Tomcat Tribes 原理3.1 什么是 Tomcat TribesApache Tomcat Tribes 是 Tomcat 的集群通信組件用于在多個(gè) Tomcat 節(jié)點(diǎn)之間同步會(huì)話、配置和消息組件作用NioReceiver監(jiān)聽(tīng) TCP 端口默認(rèn) 4000接收集群消息EncryptInterceptor加密/解密集群消息防止竊聽(tīng)和篡改DispatchChannel消息分發(fā)通道將消息分發(fā)給各個(gè)攔截器Deserialization將接收到的字節(jié)流反序列化為 Java 對(duì)象3.2 正常的加密流程正常情況下集群消息的處理流程發(fā)送端用密鑰加密消息內(nèi)容網(wǎng)絡(luò)傳輸消息是密文即使被竊聽(tīng)也無(wú)法解讀接收端EncryptInterceptor 嘗試解密解密成功消息繼續(xù)傳遞給下一個(gè)攔截器解密失敗丟棄消息記錄錯(cuò)誤日志反序列化只有解密成功的消息才會(huì)被反序列化3.3 為什么需要加密集群通信消息中包含敏感信息// 集群消息中可能包含的數(shù)據(jù) // - 用戶會(huì)話數(shù)據(jù)Session // - 配置信息 // - 應(yīng)用狀態(tài) // - 節(jié)點(diǎn)之間的認(rèn)證憑證 // 如果不加密 // 1. 攻擊者可以竊聽(tīng)集群通信 // 2. 攻擊者可以偽造集群消息 // 3. 攻擊者可以直接發(fā)送惡意序列化對(duì)象 // 4. 導(dǎo)致遠(yuǎn)程代碼執(zhí)行四、漏洞深度分析4.1 漏洞根因一行代碼的位置根據(jù)安全團(tuán)隊(duì)的分析漏洞的根本原因是修復(fù) CVE-2026-29146 時(shí)引入的回歸// 修復(fù)前正確的代碼 Override public void messageReceived(ChannelMessage msg) { try { // 嘗試解密消息 byte[] decrypted decrypt(msg.getMessage()); msg.getMessage().transferFrom(decrypted); // 只有解密成功才繼續(xù)處理 super.messageReceived(msg); } catch (GeneralSecurityException gse) { // 解密失敗丟棄消息 log.error(Failed to decrypt message, gse); // 消息被丟棄不繼續(xù)處理 } } // 漏洞版本錯(cuò)誤的代碼 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 外面 // 無(wú)論解密成功還是失敗都會(huì)執(zhí)行 super.messageReceived(msg); } // 區(qū)別只有一個(gè) // super.messageReceived(msg) 從 try 塊里面移到了外面 // 從編譯器看代碼完全正確 // 但從安全看這就是 fail-open4.2 為什么會(huì)引入這個(gè)回歸這個(gè)回歸是在修復(fù)另一個(gè)漏洞 CVE-2026-29146 時(shí)引入的漏洞問(wèn)題修復(fù)方式CVE-2026-29146CBC 模式存在 padding oracle改進(jìn)解密邏輯CVE-2026-34486修復(fù)時(shí)把 super.messageReceived 移到了外面把這行代碼移回 try 塊里面這是一個(gè)典型的修復(fù)引入新漏洞的案例。開(kāi)發(fā)者本意是好的——修復(fù) padding oracle 漏洞但在修改代碼時(shí)不小心改變了控制流導(dǎo)致了更嚴(yán)重的安全問(wèn)題。4.3 攻擊利用示例攻擊者如何利用這個(gè)漏洞執(zhí)行代碼// 攻擊步驟 // 1. 攻擊者發(fā)現(xiàn) Tomcat 集群的 TCP 4000 端口 nmap -sV target.com -p 4000 // 2. 構(gòu)造惡意 Java 序列化 payload // 比如使用 CommonsCollections 鏈 ObjectOutputStream oos new ObjectOutputStream(socket.getOutputStream()); oos.writeObject(evilPayload); // 3. 直接發(fā)送原始字節(jié)流 // 不需要加密EncryptInterceptor 會(huì)嘗試解密 // 解密失敗但消息仍然繼續(xù)處理 Socket s new Socket(target.com, 4000); OutputStream os s.getOutputStream(); os.write(serializedPayload); os.flush(); // 4. Tomcat 接收到消息 // EncryptInterceptor.messageReceived() 被調(diào)用 // decrypt() 拋出 GeneralSecurityException // catch 塊記錄錯(cuò)誤 // super.messageReceived(msg) 仍然執(zhí)行 // 消息到達(dá)反序列化層 // 惡意代碼執(zhí)行 // 實(shí)際影響 // - 遠(yuǎn)程代碼執(zhí)行RCE // - 讀取服務(wù)器文件 // - 修改應(yīng)用配置 // - 橫向移動(dòng)4.4 影響范圍產(chǎn)品影響版本影響程度Apache Tomcat 10.1.x所有啟用集群加密的版本未授權(quán) RCEApache Tomcat 11.0.x所有啟用集群加密的版本未授權(quán) RCE利用端口TCP 4000Tribes 集群通信——利用條件啟用了集群和加密攔截器——CISA KEV2026-08-04 列入確認(rèn)被利用五、修復(fù)方案分析Apache Tomcat 在后續(xù)版本中修復(fù)了這個(gè)問(wèn)題修復(fù)項(xiàng)修復(fù)方式代碼位置把 super.messageReceived(msg) 移回 try 塊里面異常處理解密失敗時(shí)丟棄消息不繼續(xù)處理安全默認(rèn)fail-close失敗時(shí)拒絕而不是放行5.1 安全編碼原則// 安全編碼的 fail-close 原則 // 不好的做法fail-open try { decrypt(data); } catch (Exception e) { log.error(decrypt failed, e); } // 即使失敗也繼續(xù)處理 process(data); // 好的做法fail-close try { decrypt(data); process(data); // 只有成功才處理 } catch (Exception e) { log.error(decrypt failed, dropping message, e); // 失敗時(shí)丟棄消息不繼續(xù)處理 return; } // 原則 // 安全相關(guān)的操作失敗時(shí)應(yīng)該拒絕 // 而不是放行 // 這就是 fail-close vs fail-open5.2 Tomcat 加固措施// Tomcat 安全加固 // 1. 及時(shí)更新 // 升級(jí)到修復(fù)了 CVE-2026-34486 的版本 // 2. 限制集群端口訪問(wèn) // 不要讓 TCP 4000 暴露在公網(wǎng) // 只允許集群節(jié)點(diǎn)之間通信 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. 監(jiān)控異常流量 // 監(jiān)控 TCP 4000 端口的連接 // 特別是來(lái)自公網(wǎng)的連接 // 5. 網(wǎng)絡(luò)分段 // 集群通信放在內(nèi)網(wǎng) // 不要和公網(wǎng)直接通信六、SRC 審計(jì)啟示錄6.1 中間件安全審計(jì)清單在 SRC 挖洞過(guò)程中針對(duì)中間件的審計(jì)清單#檢查項(xiàng)檢測(cè)方法1是否有暴露的管理端口nmap 掃描常見(jiàn)端口2集群端口是否暴露公網(wǎng)檢查 4000、8009 等端口3是否啟用了不安全的反序列化發(fā)送序列化測(cè)試 payload4加密機(jī)制是否正確實(shí)現(xiàn)檢查 fail-open / fail-close5是否有已知 CVE 未修復(fù)對(duì)比版本號(hào)和 CVE 列表6.2 常見(jiàn)中間件漏洞// 常見(jiàn)中間件漏洞 // 1. 反序列化漏洞 // WebLogic、WebSphere、JBoss、Tomcat // 發(fā)送惡意序列化對(duì)象執(zhí)行代碼 // 2. 管理接口未授權(quán) // Tomcat Manager、JMX Console // 未授權(quán)訪問(wèn)部署 WAR 包 // 3. 集群通信漏洞 // 就是本次漏洞的類型 // 集群消息沒(méi)有正確驗(yàn)證 // 4. 信息泄露 // 錯(cuò)誤頁(yè)面泄露版本信息 // 幫助攻擊者精確匹配 CVE6.3 fail-open vs fail-close場(chǎng)景fail-open 風(fēng)險(xiǎn)fail-close 正確做法解密失敗原始數(shù)據(jù)直接通過(guò)丟棄消息拒絕處理認(rèn)證失敗允許訪問(wèn)返回 403權(quán)限檢查異常默認(rèn)允許默認(rèn)拒絕輸入驗(yàn)證異常接受輸入拒絕輸入七、防護(hù)建議及時(shí)更新升級(jí)到修復(fù)了 CVE-2026-34486 的 Tomcat 版本端口限制TCP 4000 集群端口不要暴露公網(wǎng)只允許內(nèi)網(wǎng)訪問(wèn)最小化服務(wù)不需要集群功能就不要啟用監(jiān)控告警監(jiān)控集群端口的異常連接和流量網(wǎng)絡(luò)分段集群通信放在安全內(nèi)網(wǎng)段漏洞掃描定期掃描服務(wù)器上的中間件版本和已知漏洞八、總結(jié)CVE-2026-34486 是一個(gè)非常有教育意義的漏洞——它告訴我們安全是關(guān)于控制流的。一行代碼的位置變化就可能從 fail-close 變成 fail-open從安全變成不安全。在 SRC 挖洞實(shí)踐中補(bǔ)丁回歸是一個(gè)高價(jià)值的審計(jì)方向看看最近修復(fù)的漏洞修復(fù)代碼是否引入了新的問(wèn)題特別是異常處理、控制流這些細(xì)節(jié)往往藏著最嚴(yán)重的安全隱患。