CVE-2026-55615
Summary
by MITRE • 07/10/2026
Langroid is a framework for building large-language-model-powered applications. Prior to version 0.65.5, Neo4jChatAgent passes LLM-generated Cypher queries straight to the Neo4j driver with no validation, no statement-type allowlist, and no opt-out gate. The query text is influenceable by prompt injection (direct user input or indirect content the agent reads back via RAG), so an attacker who can influence the prompt can read or destroy all graph data and, when APOC or dbms.security procedures are enabled on the server, achieve OS-command and filesystem access. This is the same defect class and threat model as the SQLChatAgent prompt-to-SQL-to-RCE issue fixed in version 0.63.0 (CVE-2026-25879); that fix did not extend to the neo4j module. Version 0.65.5 contains a fix for the neo4j module.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/10/2026
The vulnerability described affects Langroid framework versions prior to 0.65.5, specifically within the Neo4jChatAgent component that interfaces with Neo4j graph databases. This represents a critical security flaw where LLM-generated Cypher queries are executed directly through the Neo4j driver without any validation or sanitization mechanisms. The absence of statement-type allowlists and lack of opt-out gates creates an environment where malicious input can be translated directly into database operations, fundamentally compromising data integrity and system security.
The technical execution path begins with prompt injection capabilities that allow attackers to influence query generation through direct user input or indirect content retrieved via Retrieval-Augmented Generation processes. This vulnerability classifies under CWE-89 as SQL injection but specifically applies to graph database queries where the Cypher language is directly executed without proper validation. The operational impact extends far beyond simple data reading, as attackers can potentially destroy all graph data and when Advanced Procedures On Cypher (APOC) or dbms.security procedures are enabled, achieve full operating system command execution and filesystem access capabilities.
This vulnerability demonstrates a pattern similar to the previously addressed SQLChatAgent prompt-to-SQL-to-RCE issue (CVE-2026-25879) which was fixed in version 0.63.0, but the same remediation approach was not extended to the Neo4j module. The root cause lies in insufficient input validation and query sanitization within the Neo4jChatAgent component, creating a pathway for privilege escalation through database access control bypasses. Attackers can leverage this flaw to perform unauthorized data manipulation, information disclosure, and potentially establish persistent access through OS command execution capabilities.
The fix implemented in version 0.65.5 addresses the core validation gap by introducing proper query sanitization and statement-type allowlisting for Neo4j operations. Security practitioners should immediately update to version 0.65.5 or later to remediate this vulnerability, as the attack surface remains significant even without APOC procedures enabled due to the potential for data destruction and unauthorized access to graph database contents. This vulnerability highlights the importance of validating all dynamically generated database queries regardless of the underlying database technology and demonstrates how prompt injection can translate into severe system compromise when proper safeguards are not implemented.
The threat model aligns with ATT&CK technique T1078 for Valid Accounts and T1566 for Phishing, as attackers would typically need to gain initial access through prompt injection vectors before exploiting this vulnerability to escalate privileges. Organizations using Langroid frameworks with Neo4j integration must ensure all components are updated to prevent exploitation of this persistent vulnerability that could lead to complete system compromise when combined with appropriate database permissions. The remediation approach should also include monitoring for unusual database query patterns and implementing additional network segmentation controls around database access points to limit potential impact even if other mitigation strategies fail.