8月22日，Spring AI发布了2.0.1版本。距离2.0正式发布只过了不到三周，这个补丁版本一口气修了7个CVE——涵盖PDF文档读取、ONNX模型加载、文件操作、Redis集成、工具调用等多个模块。

更值得注意的是，2.0.1还新增了agentic loop防护机制，专门针对AI Agent在工具调用循环中可能触发的安全风险。

Spring AI是Spring生态的AI框架，定位是让Java开发者用Spring的方式集成AI能力——对话模型、向量数据库、RAG、工具调用、Agent编排。它是Spring官方出品，背靠VMware（原Pivotal），在Java企业级开发中影响力很大。一个被企业级项目广泛依赖的框架，上线三周就修7个CVE，这件事值得认真看待。

7个CVE分别是什么

从Spring AI的GitHub changelog和安全公告中可以还原这7个漏洞的轮廓：

CVE-2026-XXXX1（PDF读取）：Spring AI的文档读取模块在解析PDF文件时存在路径遍历漏洞，恶意PDF可以触发任意文件读取。这是RAG场景的高频入口——企业用Spring AI读取内部知识库PDF做问答，如果知识库PDF被篡改，攻击者可以读取服务器上的任意文件。

CVE-2026-XXXX2（ONNX模型加载）：Spring AI支持加载ONNX格式的机器学习模型，但加载过程缺少完整性校验，恶意模型文件可以在反序列化时执行任意代码。这和Java生态长期面临的反序列化漏洞一脉相承。

CVE-2026-XXXX3/XXXX4（文件操作）：两个文件操作相关的漏洞，一个涉及临时文件处理时的竞争条件，另一个涉及文件写入路径校验不严。

CVE-2026-XXXX5（Redis集成）：Spring AI的Redis向量存储模块在处理用户输入的key时缺少校验，可能导致Redis命令注入。

CVE-2026-XXXX6/XXXX7（工具调用）：两个工具调用相关的漏洞，涉及AI Agent在调用外部工具时对参数校验不严，可能导致命令注入。

7个漏洞，5个方向，但有一个共同特征：它们都和"AI能力"直接相关——PDF读取是RAG的基础能力、ONNX是模型集成、工具调用是Agent的核心机制。这说明Spring AI的安全债不是普通的框架漏洞，而是AI能力引入后产生的新类型安全风险。

AI框架的安全债为什么来得这么快

传统Spring框架的安全更新周期通常以季度为单位，一个框架版本上线后，第一个安全补丁往往要等几个月。Spring AI三周就修7个CVE，速度异常。

原因在于AI框架的攻击面和传统框架完全不同。

传统框架的攻击面是"已知协议"。Spring MVC的漏洞通常出在HTTP参数解析、序列化、权限控制等成熟领域，这些领域的攻击手法和防御方案都相对稳定，漏洞发现速度也相对可预期。

AI框架的攻击面是"未知协议"。Spring AI的RAG模块要读取PDF——PDF解析本身就是一个漏洞高发区（想想Adobe Reader这些年的漏洞数量）；它的Agent模块要调用外部工具——工具调用的参数传递路径是全新的攻击面；它的向量数据库集成要处理用户输入的查询——向量检索的注入攻击目前几乎没有成熟防御方案。

每一个AI能力都自带一整套新的攻击面。框架上线得快，漏洞来得更快。

agentic loop防护意味着什么

2.0.1新增的agentic loop防护是最值得关注的变化。这不是修一个具体漏洞，而是在框架层面新增了一类防御机制。

AI Agent的tool calling本质上是一个循环：模型决定调用哪个工具 → 传入参数 → 执行工具 → 拿到结果 → 模型决定下一步调用什么。这个循环如果没有防护，攻击者可以通过精心构造的工具返回结果让Agent进入无限循环、递归调用、或者触发不安全的工具链。

agentic loop防护的核心是给这个循环加上限制器——最大循环次数、单次工具调用的资源配额、工具链调用的深度限制。这些在传统Spring开发中是不需要的，但在AI Agent场景中变成了基础设施。

这也意味着一件事：AI框架的安全防护正在从"修漏洞"演进到"设计防护机制"。未来Java AI项目的安全需求不只是"有没有CVE被修复"，而是"Agent循环有没有防护、工具调用有没有沙箱、模型输入有没有校验"。

Java团队该怎么应对

Spring AI的7个CVE给Java团队敲了一个钟：AI安全债不是未来的事，是已经在发生的事。

第一，立即升级Spring AI到2.0.1。如果你在用Spring AI 2.0做RAG或Agent，这7个CVE不是"可以以后修"，而是"现在就修"。尤其是PDF读取和工具调用相关的漏洞，在RAG和Agent场景中几乎必然会被触发。

第二，审视依赖链的安全密度。Spring AI本身只是AI框架层，它的下面还有Spring Boot、Spring Framework、各种starter依赖。一个典型的Spring AI项目可能引入了200+个传递依赖，每个依赖都可能有自己的CVE。这不是手动能管理的规模。

第三，建立AI代码的安全兜底流程。传统Java项目的安全审查主要依赖SonarQube和依赖扫描。但AI生成代码引入了新的安全维度——不是"依赖有没有漏洞"，而是"AI生成的代码本身有没有漏洞"。OWASP Top 10级别的漏洞——SQL注入、XSS、路径遍历、硬编码密钥——在AI生成代码中出现的频率远高于手写代码。

飞算JavaAI的Java安全修复器专门处理这个层面。它对项目代码进行OWASP Top 10漏洞扫描，发现问题后直接生成修复代码。配合Jar依赖修复器处理依赖层面的版本冲突、冗余依赖、过期依赖和安全漏洞——这两个工具组合起来，覆盖了AI时代Java项目安全审查的两个核心维度：代码级安全 + 依赖级安全。

Spring AI用三周修了7个CVE，这个速度说明AI框架厂商已经在认真对待安全债。但框架层面的修复是"最后一公里"，AI代码安全需要的是"全链路"——从生成到部署，每个环节都有安全兜底。