Query-Injection Flaw in Spring AI Vector Stores: CVE-2026-47835, Update to 1.0.9 / 1.1.8 Now

Spring AI, a popular framework for building generative-AI apps in Java, has a flaw rated 8.6. It is tracked as CVE-2026-47835. Using input laced with special characters, an attacker can — with no login — run unauthorized queries against the database an AI app uses behind the scenes.

On June 12, 2026, the Spring team published a security advisory and released fixed versions 1.0.9 and 1.1.8. Developers of apps using Spring AI should update promptly. The issue was reported by Nitro Cao of Alibaba Cloud.

What are Spring AI and a vector database

Spring AI is part of "Spring," the staple Java framework, and bundles the building blocks for adding AI features (chatbots, internal document search, and so on) to an app. Riding the wave of Spring's wide use in enterprise Java, it is being adopted rapidly for building generative-AI apps.

At its core is the vector database. In a setup where you have an AI memorize internal manuals or product information and "answer from these documents" (known as RAG), text is converted into sequences of numbers and stored in this specialized database, which then finds content close to the question. Spring AI provides components to connect to leading databases such as Elasticsearch, OpenSearch, and GemFire.

When a user searches, they can attach a specification to narrow results to "only those matching this condition" (a metadata filter). This vulnerability sat in how that narrowing condition is handled when special characters are mixed in.

When the AI's Memory Bank Becomes a Shelf Anyone Can Open

Before the number 8.6, it is more telling to recall "what, exactly, is stored in that vector database." What you feed an AI to answer from is usually unpublished internal material, exchanges with customers, or non-public product information — content gathered into one place for the convenience of search.

The ones who reach into the gaps of that narrowing condition are attackers probing the input fields and APIs of public AI apps one after another, crews that steal and trade corporate internal documents, industrial spies hunting a competitor's unreleased information, and data brokers after the personal data an AI was given. What they come for is not abstract "data" but the contracts and design documents the AI memorized, the names and contact details in inquiry histories, and the very text stored for search. Because no login is required, it works just by entering a crafted string into the app's search box. The moment a malicious query is slipped into the narrowing condition, the contents of the memory bank the AI refers to are searched and pulled out wholesale — well beyond what should ever be visible.

In security terms, this is "query injection," the same family as the familiar SQL injection. It is the type where an attacker's string sneaks in as a command into the text that builds a database query, and combined with features that Elasticsearch and the like provide, it leads to reading data that was never meant to be exposed. Because a "door anyone can touch" — a search box or an API — becomes the exploitation path directly, attackers can crawl apps automatically to find where it lands rather than picking them off by hand. An AI app may look like new technology, but behind it is an old-fashioned database, and a mistake in handling input falls into the same trap.

The number "8.6" only marks technical severity. The pile of documents you have an AI read are often the internal documents you want the AI to digest because you cannot handle them all by hand, the secrets you keep closed within an internal AI precisely because they cannot leave, and the customer information you have been entrusted with. What is really lost is not "one database" but the trust of the partners named within it, the plans not yet made public, and the information entrusted to you by others.

CVE-2026-47835: a malicious query gets through the narrowing condition

According to Spring's advisory, CVE-2026-47835 means "special characters could be used to force the execution of arbitrary queries in Elasticsearch, OpenSearch, and GemFire VectorDB." It is classified as a failure to neutralize special characters when building a database query (CWE-943).

By rights, the string passed as a search-narrowing condition should be treated as "just data." But when that string is used as-is while building the database query, the command an attacker slipped in gets executed. As a result, the database's contents can be read beyond the intended narrowing, among other impacts.

The technical scoring (CVSS vector) is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L, for a score of 8.6. The gist is: over the network (AV:N), under easy conditions (AC:L), with no login (PR:N) and no user interaction (UI:N), it succeeds, and the impact on information disclosure is at the maximum (C:H). The ratings for tampering and outage are limited, but the damage leans heavily toward data being exfiltrated, and the lack of any authentication raises the severity.

Affected versions, and what to do now

Affected are the Spring AI vector database integrations for Elasticsearch, OpenSearch, and GemFire. Check the version of Spring AI you use.

The fix is clear: update the Spring AI dependency to 1.0.9 or 1.1.8 or later. Per Spring, no additional mitigation is needed once updated. Bump the dependency version in Maven or Gradle, rebuild, and redeploy. If you do not use the Elasticsearch, OpenSearch, or GemFire integrations, you are not directly affected by this CVE, but keeping dependencies up to date across the board is the safe approach.

This kind of "a vulnerability slips into a component (open source) you pulled in from outside" happens regardless of language. Knowing which library and which version your app depends on is the prerequisite for moving fast when a fix lands. For npm or Python dependencies, our OSS vulnerability scanner offers a paste-and-check option.

This is not Spring AI's first vector-DB injection

In Spring AI, this "a malicious command gets through the search-narrowing condition" type has been found repeatedly over the past few months. In 2026, a JSONPath injection in a different database integration (CVE-2026-22729) and a case where the filter-expression handling could even run code on the server (CVE-2026-22738) were disclosed one after another. Today's CVE-2026-47835 is a new entry in that line. The same spot — filter processing — keeps becoming the weak point.

Vulnerabilities continuing in AI-development components are not unique to Spring AI. On this site we have covered the unauthenticated takeover of LiteLLM, which fronts various AIs (CVE-2026-42271), the recurring RCE in the inference server vLLM (CVE-2026-4944), and a poisoned package planted into Guardrails AI (CVE-2026-45758). The newer the field, the more the components' workmanship lags, and basic input-handling holes tend to remain.

Exploitation status, and what to keep an eye on

As of June 15, 2026, there are no reports of CVE-2026-47835 being used in real attacks, and it is not listed in the U.S. government's CISA KEV catalog of actively exploited vulnerabilities. You can track the latest status of exploited flaws in one place on our CISA KEV dashboard (Japanese).

That said, query injection is familiar territory for attackers, it requires no login, and it can be tried from the input fields of a public AI app. If details of the pre-fix behavior circulate, follow-on abuse is entirely possible. Updating the dependency now, while the fix is out, is the most reliable defense.

References

• ▸ NVD - CVE-2026-47835 (published June 15, 2026)
• ▸ Spring - CVE-2026-47835 (official advisory, fixed in 1.0.9 / 1.1.8)
• ▸ MITRE - CWE-943: Improper Neutralization of Special Elements in Data Query Logic
• ▸ Spring - CVE-2026-22729 (related: earlier vector-DB injection)
• ▸ CISA - Known Exploited Vulnerabilities Catalog