Apache Tomcat又爆出代码执行漏洞了。代码这次是问题CVE-2024-50379，影响范围覆盖9.0.x到11.0.x的漏洞多个版本。攻击者只要能在目标服务器上写入一个JSP文件，代码就能借Tomcat的问题JSP编译机制触发任意代码执行。说直白点，漏洞拿到一个文件上传权限，代码基本就等于拿到了服务器的问题root权限。

漏洞的漏洞根源出在Tomcat对JSP文件修改时间的校验逻辑上。默认配置下，代码Tomcat为了性能会缓存已编译的问题JSP，只有当文件时间戳发生变化时才重新编译。漏洞问题在于，代码这个时间戳比对存在一个微小的问题竞态窗口——攻击者可以利用文件系统的精度差异，让Tomcat误判文件未被修改，漏洞从而绕过检查，加载一个已经被篡改的恶意JSP。

这个漏洞最恶心的地方在于利用门槛极低。不需要什么高深技巧，只要目标应用存在任意文件上传功能，并且上传目录能被Tomcat的JSP解析器访问到，就能稳稳打穿。现实中很多Java Web应用都有文件上传功能，比如头像上传、附件上传、导入导出功能，这些地方稍不注意就会成为突破口。

我见过不少团队在修复这类问题时的错误姿势。有人直接把JSP编译缓存给禁了，结果性能断崖式下跌，生产环境直接报警。有人改了上传目录的权限，结果业务功能又挂了。实际上官方给出的修复方案很明确：升级到9.0.98、10.1.35或11.0.3及以上版本。如果暂时没法升级，那就需要把默认的org.apache.jasper.servlet.JspServlet配置里加上checkInterval参数，并且将development设为false，同时确保文件系统支持精确的时间戳比对。

更值得警惕的是，这已经不是Tomcat第一次在JSP机制上栽跟头了。2020年的CVE-2020-1938（Ghostcat）也是通过AJP协议绕过权限控制，直接读取或执行JSP文件。两次漏洞都指向同一个核心问题：Tomcat在处理JSP文件时的信任边界过于宽松。它默认信任文件系统提供的时间戳信息，默认信任上传文件不会被恶意篡改，默认信任JSP文件内容是可执行的——这些默认信任在真实攻击面前都成了致命弱点。

对于运维和开发人员来说，与其每次等漏洞爆出来再打补丁，不如从架构层面反思一下：为什么业务里需要允许用户上传JSP文件？绝大多数场景根本不需要。如果确实有需求，也应该把上传目录和JSP执行目录彻底隔离，比如上传到独立的静态文件服务器，或者放在Tomcat的webapps之外，用独立的Servlet处理下载请求。

安全圈有句老话：漏洞不可怕，可怕的是不知道自己暴露在漏洞里。Tomcat作为全球部署量最大的Java应用服务器之一，每次出洞都是大范围地震。但现实是，很多企业内部还在跑着老掉牙的Tomcat 8.5甚至7.0版本，这些版本已经停止维护，新漏洞永远不会有补丁。与其指望运气，不如趁早做一次全面的中间件盘点，把那些EOL（停止维护）的组件统统换掉。

这次漏洞的披露时间也很有意思，正好赶在年底很多团队做安全审计的档口。估计未来几周，会有不少公司发现自己中招。如果你还没检查自家Tomcat版本，现在就该去翻一下catalina.properties或者运行version.sh看看版本号。别等到被入侵了才想起来补丁这回事——到那时候，损失的可不止是几台服务器。