tomcat 版本漏洞修复

Tomcat 版本漏洞修复这事儿，版本说穿了就是漏洞一场猫鼠游戏。你永远不知道下一个CVE编号会落在哪个组件上，修复但你知道，版本不补，漏洞迟早出事。修复

上个月我帮一个客户排查生产环境故障，版本发现他们的漏洞Tomcat还停在8.0.30。那版本老得都快进博物馆了。修复问运维为什么不动，版本答曰“业务稳定，漏洞不敢乱动”。修复结果呢？版本被扫描工具扫出CVE-2020-1938，也就是漏洞那个著名的Ghostcat漏洞。攻击者只需要发送一个精心构造的修复AJP请求，就能读取WEB-INF下的配置文件，甚至直接执行命令。客户当时脸都绿了——因为他们的管理后台密码，就明文躺在某个properties文件里。

修复Tomcat漏洞，第一步永远是搞清楚你跑的是什么版本。别信什么“我们用的最新版”这种鬼话。bin/version.sh或者直接看lib/catalina.jar的MANIFEST，两秒钟出结果。然后去Tomcat官网的漏洞列表页对照。这里有个坑：很多人以为只要升级到当前大版本的最新小版本就完事，但Apache官方只维护当前三个主要版本线。比如现在（2025年），9.0.x和10.1.x还在更新，10.0.x早就停止维护了。你要是还在10.0.27，那跟裸奔没区别。

升级本身倒不复杂。备份conf目录，替换整个apache-tomcat-xxx文件夹，启动，测试。真正让人头疼的是兼容性。我见过一个老项目，用的JSTL实现还是1.0时代的，升级到Tomcat 10后，包名从javax.servlet变成了jakarta.servlet，整个应用直接编译不过。你说这算谁的锅？Tomcat 10.1是个分水岭，Oracle把Java EE捐给Eclipse基金会后，命名空间全改了。如果你的应用是老古董，老老实实留在9.0.x，但记得打满补丁。

有些漏洞没法靠升级解决，只能靠配置加固。还是说Ghostcat，如果你不需要AJP协议，直接注释掉server.xml里那个，漏洞就废了。再比如CVE-2022-22965（Spring4Shell），虽然根子在Spring，但Tomcat的AccessLoggingValve如果配置不当会放大攻击面——把日志编码强制设成UTF-8，就能挡住一部分利用链。这些细节，官方安全公告里都写了，但没人看。

补丁管理建议自动化。别手动下载二进制包了，用脚本定期拉取最新版本，做差异对比。我自己习惯用Ansible写个playbook，每季度跑一次，自动替换并回滚。但自动化解决不了人的问题——你得有个清单，记录每个环境跑什么版本，谁负责升级，出事了找谁。小公司往往一个人管所有服务器，那就更要命。上次遇到一个兄弟，把生产环境的Tomcat直接换成了发行版自带的（比如Ubuntu的tomcat9包），结果版本跟官方严重脱节，漏洞修了跟没修一样。

最后说句实在话：Tomcat漏洞修复不是一次性动作，是持续折腾。每次CVE公告出来，先别急着动手，去GitHub上搜搜有没有公开的利用PoC，评估下自己的暴露面。如果Tomcat只监听内网，前面还有Nginx挡着，那风险等级可以降一档。但别心存侥幸——内网横向移动的案例还少吗？该升级就升级，该打补丁就打补丁。服务器不会因为版本旧就自动安全，但会因为你偷懒而被人拿下。