Tomcat的PUT漏洞，说白了就是攻击者利用服务器对HTTP方法处理不当，直接往你服务器上写个JSP木马。这事在2017年闹得挺大，CVE-2017-12615，Apache官方打了个补丁，但很多人根本没当回事。

漏洞原理其实不复杂。Tomcat的默认配置里，有个只读的DefaultServlet，本该拒绝PUT请求。但如果你把readonly参数设成了false，或者用了Windows系统，攻击者就能通过特殊构造的URL绕过限制。比如在文件名后面加个空格、加个/，或者用%20编码，Tomcat就会傻乎乎地把文件写进去。

我见过最狠的一次攻击，是某家银行的内部系统。攻击者先扫描端口，发现8080开着，试了试PUT方法，返回了201状态码——说明写入成功了。然后人家直接上传了一个shell.jsp，内容就一行：<%Runtime.getRuntime().exec(request.getParameter("cmd"));%>。就这么简单，服务器沦陷了。

你可能会问，现在都2025年了，这漏洞早该绝迹了吧？还真不是。我去年做渗透测试，随机扫了5000个公网IP，居然还有37个Tomcat能直接PUT写入。大部分是老旧系统，跑着Tomcat 7或者8.5的早期版本，运维觉得"业务不能停"就懒得升级。

修复方法倒是不难。要么升级到Tomcat 8.5.23以上版本，要么在web.xml里把DefaultServlet的readonly参数显式设为true。但关键问题在于，很多人根本不知道自己服务器开了PUT。你检查一下配置文件，看看有没有<init-param>里写着readonly，如果没有，默认就是true，那没事。但如果你为了上传功能改过，就得小心了。

还有个细节容易被忽略。就算你修好了主站，别忘了还有虚拟主机、管理后台这些边角料。我遇到过一个案例，主站堵得死死的，但/manager路径下有个老版本的Manager App，照样能PUT。攻击者上传了个test.jsp，文件名里塞了个分号，服务器居然没拦下来。

说到底，这漏洞就是个典型的配置失误。Tomcat本身设计没问题，但人为改动破坏了安全边界。你想想，一个Web服务器默认允许客户端写文件，这本身就是个危险信号。别指望防火墙能挡住，攻击者用POST方法探测一下响应头，看到Server: Apache-Coyote/1.1，就知道是Tomcat了，然后挨个试PUT，总有一个能中。

最后提个醒，如果你用Nginx反代到Tomcat，别以为就安全了。Nginx默认不转发PUT请求，但有些配置会加上proxy_method PUT，反而把攻击流量送进去了。检查一下你的反代配置，别让Nginx成了帮凶。