A Read-Only API Key Was Enough: What the 2026 Vector-Store and RAG Framework CVEs Say About Your Trust Boundaries

Most teams draw the trust boundary for a retrieval-augmented generation (RAG) system in the same place. The vector store is "data infrastructure," so it belongs to the platform team. The application tier gets a read-only key, so the blast radius is capped at whatever is already in the index. The orchestration framework in between is a library, so it inherits the application's threat model instead of having one of its own.

Three separate 2026 advisories break that drawing in three different places, and CISA's exploitation data shows the layer actually under attack is none of the three.

Where the RAG trust boundary is actually drawn, and where teams think it is

Headlines here collapse structurally different events into one word, so here is the scale used below.

Every incident named in this post is Category C. None is a Category D breach. Qdrant, LangChain, IBM, BerriAI, n8n, Marimo and Microsoft did not have their corporate systems, repositories or customer data compromised in any of these records. Software you run contained a flaw, so the action is yours, on your estate, against your version numbers. A listing in CISA's Known Exploited Vulnerabilities catalog does not upgrade a C into a D either; it means the product flaw is being exploited in customer deployments, and yours is a customer deployment.

Qdrant CVE-2026-25628: read-only access is enough, and the vendor's own impact rating is remote code execution

Category C. Qdrant's advisory is titled "qdrant has arbitrary file write via /logger endpoint" (Qdrant, GHSA-f632-vm87-2m2f). Two lines carry the argument.

The Impact section reads, in its entirety: "Remote code execution."

The privilege statement reads: "Minimal privileges are required (read-only access)." That is the vendor's own wording, not a journalist's paraphrase, and NVD's independently written description repeats the clause verbatim (NVD, CVE-2026-25628). Two primary sources agree that the credential most teams hand the application tier as the safe option reaches a flaw the vendor rates as code execution.

At the level a defender needs: the endpoint accepts an attacker-controlled log file path, permitting appends to files outside the intended directory, and the vendor notes it has an authentication check but no authorization check. That is the crux. "Read-only" describes what an identity may do to the data plane. It says nothing about which administrative and diagnostic surfaces the same identity reaches on the same API.

The vendor's own workarounds need no code change: limit the /logger endpoint to users with management privileges or disable it, and restrict the log file path to a dedicated logs directory. The advisory ships a working proof of concept; none of it is reproduced here, and you do not need it to remediate.

For prioritisation, CISA's SSVC decision in the NVD record is exploitation "poc", automatable "no", technical impact "total". It is not being mass-exploited, not trivially wormable, and not in KEV as of catalog version 2026.08.07.

The disagreement is substantive: NVD rates attack complexity low and scope unchanged, the CNA rates complexity high and scope changed. Triage against NVD's 8.8, because it is the Primary score in the authoritative record and it is what vulnerability management tooling consumes. Read the CNA vector to judge real-world reachability, because attack complexity is a product judgement the maintainers are better placed to make.

Two version numbers, one bug: when the vendor advisory and NVD disagree about what is patched

This is the part that quietly breaks remediation tracking. Three authoritative statements exist about one CVE and they do not agree.

Read the last row again. NVD's structured configuration marks 1.16.0 as inside the vulnerable range, contradicting the prose directly above it in the same record.

The practical consequence: two software composition analysis tools reading different feeds return different answers for the same host, and neither is malfunctioning. A node on 1.15.7 is clean by the GHSA range and flagged by the NVD range.

The vendor's fix commit shipped in 1.15.6, so 1.15.6 is a defensible floor. For a floor no published record contradicts, go above 1.16.0. Either way, record which source the remediation ticket used, because the next assessor will be reading the other one. This divergence is wider and more frequent across AI infrastructure than across mature enterprise software. Print both; do not silently pick one.

LangChain CVE-2025-68664: not an RCE, and why calling it one gets the real harm deprioritised

Category C. The advisory is titled "LangChain serialization injection vulnerability enables secret extraction in dumps/loads APIs" (GHSA-c67j-w6g6-q2cm). It affects langchain-core and is patched in 0.3.81 and 1.2.5.

The advisory never uses the phrase "remote code execution." It says attackers who control serialized data can "extract environment variable secrets" by injecting structures that load environment variables during deserialization, in the configuration where secrets_from_env=True, which the advisory notes "was the old default." It adds that an attacker can instantiate classes within trusted namespaces with controlled parameters, "potentially triggering side effects such as network calls or file operations."

Both vectors show confidentiality high, integrity low, availability none. That is the signature of a secrets-disclosure bug, and the weakness class is CWE-502, deserialization of untrusted data.

The mislabelling is expensive. An "RCE in LangChain" headline routes the ticket to the queue where the remedy is "upgrade the package and close." The accurate label routes it elsewhere. Environment variables in a retrieval service are, in almost every deployment we see, the model provider key, the vector store key, the database connection string and whatever cloud credential the container assumed. Patching removes the flaw and does nothing about credentials that may already have left. Rotation is the remediation; patching is the prerequisite.

Concretely: floor langchain-core at 0.3.81 or 1.2.5, confirm you are not relying on the old secrets_from_env default, and rotate every secret that lived in the environment of a service that deserialized untrusted-influenced data.

Pickled indexes are executable: IBM Langflow's FAISS component and the shared-index problem

Category C. IBM's advisory for CVE-2026-3357, published 8 April 2026 under source identifier psirt@us.ibm.com, states in full: "IBM Langflow Desktop 1.6.0 through 1.8.2 Langflow could allow an authenticated user to execute arbitrary code on the system, caused by an insecure default setting which permits the deserialization of untrusted data in the FAISS component" (GHSA-g2wf-gm3w-w9x3). It is CWE-502, scored 8.8 by IBM as a secondary score, with no NVD primary score assigned.

Two things matter more than the score.

First, the advisory lists no patched version, and the GitHub Advisory Database shows that field as unknown. Do not infer a fix release from a nearby version number. Until IBM publishes one, this is a configuration and provenance problem, not an upgrade.

Second, the generalisable point. A serialized index is not a data file that gets read. It is an artifact that runs at load time, in the loading process, with that process's privileges. Teams share prebuilt indexes because embedding a large corpus is expensive, so the index gets published to a bucket, cached in CI, passed between environments or pulled from a public hub. Each hop converts a compute-saving optimisation into a software supply chain most organisations have no provenance controls over. The same failure appears on the model-file side, where a clean scanner result does not mean a safe artifact (Stingrai, when a clean model scan is not enough).

The control is boring and effective: treat index artifacts like binaries. Name their origin, hash or sign them, pin allowed sources, prefer formats without executable semantics where the framework supports it, and never load an index whose provenance you cannot state in one sentence.

Already being exploited: the AI orchestration entries now sitting in CISA KEV

Category C throughout, with observed exploitation. The advisories above are the ones people argue about. The layer actually being exploited is the orchestration tier between the application and the store.

As of catalog version 2026.08.07 (1,662 total entries, 178 added during 2026), CISA's Known Exploited Vulnerabilities catalog holds ten entries covering AI orchestration and workflow software (CISA KEV).

Four things a defender can act on.

The low-privilege key is the recurring theme. CISA's description of CVE-2026-42271 says the LiteLLM command injection "could allow any authenticated user, including holders of low-privilege internal-user keys, to run arbitrary commands on the host." NVD adds that the affected functionality was gated only by a valid proxy API key with no role check, and is fixed in 1.83.7. That is the Qdrant lesson one layer up: possession of a low-privilege key was the entire authorization model.

A gateway is a credential store. CISA describes CVE-2026-42208, the LiteLLM SQL injection added on a three-day clock, as allowing an attacker to read and potentially modify the proxy's database, "leading to unauthorized access to the proxy and the credentials it manages." A gateway brokering provider keys company-wide is a secrets system with a chat-shaped front end, and should be scoped like one.

One of these is a plain authorization bug. CVE-2026-55255 is an insecure direct object reference in Langflow, CWE-639, which per NVD lets an authenticated attacker execute a flow belonging to another user by supplying the victim's flow identifier, fixed in 1.9.1. It reached KEV on 7 July 2026 with a three-day deadline. No scanner signature finds that, because the request is well-formed and the response is valid; only logic-aware testing does (Stingrai, why API scanners miss BOLA and IDOR). Its neighbour CVE-2026-33017 is the opposite shape, an unauthenticated code injection scored 9.3 under CVSS 4.0 with 1.9.0 as the patched release (Langflow, GHSA-vwmf-pq79-vjvx).

Your inventory may not match the catalog. CVE-2026-9198 is filed under vendor "IBM" while the five older Langflow entries are filed under "Langflow," so an inventory keyed on vendor name misses half of them. IBM scores it 9.8 as a secondary score; NVD assigned no primary.

One further signal, with a caveat worth stating precisely. Every KEV entry added on or after 7 July 2026 carries required-action text referencing BOD 26-04 and CISA's forensic triage requirements, and most now carry three-day deadlines: 27 of the 31 entries added in that window, with four still at 14 days. Three-day clocks predate the transition, though. CVE-2026-42208 above was added on 8 May 2026 with a three-day deadline under the older BOD 22-01 text, and 44 entries added before 7 July 2026 carry a three-day clock, all of them from 2026. Do not model the change as a clean date cutover in either direction; an SLA written against a flat 14 or 21 day KEV window is stale regardless (Stingrai, is your pentest report still valid).

When the vendor record itself is inconsistent: reading a cloud-service CVE you cannot scope

Category C, and instructive. Microsoft Copilot Studio's CVE-2026-21520 was published on 22 January 2026 under source identifier secure@microsoft.com and is tagged in NVD as an exclusively hosted service (NVD, CVE-2026-21520).

The description reads: "Exposure of Sensitive Information to an Unauthorized Actor in Copilot Studio allows a unauthenticated attacker to view sensitive information through network attack vector." The assigned weakness is CWE-77, improper neutralisation of special elements used in a command. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, scored 7.5 High, supplied by Microsoft as a secondary score. NVD assigned no primary score.

The internal inconsistency is the finding, and it is all the record supports: a command-injection weakness class paired with a confidentiality-only impact vector and a description mentioning only viewing sensitive information. A command-injection class normally implies integrity impact at minimum; this vector asserts none. We will not speculate about the underlying flaw, because Microsoft's record does not say and no primary source we could retrieve does either.

The operational lesson matters more. The affected version field is a single hyphen: no version floor to enforce, no artifact to scan, and no way to tell whether your tenant was affected, for how long, or what was reachable. For hosted AI services the CVE record is not an asset management input. The remedies are contractual: ask the vendor in writing for tenant-level impact and dates, and get that obligation into the agreement before you need it.

Detection and remediation: key scoping that actually constrains, index provenance, deserialization policy

Beyond version floors, four controls do most of the work.

Make "read-only" mean something at the network layer. A read-only role constrains data-plane operations; it does not enumerate which administrative endpoints the same identity reaches. Put the store behind an authenticating proxy that allows only the query and upsert paths your application actually calls, and deny the rest by path, not by role.

Give index artifacts a provenance policy. Allowlist load origins, hash or sign at build time, verify at load time, fail closed, and prefer non-executable serialization formats where the framework offers them.

Write a deserialization policy for the app tier. Any path deserializing data influenced by a user, document, webhook or retrieved chunk is in scope. Default it to the safest configuration, and treat a change to that default as security-relevant.

Instrument the signals that would show abuse. The useful telemetry is unglamorous: writes by the vector store's own process outside its data directory, changes to its logging or diagnostic configuration, a retrieval service opening outbound connections it never opened before, index loads from origins not on the allowlist, and orchestration hosts spawning child processes. Most teams log queries and not configuration changes, which is backwards for this class.

What a pentest should now cover: the RAG data plane as a normal application target

The through line is that the RAG data plane is ordinary application attack surface behind an interesting user interface. Add these to your next statement of work:

• The vector store's full HTTP surface, not only query and upsert, tested with the exact credential the application tier uses in production.

• Object-level authorization across every identifier the orchestration layer accepts: flow, collection, namespace, index and tenant. CVE-2026-55255 is the canonical example.

• The AI gateway as a credential-holding system: role enforcement on administrative functions, injection into anything reaching a database or a shell, and what a low-privilege key can actually do.

• Deserialization paths, including index loading and any framework serialization helper reachable from user-influenced input.

• Index and model artifact provenance end to end, from build to load.

• Version-floor verification against both the vendor advisory and NVD, with divergences recorded rather than resolved.

None of this is novel testing. It is authorization testing, injection testing and supply chain review applied to components scoped out because someone filed them under "data infrastructure." Our guidance on RAG control points goes deeper on ingestion and tenant isolation (Stingrai, testing RAG vector store access control), and the MCP layer carries its own considerations (Stingrai, MCP server security assessment).

Stingrai has run offensive security engagements since 2021 from Toronto and London. We are a CREST-accredited penetration testing service provider at firm level, with individual testers holding CREST CRT, 18 published CVEs, and a 5.0 out of 5.0 average across 19 Clutch reviews. For web applications, our autonomous agent Snipe hunts the complex classes scanners miss, including IDOR, broken authorization and business logic, exactly the shape of the Langflow KEV entry above. Web application testing is US$3,000 one-time or US$450 per month for Autonomous, and US$6,800 one-time or US$1,275 per month for Hybrid, where every finding is validated by a human tester. Both tiers carry our "No High or Critical Finding = Don't Pay" guarantee; details are on our pricing page.

On the compliance question that follows: only PCI DSS v4.0.1 mandates penetration testing across a general population, and CMMC at Level 3 only. ISO 27001, SOC 2, NIST SP 800-171 and NIS2 do not, and ISO 27001 and SOC 2 set no frequency. Our reports and retests are the offensive-security evidence your assessors and enterprise customers ask for.

Frequently Asked Questions

Are vector databases a security risk?

They are ordinary network services carrying ordinary network-service risk, and in 2026 one of them shipped a flaw its own vendor rated as remote code execution. Qdrant's advisory for CVE-2026-25628 states that minimal privileges are required to reach it, specifically read-only access, and NVD's independently written description repeats that clause. The risk is not exotic: the store is usually deployed with weaker network controls than a database of equivalent sensitivity, and its administrative endpoints answer to the same identity as its query endpoints.

What is CVE-2026-25628 in Qdrant and which version fixes it?

It is an arbitrary file write reachable through the /logger endpoint using an attacker-controlled log file path, classified CWE-73, with the vendor's Impact section stating "Remote code execution." The fix version depends on which authoritative record you read, and they disagree: Qdrant's advisory says versions from 1.9.3 up to but not including 1.15.6 are affected and 1.15.6 is patched, while NVD's description says "before 1.16.0" and "fixed in 1.16.0," and NVD's machine-readable range marks 1.16.0 as still within the vulnerable set. Use 1.15.6 as the vendor-supported floor, go above 1.16.0 for a floor no published record contradicts, and note which source your remediation ticket relied on.

Is a read-only API key safe for a RAG application?

Not by itself, because "read-only" describes what the key does to the data, not which endpoints it reaches. Qdrant's advisory for CVE-2026-25628 says minimal privileges, specifically read-only access, are sufficient to reach a flaw it rates as remote code execution, and the vendor notes the affected endpoint had an authentication check but no authorization check. CISA describes KEV entry CVE-2026-42271 for LiteLLM the same way, as allowing any authenticated user, including holders of low-privilege internal-user keys, to run arbitrary commands on the host. Enforce the constraint at the network layer by allowlisting the specific paths your application calls rather than trusting the product's role model alone.

Is LangChain vulnerable to remote code execution?

CVE-2025-68664 is not a remote code execution vulnerability and its advisory never uses that phrase. It is a serialization injection issue in langchain-core, classified CWE-502, whose advisory describes extraction of environment variable secrets during deserialization and instantiation of classes within trusted namespaces with attacker-controlled parameters, which can trigger side effects such as network calls or file operations. Both published vectors show confidentiality high, integrity low and availability none, scored 9.3 by the CNA and 8.2 by NVD. Floor langchain-core at 0.3.81 or 1.2.5, then rotate any secret that lived in the affected process environment, because patching does not rotate credentials that may already have been read.

Can a FAISS index file contain malicious code?

A serialized index is an artifact that executes at load time in the process that loads it, not inert data that is merely read. IBM's advisory for CVE-2026-3357 states that IBM Langflow Desktop 1.6.0 through 1.8.2 could allow an authenticated user to execute arbitrary code because of an insecure default setting permitting deserialization of untrusted data in the FAISS component, classified CWE-502. That advisory lists no patched version, so the mitigation is to change the insecure default and control where index files come from rather than to upgrade. Treat shared or downloaded index files like binaries: allowlist their origins, hash or sign them, verify at load, and fail closed.

Is Langflow safe to expose to the internet?

The published record argues strongly against it. As of CISA KEV catalog version 2026.08.07 there are six Langflow entries in the catalog of known exploited vulnerabilities, spanning missing authentication, code injection, origin validation and an insecure direct object reference, and the oldest of them, CVE-2025-3248, is flagged for known ransomware campaign use. The three most recent were added with three-day remediation deadlines. Keep it behind authentication you control, off the public internet, and tracked in your inventory under both "Langflow" and "IBM," because the catalog files newer entries under the latter.

How do you penetration test a RAG pipeline?

Test it as an application, not as infrastructure. Exercise the vector store's full HTTP surface using the exact credential the application tier uses in production rather than an administrative one, test object-level authorization across every identifier the orchestration layer accepts including flow, collection, namespace and tenant identifiers, treat the AI gateway as a credential-holding system and test role enforcement on its administrative functions, and review every deserialization path reachable from user-influenced input including index loading. Verify version floors against both the vendor advisory and NVD, and record the divergences rather than resolving them silently.

What should be in scope when testing an AI application?

At minimum: the application tier, the orchestration framework and any AI gateway or proxy, the vector store's complete API surface, the ingestion and retrieval paths, the index and model artifact supply chain from build to load, and the identity and key-scoping model connecting them. Scope components by what they can reach rather than by which team owns them, because the 2026 record shows the exploited layer is usually the orchestration tier nobody filed under "application." Include object-level authorization testing explicitly, since insecure direct object references like Langflow's CVE-2026-55255 produce well-formed requests and valid responses that signature-based scanning does not detect.

References

• Qdrant, security advisory GHSA-f632-vm87-2m2f: https://github.com/qdrant/qdrant/security/advisories/GHSA-f632-vm87-2m2f

• GitHub Advisory Database mirror of GHSA-f632-vm87-2m2f: https://github.com/advisories/GHSA-f632-vm87-2m2f

• NVD, CVE-2026-25628: https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-25628

• GitHub Advisory Database, GHSA-c67j-w6g6-q2cm (LangChain, CVE-2025-68664): https://github.com/advisories/GHSA-c67j-w6g6-q2cm

• NVD, CVE-2025-68664: https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2025-68664

• GitHub Advisory Database, GHSA-g2wf-gm3w-w9x3 (IBM Langflow, CVE-2026-3357): https://github.com/advisories/GHSA-g2wf-gm3w-w9x3

• NVD, CVE-2026-3357: https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-3357

• Langflow, security advisory GHSA-vwmf-pq79-vjvx (CVE-2026-33017): https://github.com/langflow-ai/langflow/security/advisories/GHSA-vwmf-pq79-vjvx

• CISA, Known Exploited Vulnerabilities catalog, catalogVersion 2026.08.07: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

• NVD, CVE-2026-42271 (LiteLLM): https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-42271

• NVD, CVE-2026-55255 (Langflow): https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-55255

• NVD, CVE-2026-9198 (IBM Langflow): https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-9198

• NVD, CVE-2026-0770 (Langflow): https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-0770

• NVD, CVE-2026-21520 (Microsoft Copilot Studio): https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-21520