文章目录前言这俩漏洞到底是个啥鬼东西CVE-2026-22730SQL注入的借尸还魂CVE-2026-22729JSONPath的暗度陈仓快看看你是不是中枪了受影响的版本范围紧急修复三步走战略第一步升级最靠谱的方案第二步临时缓解措施万一升不了级第三步改代码逻辑治本之策实战检测写个脚本扫一遍深层次思考为什么我们会翻车长期防护建立你的安全雷达1. 订阅官方安全通告2. 依赖扫描工具用起来3. 最小权限原则结语修完漏洞记得喝杯咖啡压压惊参考链接无意间发现了一个CSDN大神的人工智能教程忍不住分享一下给大家。很通俗易懂重点是还非常风趣幽默像看小说一样。床送门放这了 http://blog.csdn.net/jiangjunshow前言兄弟们Spring AI这波背刺来得有点猛。说真的我昨天还在跟同事吹牛逼说咱们这套基于Spring AI的RAG系统稳如老狗结果晚上刷安全通告直接傻眼——Spring官方在3月17号没错就是三天前连发两条高危漏洞公告CVSS评分分别飙到8.8和8.6属于那种看一眼就睡不着觉的级别。这俩漏洞编号记好了CVE-2026-22730和CVE-2026-22729。一个是SQL注入一个是JSONPath注入组合拳打得虎虎生风。更蛋疼的是只要你用的是Spring AI 1.0.x或者1.1.x版本基本都在射程范围内。说白了只要你用了向量数据库做过滤查询就相当于给黑客留了扇后门人家拿着万能钥匙随时能进来翻你家冰箱。我花了一晚上时间复现这两个漏洞今天赶紧把热乎的防护方案写出来。咱不整那些虚头八脑的安全理论直接上手怎么检查、怎么修、怎么防争取让你喝杯咖啡的功夫把坑填上。这俩漏洞到底是个啥鬼东西CVE-2026-22730SQL注入的借尸还魂先说这个评分8.8的狠角色。问题出在MariaDBFilterExpressionConverter这个类上这玩意是干嘛的呢简单理解就是你用Spring AI查MariaDB向量数据库时它负责把你的过滤条件翻译成SQL语句。正常情况下这个过程应该像银行柜台一样柜员代码严格按照规定流程办事客户用户输入说啥都不管用。但这次的bug在于柜员太老实了客户说我要查ID等于1的记录柜员就原封不动地写进SQL。万一客户说的是1 OR 11这种黑话柜员也照办那不就全漏了具体来说当你用FilterExpressionBuilder拼查询条件时如果直接把用户输入的字符串塞进去比如FilterExpressionBuilderbnewFilterExpressionBuilder();b.eq(userId,request.getUserId());// 这里userId如果是恶意构造的...如果userId被填成了1 OR 11这种 payload因为没有做充分的转义处理最后生成的SQL就变成了SELECT*FROMvector_storeWHEREmetadata-$.userId1OR11好家伙这后面的OR 11一加上去直接变成查询所有记录了。这就是典型的SQL注入只不过套了个向量数据库的马甲。CVE-2026-22729JSONPath的暗度陈仓第二个漏洞评分8.6原理类似但玩的是JSONPath注入。这次中招的是AbstractFilterExpressionConverter也就是所有向量存储过滤器的祖宗类。JSONPath这玩意儿可以理解为在JSON文档里找东西的导航系统。正常情况下你应该只能查自己有权限看的数据比如.tenantId user123。但如果系统没处理好攻击者可以注入额外的JSONPath逻辑比如改成.tenantId user123 || $.role admin甚至直接把整个查询逻辑改写。最骚的是这漏洞能直接绕过多租户隔离。想象一下你开发了个SaaS系统每个客户只能看自己的文档结果因为这么个过滤条件没处理好客户A随便构造个请求就能看到客户B的私密数据这不就全完了快看看你是不是中枪了别光听我在这吓唬人先看看你的项目有没有踩雷。检查方法很简单打开你的pom.xml或build.gradleMaven用户看这里org.springframework.ai spring-ai-mariadb-store 1.0.3Gradle用户看这里implementationorg.springframework.ai:spring-ai-mariadb-store:1.1.2// 同样是高危版本受影响的版本范围Spring AI 1.0.0 - 1.0.31.0线全灭Spring AI 1.1.0 - 1.1.21.1线也全灭如果你用的是其他向量存储比如Redis、MongoDB、PgVector也别高兴太早。虽然CVE-2026-22730只针对MariaDB但CVE-2026-22729影响的是AbstractFilterExpressionConverter这个基类只要你用了过滤表达式功能理论上都可能有风险。紧急修复三步走战略第一步升级最靠谱的方案Spring官方已经发布了修复版本1.0.x用户升级到1.0.41.1.x用户升级到1.1.3Maven直接改版本号1.1.3Gradle同理ext{set(springAiVersion,1.1.3)}升级完之后记得跑一遍你的集成测试特别是那些涉及向量搜索、元数据过滤的用例。Spring AI的API在1.0到1.1之间有些breaking changes虽然1.0.4是patch版本但小心驶得万年船。第二步临时缓解措施万一升不了级我知道有些 legacy 项目牵一发而动全身升级版本可能要排期到下周甚至下个月。在这种青黄不接的时候你得先加个止血带——输入验证。既然漏洞是因为用户输入直接拼进查询导致的那咱们就手动过滤一下危险字符。可以搞个简单的工具类ComponentpublicclassFilterInputSanitizer{// 这些字符在JSONPath和SQL里都是危险分子privatestaticfinalPatternDANGEROUS_CHARSPattern.compile([\\\\\|!]);publicStringsanitize(Stringinput){if(inputnull){returnnull;}// 简单粗暴但有效把危险字符全干掉或转义returnDANGEROUS_CHARS.matcher(input).replaceAll();}}然后在你的Repository层加上这层防护ServicepublicclassDocumentService{AutowiredprivateFilterInputSanitizersanitizer;AutowiredprivateVectorStorevectorStore;publicListsearch(StringuserId,Stringquery){// 先洗一遍输入StringsafeUserIdsanitizer.sanitize(userId);SearchRequestrequestSearchRequest.builder().query(query).filterExpression(userId safeUserId)// 注意即使做了sanitize这种拼接方式依然不推荐只是权宜之计.build();returnvectorStore.similaritySearch(request);}}注意这只是临时方案千万别觉得这样就高枕无忧了。真正的安全还得靠升级。第三步改代码逻辑治本之策其实就算没这漏洞直接拼接查询字符串本来就是个坏习惯。Spring AI提供了参数化查询的方式或者说你应该把过滤条件拆得更细别给用户直接操作查询字符串的机会。推荐的做法是用Filter.Expression的API而不是直接传字符串// 不推荐直接把用户输入拼进表达式Stringexprauthor userInput;// 推荐用类型安全的方式构建FilterExpressionBuilderbuildernewFilterExpressionBuilder();Expressionexprbuilder.eq(author,userInput).build();// 升级后的版本会正确处理转义实战检测写个脚本扫一遍光修代码不够你还得确认生产环境到底有没有被捅过。虽然这两个漏洞刚披露三天被大规模利用的可能性还不高但检查一下日志总是好的。可以写个简单的Python脚本或者Java随你喜好扫一下你的访问日志看看有没有可疑的查询参数importre# 可疑的payload特征suspicious_patterns[r\sOR\s1\s*\s1,# SQL注入经典payloadr||.,# JSONPath注入尝试r\s*[^\s],# 逻辑运算符注入r[^]..*# 引号逃逸尝试]defcheck_logs(log_file):withopen(log_file,r)asf:forline_num,lineinenumerate(f,1):forpatterninsuspicious_patterns:ifre.search(pattern,line,re.IGNORECASE):print(f[ALERT] 第{line_num}行发现可疑请求:{line.strip()})breakif__name____main__:check_logs(/var/log/app/access.log)当然如果你用了ELK或者Grafana Loki这种日志系统直接在里面搜关键词更快。重点搜||、、这些在过滤表达式里不该出现的组合。深层次思考为什么我们会翻车这次漏洞给我最大的感触是——别把用户当好人。Spring AI作为一个相对年轻的框架1.0正式版其实也就这一年多的事在便利性上确实做得很好几行代码就能对接大模型和向量数据库。但便利性往往伴随着牺牲它为了让你写得更爽默认把很多细节藏起来了比如这次的过滤表达式拼接。很多开发者包括我在用这些高级封装时很容易产生一种框架会帮我处理好安全的错觉。但现实是框架只提供能力安全还得靠你自己把关。就像给你一把瑞士军刀它能开瓶盖也能割手指关键看你怎么用。另外这也暴露了AI应用的一个通病大家太关注模型效果忽视了工程安全。咱们都在卷RAG的准确率、Agent的响应速度结果基础的数据库查询安全都没做好。这次Spring AI的漏洞说白了就是把传统Web开发时代早就趟过的坑在AI时代又踩了一遍。长期防护建立你的安全雷达1. 订阅官方安全通告这次漏洞我是从Spring官方安全页面看到的建议你把它加入浏览器收藏夹或者订阅RSS。Spring团队处理安全问题的响应速度还是挺快的从漏洞发现到发布补丁也就几天时间但你要是不知道那就等于零。2. 依赖扫描工具用起来如果你还没用OWASP Dependency Check或者Snyk这类工具赶紧安排上。这些工具能自动扫你的依赖库一旦发现高危CVE会直接报警。比如这次Spring AI的漏洞这些工具在3月18号之后就已经能识别了。Maven里配一下CI/CD流水线跑起来。3. 最小权限原则就算没有注入漏洞你的向量数据库连接账号也不应该有DROP TABLE权限。按照最小权限原则应用账号只给SELECT和INSERT就够了。这样就算真的被注入损失也能控制在一定范围内不至于整个库被拖走。结语修完漏洞记得喝杯咖啡压压惊写到这看了眼字数差不多两千字了。其实技术这东西最怕的不是出问题而是出了问题你不知道。这次Spring AI的双漏洞虽然评分高但修复起来还算简单升个版本号的事比那些内核级别的漏洞友好多了。最后提醒一句升级完之后记得在测试环境跑一遍你的AI功能特别是那些依赖元数据过滤的场景。vector store这玩意儿查询逻辑稍微变一点召回率可能就掉几个点安全性和准确性咱们得两头兼顾。好了该说的都说了赶紧去改代码吧。改完记得给自己点杯奶茶毕竟又阻止了一次潜在的数据泄露惨案这杯奶茶你值得拥有。参考链接Spring官方安全通告 CVE-2026-22730Spring官方安全通告 CVE-2026-22729阿里云漏洞库详情NVD漏洞数据库本文技术细节基于2026年3月17-20日公开的安全通告修复方案已在本地环境验证通过。如有遗漏欢迎在评论区指正。