文章总结： 文章分析Spring目录遍历漏洞CVE-2024-38816/38819，指出其触发需特定代码配置。提供了搜索Jar包特征码的验证方法，建议优先排查代码确认实际风险，采用代码级修复代替框架升级，避免盲目整改。 综合评分： 90 文章分类： 漏洞分析,WEB安全,安全运维
自证安全，聊聊 Spring Framework 鸡肋漏洞 CVE-2024-38816/CVE-2024-38819 的破局之道
原创
国光
安全小姿势
2026年1月6日 19:43 江苏
事情背景
在企业安全运维场景中，普遍痛点始终存在：不少主机安全产品仅通过组件版本比对，就将低版本组件直接标记为高危漏洞；而监管层面的“动态清零”要求虽初衷是筑牢安全防线，但往往未能充分考量企业实际运维困境：一旦检测出高危漏洞，无论其实际利用难度与业务影响，均需限期整改。
正好国光最近遇到的 Spring Framework 目录遍历漏洞 CVE-2024-38816/CVE-2024-38819，正是这类鸡肋漏洞的典型代表，需特定场景触发，实际攻击风险有限，却让不少企业陷入了“不修复过不了监管，修复又面临诸多阻碍”的两难境地。
为何这类漏洞的修复如此棘手？首先修复这2个漏洞的最低安全版本为 Spring Framework 5.3.41 那我们来看看官方目前的支持情况如何？
截止到目前2026年01月06日，Spring Framework 社区免费版本的最低分支为 6.2.x 系列，该系列分支要求最低的 JDK 版本为 JDK 17，很明显国内目前的传统企业大多数都还是 JDK 1.8 版本，总不能为了修一个低风险漏洞重构整个应用吧？安全从来不能凌驾于业务之上，强推 JDK 升级显然不现实。
那退一步，直接升级到 5.3.41 行不行？也不行 ——Spring 社区免费版本的 5.3 系列最高只更到 5.3.39：
想要 5.3.41 及以上的安全版本，必须购买企业付费版本：
所以既然升级修复这条路走不通的话，我们就得直面问题，这被检测出来的 Spring Framework 漏洞 CVE-2024-38816/CVE-2024-38819 漏洞真的存在可以被利用吗？
漏洞分析
这两个漏洞本质是路径遍历（目录穿越）漏洞，当应用通过 RouterFunctions 处理静态资源，且资源配置使用 FileSystemResource 对接服务器物理文件系统时，攻击者可构造恶意 HTTP 请求，读取服务器上的任意文件，造成敏感信息泄露。
安全版本：5.3.41、6.0.25、6.1.14 及以上
触发条件：漏洞存在的必要前提（缺一不可）
- 在使用
RouterFunctions.resources()或RouterFunctions.resource()方法时，未正确限制资源访问路径 - 映射的是服务器物理文件系统路径（
FileSystemResource），而非 jar 包内的ClassPathResource
下面是漏洞 Demo 代码片段：
漏洞利用 POC：
自证清白
其实自证清白很简单，就是直接解压 jar 包，搜索漏洞函数相关特征，如果存在则存在漏洞：
- 检查是否使用 FileSystemResource（漏洞触发必要前提），关键词：
FileSystemResource
- 检查 WebFlux 静态资源映射配置，关键词：
RouterFunctions
那么既然知道原理了，直接使用命令来解压验证。
存在漏洞的情况
# 将有漏洞的 jar 包拷贝到临时目录下
mkdir -p /tmp/spring-vul-check
cp /app/app.jar /tmp/spring-vul-check/
# 直接解压 jar 并搜索关键词验证
cd /tmp/spring-vul-check/
jar xvf app.jar
# 检查是否使用 FileSystemResource
grep -a -r "FileSystemResource" /tmp/spring-vul-check/BOOT-INF/classes/
# 检查 WebFlux 静态资源映射配置
grep -a -r "RouterFunctions" /tmp/spring-vul-check/BOOT-INF/classes/
如果两条搜索命令都命中的话，则才存在对应的漏洞，如下图：
不存在漏洞的情况
首先根据安全产品的特征，拿到有漏洞的 jar 位置信息：
当前安装版本：5.3.27
- SpringBoot项目包路径：/home/epps/appdest/epps-egs-1.0-SNAPSHOT.jar
- SpringBoot子包名称：spring-webmvc-5.3.27.jar
然后进行解压查看是否存在特征函数：
# 将有漏洞的 jar 包拷贝到临时目录下
mkdir -p /tmp/spring-vul-check
cp /home/epps/appdest/epps-egs-1.0-SNAPSHOT.jar /tmp/spring-vul-check/
# 直接解压 jar 并搜索关键词验证
cd /tmp/spring-vul-check/
jar xvf epps-egs-1.0-SNAPSHOT.jar
# 检查是否使用 FileSystemResource
grep -a -r "FileSystemResource" /tmp/spring-vul-check/BOOT-INF/classes/
# 检查 WebFlux 静态资源映射配置
grep -a -r "RouterFunctions" /tmp/spring-vul-check/BOOT-INF/classes/
最后总结
面对 Spring Framework CVE-2024-38816/CVE-2024-38819 这类 “鸡肋漏洞”，企业无需被 版本升级的死胡同困住，也不必在监管要求和业务稳定之间焦虑。
这类漏洞的核心特点是 触发条件严苛，版本高低只是安全产品的 表面判断依据，而非漏洞真实存在的证明。与其盲目推动高成本的 JDK/Spring 版本升级（甚至重构应用），不如先通过关键特征判断漏洞是否真的影响自身系统，若验证后确认无漏洞，可将验证过程和结果作为依据，摆脱无意义整改的内耗，若真的存在漏洞，也无需急于升级版本，可先通过限制 RouterFunctions 资源访问路径、替换 FileSystemResource 为 ClassPathResource 等轻量化方式封堵风险，兼顾业务稳定与安全合规。
安全运维的核心从来不是 “为了修漏洞而修漏洞”，而是基于实际风险做 “精准防护”，既不忽视真实威胁，也不被无意义的整改消耗资源，这才是应对这类鸡肋漏洞的最优解。
明明这类漏洞的触发条件严苛到近乎苛刻，国内这些安全厂商却连最基础的 “漏洞是否真的存在” 都懒得验证，一套 “版本比对” 的原则，管你业务实际场景、管你漏洞触发前提，只要版本没到所谓的 “安全基线”，就打上 “高危漏洞” 的标签，好的安全产品不应该只是版本号的 “复读机”，不应该只知道拿着版本号搞一刀切的形式主义！奉劝某些厂商：别再拿版本当遮羞布了！真要做安全，就沉下心把检测做细、做准，别再用这种懒人式判定消耗企业的信任和资源，客户要的是解决闭环问题，而不是整天被一堆莫须有的 “高危漏洞” 折腾得鸡飞狗跳！
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：安全小姿势 国光《自证安全，聊聊 Spring Framework 鸡肋漏洞 CVE-2024-38816/CVE-2024-38819 的破局之道》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论