CVE-2026-82526 in R2R
Summary
by MITRE • 09/03/2026
R2R through 3.6.6 contains a stacked SQL injection vulnerability that allows unauthenticated attackers to execute arbitrary SQL statements by manipulating the index name parameter in the vector index creation endpoint. The index name is interpolated directly into a CREATE INDEX statement via string formatting without identifier quoting or allowlist validation, enabling arbitrary DDL and DML execution through semicolon-separated statements under the PostgreSQL superuser account.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified within R2R versions up to 3.6.6 represents a critical stacked SQL injection flaw located in the vector index creation endpoint. This security defect stems from improper neutralization of special elements used in SQL commands, specifically categorized under CWE-74 for Injection Improper Neutralization of Special Elements in SQL Commands and CWE-89 for SQL Injection. The root cause lies in the application's handling of the index name parameter provided by the user during the creation process. Instead of utilizing prepared statements with parameterized queries or implementing strict allowlist validation, the system interpolates this input directly into a CREATE INDEX statement using string formatting techniques. This architectural decision bypasses standard SQL injection defenses that rely on separating code from data, thereby allowing an attacker to inject arbitrary SQL syntax directly into the database engine's execution context.
The operational impact of this vulnerability is severe due to the privilege level under which the application operates. The underlying PostgreSQL instance runs with superuser privileges, meaning there are no restrictive permissions limiting what actions can be performed once a query is executed. Because the injection point allows for semicolon-separated statements, an unauthenticated attacker can execute not only Data Definition Language commands such as CREATE INDEX but also arbitrary Data Manipulation Language operations including SELECT, INSERT, UPDATE, and DELETE on any table within the database. This capability effectively grants full control over the data store, enabling potential data exfiltration, modification of critical application settings, or complete destruction of stored vector embeddings which are central to the R2R functionality. The lack of authentication requirements further exacerbates the risk, as external actors can exploit this flaw without needing valid credentials.
From a tactical perspective, this vulnerability aligns with ATT&CK technique T1059 Command and Scripting Interpreter, specifically SQL commands, allowing attackers to interact directly with the database backend. It also relates to T1190 Exploit Public-Facing Application as it targets an exposed endpoint accessible without prior authentication. The ability to execute arbitrary DDL statements poses a significant risk to system integrity, potentially leading to denial of service through resource exhaustion or schema corruption. Furthermore, the execution of arbitrary queries can facilitate lateral movement if the database server is compromised further, although in this specific context, the primary concern remains the direct compromise of data confidentiality and integrity via SQL injection.
Mitigation strategies must focus on eliminating the root cause by refactoring the code responsible for index creation. Developers should replace string formatting with parameterized queries or prepared statements that ensure user input is treated strictly as data rather than executable code. If dynamic identifiers such as table names are required, they must be validated against a strict allowlist of known safe values before being incorporated into the query structure. Additionally, implementing principle of least privilege for the database account used by the application would significantly reduce impact; running the service under a restricted user with minimal permissions can prevent arbitrary DDL execution even if an injection occurs. Network-level controls such as Web Application Firewalls may offer some detection capability but should not be relied upon as the primary defense given the sophistication of stacked injections. Regular security audits and static code analysis tools configured to detect SQL injection patterns are recommended to identify similar flaws in other parts of the application before deployment.