Flexible GraphRAG EUVD-2026-108207

Exploitable only when the application runs GRAPH_BACKEND=langchain together with GRAPH_DB=falkordb; the LlamaIndex FalkorDB store is explicitly not affected, and other backends are not in scope. The attacker must get a crafted document ingested into the GraphRAG pipeline and must steer the extraction LLM into producing an entity/relationship id (or node/relationship type) value containing a Cypher payload, which the backwards-ordered _escape() helper then fails to neutralize (it escapes quotes before backslashes, doubling the inserted backslash so the quote terminates the string). Data disclosure specifically requires that the calling code surfaces query results back to the user or LLM; data modification and full-graph deletion do not. Limiting factors that lower real-world risk: the non-default backend configuration, the need for a user/pipeline to actually ingest the attacker's document (UI:R), and the inherent unreliability of indirect prompt injection reliably emitting the exact payload (AC:H). Workaround before upgrading, per the vendor: switch to GRAPH_BACKEND=llamaindex with FalkorDB or use another graph database; the complete fix is upgrading to 0.8.2.

Signals are moderately consistent and point to a real but conditional priority rather than an emergency. The NVD CVSS 3.1 vector (7.1, AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H) treats this as network-reachable but gated by high attack complexity, some privilege, and required user interaction, whereas the GHSA advisory proposes a far higher ~9.0 score using AC:L/PR:N/UI:N - these two scorings conflict materially on complexity, privilege, and interaction, and the NVD vector is the better fit because exploitation depends on steering an LLM extraction step and on a non-default backend configuration. No EPSS score and no KEV listing were provided, so there is no evidence of widespread or active in-the-wild exploitation; absence of EPSS also prevents a probabilistic exploitation estimate. However, exploitation is not merely theoretical: the GHSA contains an executed string-reconstruction PoC and the maintainer explicitly confirmed a working full-graph deletion against a live FalkorDB instance (with a 'WITH 1 AS x' clause added). Technical impact is total (graph data modification, deletion via DETACH DELETE, and disclosure when results are surfaced), but 'automatable' is weak because the chain relies on indirect prompt injection reliably producing a specific payload. The vuln.today decision label 'this_week' aligns with this picture - a confirmed-exploitable, high-impact flaw in a niche product that warrants prompt patching but is not a mass-exploitation emergency.

An attacker plants a document whose text steers the GraphRAG extraction model into emitting an entity id or relationship value containing a Cypher payload (e.g. a trailing quote plus 'WITH 1 AS x MATCH (m) DETACH DELETE m'); when that document is ingested, the broken _escape() helper fails to neutralize the quote and the payload executes as live Cypher. A maintainer-confirmed PoC used this to delete every node in the graph against a live FalkorDB instance; the same primitive can tamper with or exfiltrate graph data when query results are surfaced to the user or LLM. The chain requires getting a document ingested (UI:R) and the non-default GRAPH_BACKEND=langchain plus GRAPH_DB=falkordb configuration, consistent with AC:H.