CVE-2026-82271: R2R Authentication Bypass Vulnerability

CVE-2026-82271 Overview

CVE-2026-82271 is a broken access control vulnerability in R2R (Retrieval-to-Reasoning), an open-source retrieval-augmented generation platform maintained by SciPhi-AI. Versions through 3.6.5 fail to validate user ownership in conversation update and message handlers. Authenticated users can supply arbitrary conversation identifiers to rename other users' conversations and append messages to their conversation histories. The flaw is tracked as CWE-639: Authorization Bypass Through User-Controlled Key and enables cross-tenant state corruption and prompt injection into other users' AI conversations.

Critical Impact
Any authenticated R2R user can modify, rename, or inject content into any other user's conversation history, corrupting downstream retrieval and reasoning workflows.

Affected Products

SciPhi-AI R2R versions up to and including 3.6.5
R2R deployments exposing the v3 conversations_router API endpoints
Multi-tenant R2R installations with more than one authenticated user

Discovery Timeline

2026-08-28 - CVE-2026-82271 published to NVD
2026-08-31 - Last updated in NVD database

Technical Details for CVE-2026-82271

Vulnerability Analysis

R2R exposes a REST API that manages user conversations through the conversations_router.py module in the py/core/main/api/v3/ path. The update and message-append handlers accept a conversation identifier from the request and operate on the referenced record without verifying that the calling user owns the conversation. Because the identifier is user-controlled and no ownership predicate is applied before the mutation, any authenticated caller can act on records belonging to another tenant. The impact is limited to integrity, but that integrity impact is significant: attackers can rename conversations, poison stored context, and inject adversarial content that will be replayed to a victim's language model on subsequent turns.

Root Cause

The root cause is a missing authorization check between authentication and data mutation. The router resolves the conversation by primary key but does not compare the record's owner field against the authenticated principal from the request context. This pattern is the canonical form of CWE-639, where authorization is inferred from possession of an identifier rather than from a validated ownership relationship. See the affected R2R conversations router source and the tracking issue in R2R Issue #2292.

Attack Vector

Exploitation requires only a valid low-privilege R2R account and network access to the API. An attacker enumerates or guesses a target conversation UUID, then issues an authenticated update or message-append request supplying that identifier. The server executes the mutation against the victim's record. Repeated calls allow the attacker to append arbitrary text into the victim's conversation history, which the RAG pipeline may later retrieve as trusted context, effectively enabling stored prompt injection. Refer to the VulnCheck advisory for additional detail.

No public proof-of-concept code is available. The vulnerability manifests in the conversation update and message handlers; see the security advisory linked above for technical details.

Detection Methods for CVE-2026-82271

Indicators of Compromise

Application logs showing conversation PATCH or message POST requests where the authenticated user ID does not match the target conversation's owner ID.
Unexpected renames or new messages in conversations that end users report not having authored.
Bursts of API calls to /v3/conversations/{id} endpoints iterating across sequential or enumerated conversation identifiers.

Detection Strategies

Enable request-level audit logging in R2R and correlate the caller identity with each conversation record's owner field to flag ownership mismatches.
Deploy a reverse-proxy or API gateway rule that inspects mutating routes on conversations_router and rejects requests where the JWT subject does not match the resource owner.
Baseline normal per-user conversation counts and alert on users touching an anomalous number of distinct conversation IDs.

Monitoring Recommendations

Forward R2R application and access logs to a central data lake and retain them for post-incident review of cross-tenant access.
Monitor for lateral movement patterns where a single account modifies conversations belonging to many other accounts within a short window.
Track model outputs for anomalous or off-topic responses that may indicate stored prompt-injection content in retrieved history.

How to Mitigate CVE-2026-82271

Immediate Actions Required

Inventory all R2R deployments and identify any instance running version 3.6.5 or earlier.
Restrict network exposure of the R2R API to trusted clients until a patched release is deployed.
Rotate API keys and revoke suspect sessions if audit logs show cross-tenant conversation access.
Review conversation records for unauthorized renames or injected messages before they are consumed by downstream RAG queries.

Patch Information

At the time of publication, refer to the SciPhi-AI R2R repository and R2R Issue #2292 for fix status and release notes. Upgrade to a version later than 3.6.5 that enforces ownership validation in the conversations_router handlers.

Workarounds

Front the R2R API with a gateway that enforces ownership by matching the authenticated subject to the conversation owner before proxying update and message routes.
Apply a local patch to the update and message handlers in py/core/main/api/v3/conversations_router.py that queries the conversation record and rejects requests when conversation.owner_id does not equal the caller's user ID.
Limit R2R to single-tenant deployments until an official fix is available.

bash

# Example gateway rule (pseudo-config) enforcing ownership check
location ~ ^/v3/conversations/(?<cid>[0-9a-f-]+)(/messages)?$ {
    access_by_lua_block {
        local jwt_sub = ngx.var.http_x_user_id
        local owner   = lookup_conversation_owner(ngx.var.cid)
        if owner ~= jwt_sub then
            return ngx.exit(403)
        end
    }
    proxy_pass http://r2r_backend;
}