RAGFlow CVE-2026-119337

The attacker must (1) hold a valid, authenticated RAGFlow account or API key (PR:L) and (2) know the target's private agent UUID. The malicious request must use the OpenAI-compatible branch ("openai-compatible": true in the body) and be sessionless (no session_id / id present), because that is the code path that returns via completion_openai before UserCanvasService.accessible() executes; the normal sessionless path and the negative-control request without openai-compatible mode are correctly rejected with code 103. No special victim-side configuration is needed since RAGFlow agents default to 'Only me' permission. Limiting factors that reduce realistic risk: authentication is mandatory (no anonymous access), the agent UUID is a non-sequential identifier that is not readily enumerable, and the affected code is only present in versions 0.25.2 through 0.27.2 (fixed in 0.27.3). Demonstrated impact is unauthorized private-workflow execution and output disclosure; retrieval of private data or tool side effects depends on the victim workflow's configured tools and was not demonstrated.

This is a genuine but conditional priority, not an inflated high-CVSS issue. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, base 7.1 High) correctly reflects that exploitation is network-based, low-complexity, requires no user interaction, but DOES require privileges (PR:L) - i.e. the attacker must hold a valid RAGFlow account or API key. No EPSS score and no SSVC exploitation/automatable/technical-impact fields were provided in the input, so probabilistic and decision-framework signals are MISSING and cannot be weighed. The vulnerability is NOT in CISA KEV (no confirmed active exploitation), but a public PoC reference exists (a YouTube video plus detailed step-by-step Burp reproduction against v0.27.2), so the exploitation primitive is well understood and reproducible. The vuln.today decision label is 'this_week', consistent with a confirmed, documented, authenticated authorization bypass rather than an internet-wide unauthenticated emergency. The principal factor dampening real-world risk is the dual requirement of (a) an authenticated account/API key and (b) knowledge of the victim's private agent UUID, which is a non-sequential identifier that is not trivially enumerable - meaning realistic exploitation leans toward insiders or multi-tenant scenarios where UUIDs leak, rather than mass untargeted attack. One data conflict to flag: the package-feed line states 'not yet patched' while the CVE description, the GHSA advisory, and the v0.27.3 release tag all state the fix shipped in 0.27.3 - treat 0.27.3 as the fixed version and the 'not yet patched' metadata as stale.

An authenticated RAGFlow user (user2) who has learned the UUID of another user's private 'Only me' agent sends POST /api/v1/agents/chat/completions with "openai-compatible": true and the victim's agent_id; because the OpenAI-compatible branch invokes completion_openai and returns before UserCanvasService.accessible() runs, the server executes the victim's private workflow and returns its output (HTTP 200) to the attacker, as demonstrated in the public PoC where the control request is correctly rejected but the openai-compatible request returns the private marker 'CROSS_TENANT_POC_7F31C9'. With AV:N/AC:L the request is a single crafted HTTP call requiring no special timing or interaction, only a valid account/API key and the target UUID.