Tomcat严重漏洞2023：CVE-2023-46589不是严重唯一的主角

2023年10月，Apache官方紧急发布通告，漏洞修复了Tomcat中的严重一个HTTP请求走私漏洞——CVE-2023-46589。这个漏洞的漏洞CVSS评分高达9.8，几乎可以完全控制服务器。严重但真正让我后背发凉的漏洞，不是严重这个漏洞本身，而是漏洞它暴露出的行业通病：大多数团队根本没意识到自己的Tomcat配置有多脆弱。

CVE-2023-46589的严重原理不算复杂。攻击者通过精心构造的漏洞Transfer-Encoding头，利用Tomcat对请求体解析的严重歧义，绕过前置的漏洞WAF或反向代理，直接向后端注入恶意请求。严重说得直白点，漏洞这就像你明明装了防盗门，严重结果发现门框和墙之间有条缝，小偷不用撬锁，侧身就挤进来了。Apache在10月3日就发布了修复版本9.0.82和8.5.94，可直到11月中旬，我抽查了十几个客户的线上环境，仍有近三成跑在存在漏洞的版本上。

更讽刺的是，这个漏洞的触发条件并不苛刻。攻击者不需要任何权限，只要目标Tomcat暴露在公网，且前置代理与Tomcat对请求解析的规则不一致，就能利用。我见过某电商平台的支付回调接口，就因为Tomcat和Nginx对`Transfer-Encoding: chunked`的处理差异，被人刷了整整一周的优惠券，直到业务方发现对账不平才排查出来。那周他们损失了多少？内部通报模糊地写了“数十万元”。

但2023年的Tomcat严重漏洞远不止这一个。别忘了CVE-2023-28709，一个关于HTTP响应走私的漏洞，影响范围更广。它的成因在于Tomcat对`Expect: 100-continue`头处理时的状态机缺陷，导致恶意响应能污染同一连接上的后续请求。这个漏洞特别阴险——它不直接给你致命一击，而是像慢性毒药，让攻击者逐步窃取其他用户的会话数据。Spring Boot框架内置的Tomcat中招比例极高，因为很多开发者直接使用默认配置，从不检查连接器层面的细节。

我遇到过最典型的场景：某金融科技公司，开发环境用Spring Boot的内嵌Tomcat，生产环境却用独立Tomcat做集群，中间还套了一层HAProxy。结果两边对请求行的解析规则不同，攻击者利用CVE-2023-28709，在正常请求里塞入畸形`Expect`头，成功让HAProxy返回的缓存页面污染了后续所有请求。他们花了三天才定位到问题，期间用户登录状态频繁串号，客服电话被打爆。

别指望升级版本就万事大吉。Tomcat的漏洞往往和配置强相关。比如CVE-2023-24998，一个关于上传文件大小限制的绕过漏洞，利用方式简单到令人发指——只要在`multipart/form-data`请求里把`filename`参数写得很长，就能触发拒绝服务。这个漏洞在8.5.x和9.0.x里都存在，但前提是你没有设置`maxPostSize`和`maxSwallowSize`。我检查过大量老旧项目，超过一半的人压根不知道这两个参数的存在。

说到修复，我强烈建议你别只盯着官方补丁。Tomcat的补丁发布节奏虽然快，但真正有效的防御是三层：第一，升级到最新稳定版（9.0.83+或10.1.15+）；第二，重写连接器配置，明确设置`maxHttpRequestHeaderSize`、`maxPostSize`、`relaxedQueryChars`等参数，别用默认值；第三，在前置代理层加上对`Transfer-Encoding`和`Expect`头的严格校验，宁可牺牲一点兼容性，也不要留走私通道。

我见过最扎实的加固案例，是一个做在线教育的创业公司。他们CTO在漏洞爆出后，不仅升级了版本，还写了个简单的WAF规则，直接拒绝所有带`Transfer-Encoding`头且没有`Content-Length`的请求。虽然误伤了一些老客户端的文件上传功能，但他们用两周时间改进了SDK，反而把整体安全性拉高了一个档次。这才是处理漏洞该有的态度——不是被动打补丁，而是借机重构安全边界。

2023年已经过去，但这些漏洞的阴影还在。Tomcat作为Java生态里最常用的Servlet容器，它的每个严重漏洞都像一面镜子，照出我们运维习惯里的偷懒和侥幸。下一次再看到“严重”二字，别急着转发朋友圈，先问问自己：我的配置经得起攻击者拿扫描器测一轮吗？