Spring4Shell（CVE-2022-22965）刚爆出来那天，服务我正盯着一个客户的漏洞Tomcat日志看。日志里有个奇怪的补丁请求参数，名字叫“class.module.classLoader.resources.context.parent.pipeline.first.pattern”，服务长得像一串乱码。漏洞当时没反应过来，补丁第二天整个安全圈就炸了。服务这个漏洞影响Spring Framework 5.3.0到5.3.17、漏洞5.2.0到5.2.19，补丁以及更早的服务不受支持版本。攻击者能在特定条件下通过数据绑定机制写入JSP文件，漏洞直接拿shell。补丁不是服务理论上的风险，是漏洞实打实的远程代码执行。

补丁其实不复杂。补丁Spring官方在5.3.18和5.2.20里修了。核心改动在WebDataBinder里加了一个disallowedFields，把class.*、Class.*、*.class.*、*.Class.*全拉黑。你如果没法立刻升级，临时方案是在@ControllerAdvice里写个@InitBinder方法，手动设置setDisallowedFields。但注意，这个临时方案只对Spring MVC的@ModelAttribute和@RequestParam绑定生效，对WebFlux无效。WebFlux用户只能升级。

我见过有人改完@InitBinder就以为万事大吉，结果忘了Tomcat的web.xml里还有readonly参数没设。Spring4Shell利用链依赖Tomcat的AccessLogValve，如果readonly设成true，攻击者写不了JSP。但这不是根因修复，只是堵了一条路。攻击者换个容器、换个日志配置，照样能打。所以别把缓解措施当补丁用。

升级本身有个坑。Spring Boot 2.6.6和2.5.12已经包含了修复后的Spring Framework版本。但如果你用的是Spring Boot 2.6.5，手动把spring-framework.version属性改成5.3.18，可能会遇到依赖冲突。我试过一次，spring-webmvc和spring-core版本不一致，启动直接报NoSuchMethodError。稳妥做法是直接升Spring Boot小版本，别单独改Framework版本。Maven项目里跑一下mvn dependency:tree | grep spring，确认所有spring-*包版本对齐。

另外，这个漏洞的利用条件比想象中宽松。不需要Spring Security，不需要特定注解，只要应用跑在Tomcat上、用了Spring MVC的数据绑定、JDK 9以上。JDK 8反而不受影响，因为class.module.classLoader这个链在JDK 8里走不通。但2022年谁还只用JDK 8？我手头五个项目，四个已经上了JDK 11或17。所以别侥幸。

补丁打完之后，建议做一次回归测试。重点测表单提交和API参数绑定。因为disallowedFields加得太狠，有些正常字段如果名字里带“class”字样，比如className、classId，会被一并拦截。我遇到过前端传classId，后端直接绑定失败，报400。解决办法是把disallowedFields写成class.*而不是*class*，精确匹配。Spring官方默认配置已经考虑到了这点，但如果你自己写@InitBinder，容易踩坑。

最后说个观察。Spring4Shell的补丁发布后，很多团队只升了生产环境，忘了CI/CD流水线里的构建镜像。结果测试环境还是老版本，自动化测试跑得欢，一上生产就出事。补丁管理不是一次性的活，得把版本号写进基线检查脚本。每次构建前跑一遍mvn versions:display-dependency-updates，比事后救火强。