Summary
Flexible GraphRAG contains a Cypher injection vulnerability in its LangChain FalkorDB graph adapter because attacker-influenced document content can reach dynamically assembled graph queries. Under the affected backend configuration, crafted entity or relationship values may modify or delete graph data and could disclose graph contents when query results are returned to users or language models.
Flexible GraphRAG contains a Cypher injection vulnerability in its LangChain FalkorDB graph adapter because attacker-influenced document content can reach dynamically assembled graph queries. Under the affected backend configuration, crafted entity or relationship values may modify or delete graph data and could disclose graph contents when query results are returned to users or language models.
Affected context
The issue occurs in deployments that use the LangChain graph integration with FalkorDB and ingest content that can influence extracted entities or relationships. It involves query construction in the FalkorDB adapter, including string values and dynamic node or relationship type identifiers that are inserted into Cypher without sufficiently safe parameterization. The LlamaIndex FalkorDB store is outside the described affected context.
The issue occurs in deployments that use the LangChain graph integration with FalkorDB and ingest content that can influence extracted entities or relationships. It involves query construction in the FalkorDB adapter, including string values and dynamic node or relationship type identifiers that are inserted into Cypher without sufficiently safe parameterization. The LlamaIndex FalkorDB store is outside the described affected context.
Exploit preconditions
- Attack surface: Graph document ingestion through the LangChain FalkorDB adapter
- Required access: Ability to submit or influence content processed by the extraction pipeline
- Trigger point: Construction and execution of Cypher queries in
add_graph_documents - Configuration condition:
GRAPH_BACKEND=langchainandGRAPH_DB=falkordb - Why exploitation is possible: Improper escaping can be bypassed when backslashes are processed after quotes, while dynamic identifiers are inserted into query syntax without safe parameterization
- Attack surface: Graph document ingestion through the LangChain FalkorDB adapter
- Required access: Ability to submit or influence content processed by the extraction pipeline
- Trigger point: Construction and execution of Cypher queries in
add_graph_documents - Configuration condition:
GRAPH_BACKEND=langchainandGRAPH_DB=falkordb - Why exploitation is possible: Improper escaping can be bypassed when backslashes are processed after quotes, while dynamic identifiers are inserted into query syntax without safe parameterization
Why this happens
The vulnerability results from incorrect neutralization of special characters before attacker-influenced values are interpolated into Cypher statements. The _escape() helper processes quotes before backslashes, allowing an inserted escape character to alter the meaning of a subsequently escaped quote and terminate a string early. Dynamic node and relationship type identifiers are also placed into backtick-quoted query positions without a sufficiently constrained representation. This behavior maps primarily to CWE-943: Improper Neutralization of Special Elements in Data Query Logic, with CWE-116: Improper Encoding or Escaping of Output describing the flawed escaping pattern.
The vulnerability results from incorrect neutralization of special characters before attacker-influenced values are interpolated into Cypher statements. The _escape() helper processes quotes before backslashes, allowing an inserted escape character to alter the meaning of a subsequently escaped quote and terminate a string early. Dynamic node and relationship type identifiers are also placed into backtick-quoted query positions without a sufficiently constrained representation. This behavior maps primarily to CWE-943: Improper Neutralization of Special Elements in Data Query Logic, with CWE-116: Improper Encoding or Escaping of Output describing the flawed escaping pattern.
Potential impact
- Attackers may modify graph nodes, relationships, or stored properties
- Attackers could delete graph data or disrupt retrieval workflows
- Graph data may be disclosed if query results are surfaced to users or language models
- Downstream retrieval and generation responses may be influenced through graph manipulation
- Applications may experience integrity, availability, or confidentiality impacts
- Attackers may modify graph nodes, relationships, or stored properties
- Attackers could delete graph data or disrupt retrieval workflows
- Graph data may be disclosed if query results are surfaced to users or language models
- Downstream retrieval and generation responses may be influenced through graph manipulation
- Applications may experience integrity, availability, or confidentiality impacts
General mitigation guidance
Mitigation generally focuses on removing string-based query construction for untrusted values and reducing the trust placed in extracted graph content.
Defensive patterns include:
- Use parameterized Cypher for all values derived from documents, models, or external requests
- Treat node and relationship type identifiers as controlled data selected from an allowlist rather than interpolated input
- Apply dedicated, context-aware escaping only where parameterization is not supported, and test escaping order and edge cases
- Validate extracted entities and relationships against strict schemas before query construction
- Restrict graph database permissions so ingestion components cannot perform unnecessary destructive operations
- Separate write and read capabilities and avoid exposing raw query results to untrusted callers or model prompts
- Add regression tests covering escape characters, quotes, delimiters, and unexpected identifier values
Mitigation generally focuses on removing string-based query construction for untrusted values and reducing the trust placed in extracted graph content.
Defensive patterns include:
- Use parameterized Cypher for all values derived from documents, models, or external requests
- Treat node and relationship type identifiers as controlled data selected from an allowlist rather than interpolated input
- Apply dedicated, context-aware escaping only where parameterization is not supported, and test escaping order and edge cases
- Validate extracted entities and relationships against strict schemas before query construction
- Restrict graph database permissions so ingestion components cannot perform unnecessary destructive operations
- Separate write and read capabilities and avoid exposing raw query results to untrusted callers or model prompts
- Add regression tests covering escape characters, quotes, delimiters, and unexpected identifier values
How teams detect issues like this
Useful detection approaches include:
- Static analysis rules for string interpolation, concatenation, or formatting used to assemble Cypher queries
- Searches for graph-query APIs receiving values derived from document text or model output
- Code review checks for custom escaping routines and dynamic identifiers placed in backtick- or quote-delimited query positions
- Tests that verify parameters remain separate from query text and that unsupported identifiers are rejected
- Runtime monitoring for unexpected schema changes, destructive graph operations, or anomalous query patterns
- Policy enforcement requiring parameterized database queries and allowlisted schema identifiers
Automated security review tools can help identify likely injection sinks, but findings should be validated against actual data flow and query execution behavior.
Useful detection approaches include:
- Static analysis rules for string interpolation, concatenation, or formatting used to assemble Cypher queries
- Searches for graph-query APIs receiving values derived from document text or model output
- Code review checks for custom escaping routines and dynamic identifiers placed in backtick- or quote-delimited query positions
- Tests that verify parameters remain separate from query text and that unsupported identifiers are rejected
- Runtime monitoring for unexpected schema changes, destructive graph operations, or anomalous query patterns
- Policy enforcement requiring parameterized database queries and allowlisted schema identifiers
Automated security review tools can help identify likely injection sinks, but findings should be validated against actual data flow and query execution behavior.
