AI-powered scanning tools found security holes in the AI framework. That’s the shape of Broadcom’s June 8 announcement: the company released what it called the largest set of Spring security updates in the framework’s 23-year history, prompted by a 1,700% jump in CVE reports between March and April 2026. The surge was driven by AI-assisted vulnerability scanning doing exactly what it was designed to do — and finding flaws in the very frameworks teams use to build AI applications. The worst of those flaws lets unauthenticated attackers achieve remote code execution on any Spring AI service that passes user-supplied input into a vector store filter. You have until June 30 before Spring Boot 3.5 and Spring AI 1.x hit end-of-life.
The Critical Flaw: SpEL Injection to RCE (CVE-2026-22738) #
CVE-2026-22738 carries a CVSS score of 9.8 — Critical, unauthenticated, no user interaction required. The vulnerability is in Spring AI’s SimpleVectorStore
, a component many developers use during development and testing, and not a few have left running in production. When user-supplied input is passed as a filter expression key, it flows into StandardEvaluationContext
without sanitization. That context evaluates arbitrary Spring Expression Language, which means an attacker can call Java classes, navigate the runtime, and execute system commands.
The exploitation chain is not theoretical. Resecurity published a full breakdown of the RCE path, and TryHackMe already has an active room on it — a reliable signal that attackers are drilling this. The fix in versions 1.0.5 and 1.1.4 swaps StandardEvaluationContext
for SimpleEvaluationContext
, the same pattern used to close CVE-2022-22963. Upgrade.
If you cannot upgrade immediately, whitelist the filter expression keys your application accepts and validate all input before it reaches the builder. That is a mitigation, not a fix.
The Vector Store Attack Surface Is Wider Than You Think #
CVE-2026-22738 is the most severe, but it is not alone. The same research cycle produced injection flaws across other Spring AI vector store implementations:
CVE-2026-22730 (CVSS 8.8 — SQL injection): The MariaDB vector store concatenates filter expressions directly into SQL without escaping. Attackers with minimal privileges can bypass metadata-based access controls and run arbitrary SQL against the underlying database. Multi-tenant RAG pipelines built on MariaDB should treat this as a data breach vector.CVE-2026-22729 (CVSS 8.6 — JSONPath injection):AbstractFilterExpressionConverter
— used by PgVectorStore and several other vector stores — passes unescaped characters ("
,||
,&&
) into JSONPath queries. An attacker in one tenant can craft filter expressions that return documents belonging to another. If you built document-level access control on top of this,that control is currently bypassable.
Additional injection variants affecting Neo4j (Cypher) and Milvus vector stores were also patched in the same release cycle. The pattern is consistent: user-controlled input flowing into query builders without sanitization. The vector store filter API was designed for flexibility; that flexibility became the attack surface.
The EOL Deadline Is June 30 #
Spring Boot 3.5 reaches open-source end-of-life on June 30, 2026 — 15 days from today. Spring AI 1.x tracks Boot 3.5, so both enter the unsupported zone together. After that date, new CVEs get patched in upstream releases only; there are no backports. Teams that do not act before June 30 are committing to running unpatched software indefinitely.
The long-term migration target is Spring AI 2.0 on Spring Boot 4.0. But that migration is not a weekend project — Broadcom estimates 83 breaking changes in Boot 4.0, with effort ranging from 200 to 500 hours. Jackson 3 is required (date serialization and property ordering defaults change silently). JUnit 4 is gone. Java 21 is the minimum.
The practical path for most teams right now: patch to Spring AI 1.0.5 or 1.1.4 on the current Boot 3.5 baseline, lock in extended support if the budget allows, and plan the Boot 4 migration for Q3.
The AI Security Feedback Loop #
The 1,700% CVE surge is not a blip. AI-powered vulnerability scanning tools are systematically discovering new injection classes across codebases that have been stable for years. Spring is a 23-year-old framework; it has been through many security cycles. This one is different because the discovery rate now outpaces the remediation capacity of most teams.
Broadcom’s response acknowledges this explicitly. They have scaled AI-assisted security analysis using frontier models to scan, test remediation options, and verify fixes across the full dependency graph. For enterprise Tanzu customers, day-zero CVE patches now land before the open-source release — meaning there is a window after enterprise patching and before public disclosure where the gap exists for open-source users.
The structural irony is hard to miss: the tools that found these vulnerabilities are the same generation of AI systems that Spring AI is designed to integrate. AI scanning Spring AI. The security surface of AI-adjacent code is growing faster than the teams maintaining it can track manually.
What to Do Right Now #
Check your pom.xml
or build.gradle
. If you are on Spring AI 1.0.x or 1.1.x:
- Upgrade to 1.0.5(1.0.x line) or** 1.1.4**(1.1.x line) immediately — both are available on Maven Central - Review any code path that passes user-controlled input to vector store filter expressions
- Treat CVE-2026-22738 as P0 if your application exposes vector search to external users
- Make the Boot 4 migration a dated roadmap item before June 30 — not an aspiration
The alternative is running production workloads on an unsupported platform with no security backports, while the CVE rate continues to climb. At 1,700% quarterly growth, that is not a risk worth taking.