Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-03T19:17:29.950Z",
  "pubdate": "2026-09-03T19:17:29.950Z",
  "executiveSummary": "R2R versions through 3.6.6 are susceptible to a critical stacked SQL injection vulnerability located within the vector index creation endpoint.\nThe vulnerability arises from improper sanitization of the index name parameter, which is directly interpolated into a database query string.\nThis flaw allows unauthenticated remote attackers to execute arbitrary SQL commands, including both Data Definition Language (DDL) and Data Manipulation Language (DML) operations.\nBecause the application interface executes these queries under the authority of a PostgreSQL superuser, successful exploitation results in full database compromise.\nThe attack vector does not require prior authentication, significantly increasing the risk profile for exposed instances.\nThe potential impact includes unauthorized data exfiltration, modification or deletion of database contents, and potential escalation of privileges within the underlying database server.",
  "technicalDetails": "The vulnerability resides in the vector index creation functionality of R2R, specifically within the logic processing the index name parameter.\nThe root cause is an insecure implementation of query construction where the user-supplied index name is incorporated into a CREATE INDEX statement via standard string formatting instead of using parameterized queries or proper database abstraction identifiers.\nBy failing to implement identifier quoting or a restrictive allowlist for the index name input, the application permits the injection of arbitrary SQL syntax.\nAttackers can leverage this by including semicolon characters (;) to terminate the intended CREATE INDEX statement and initiate new, malicious SQL queries.\nSince the database connection pool operates with PostgreSQL superuser privileges, the injected SQL is executed with maximal system permissions.\nThe attack flow follows a predictable sequence: First, the attacker identifies the vector index creation endpoint. Second, they craft a malicious payload containing a valid index name followed by a delimiter and the target SQL commands (e.g., 'test_index; DROP TABLE users;--'). Third, the backend service receives the payload and interpolates it directly into the raw SQL query string sent to the PostgreSQL backend.\nThe database engine interprets the input as a series of legitimate commands, executing the attacker-controlled statements after the primary index operation.\nThis behavior facilitates arbitrary DML execution, such as modifying or exfiltrating sensitive data, and DDL execution, such as dropping tables or altering database schemas.\nBecause this endpoint is reachable without authentication, the attack surface is exposed to any network entity capable of reaching the R2R service.\nPost-exploitation, an attacker could potentially gain full control over the database, bypass internal security controls, or gain persistence within the infrastructure by manipulating administrative database roles or configurations."
}