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