R2R CVE-2026-82526

Exploitation requires the R2R vector index creation endpoint to be network-reachable by the attacker; no authentication, user interaction, or non-default feature toggle is required per the CVSS vector (PR:N/UI:N/AT:N) and description. The concrete prerequisite is that R2R (version ≤3.6.6) is deployed with its API accessible to the attacker and backed by PostgreSQL, where the database connection uses a superuser account - the superuser context is what elevates the injection from limited SQL to arbitrary DDL/DML. The primary limiting factor is exposure: instances bound to localhost or behind authenticated network controls are not reachable unauthenticated, and running PostgreSQL under a non-superuser role would constrain (though not eliminate) impact.

This is a genuine high-priority issue rather than an inflated high-CVSS score. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H) describes network-reachable, low-complexity, unauthenticated exploitation with high impact to confidentiality, integrity and availability of the vulnerable system, and all of these align with the description: no auth is required and the injection runs as PostgreSQL superuser. The presence of public exploit code (GitHub issue #2308) and a VulnCheck advisory raises exploitability materially, and any operator running R2R with its API exposed - even a small or mid-sized team - should treat patching or restricting access as urgent. EPSS was not provided and the CVE is not listed in CISA KEV, so there is no confirmation of active exploitation; the realistic risk is driven by public PoC availability plus trivial exploitation, not by observed in-the-wild attacks. The main factor limiting blast radius is exposure: R2R deployments that keep the API bound to localhost or behind authenticated network controls are far less reachable than internet-exposed instances.

An attacker locates an internet-exposed R2R instance and sends an unauthenticated request to the vector index creation endpoint with an index name containing a stacked payload such as a valid name followed by a semicolon and additional SQL. The injected statements execute as the PostgreSQL superuser, letting the attacker read or destroy all stored documents and embeddings, create rogue database objects, or pivot toward wider system compromise. Public PoC in GitHub issue #2308 makes this low-effort to reproduce.