SciPhi-AI R2R EUVD-2026-67802

The attacker must hold a valid authenticated session on the target R2R instance (PR:L - low-privileged account sufficient, no administrative role required). The attacker must be able to supply or enumerate a conversation identifier belonging to another user; identifiers that are non-sequential or cryptographically random would significantly raise the bar for blind exploitation. The vulnerability is present in the v3 conversations API router and affects the conversation rename (update) and message append handlers specifically. Exploitation is limited by: (1) authentication requirement - unauthenticated parties cannot exploit this; (2) identifier discoverability - if conversation IDs are UUIDs or similarly opaque, enumeration is impractical without an additional information-disclosure path; (3) no confidentiality impact - attackers can write to but cannot read victim conversation content per the CVSS 4.0 VC:N metric.

The CVSS 4.0 score of 7.1 reflects a network-accessible (AV:N), low-complexity (AC:L) flaw requiring low privileges (PR:L) with high integrity impact on the vulnerable system (VI:H) and no confidentiality or availability impact. This characterization is consistent with the described behavior: an authenticated attacker cannot read other users' conversation content (VC:N), but can overwrite or corrupt it (VI:H). The authenticated prerequisite (PR:L) meaningfully limits exposure to users who already have valid accounts on the R2R instance, ruling out unauthenticated mass exploitation. No EPSS data was provided, no CISA KEV listing exists, and no confirmed public exploit code has been reported - all signals point to a real but not immediately weaponized integrity issue. The primary real-world risk is in multi-tenant R2R deployments where untrusted authenticated users share an instance; single-tenant or tightly access-controlled deployments face substantially lower exposure.

An authenticated user logs into a shared R2R deployment and, through prior observation, API enumeration, or guessing sequential/predictable conversation identifiers, obtains the conversation ID of a victim user. The attacker then issues a crafted PATCH or POST request to the conversation update or message append endpoint, substituting the victim's conversation ID - the server processes the request without verifying ownership, renaming the victim's conversation or appending attacker-controlled content to their message history. No confirmed public exploit code exists at time of analysis, but the attack requires only standard authenticated HTTP requests with no special tooling.