RAGFlow EUVD-2026-91117

The specific precondition is that the externally reachable trace_mindmap path accepts a caller-supplied object or tenant identifier and performs its data-access operation without enforcing any owner, tenant, workspace, or membership binding; an attacker simply substitutes another tenant's/object's identifier to read data they should not access. Exploitation is limited by the need for network reachability to the RAGFlow 0.24.0 instance and, realistically for a multi-tenant IDOR, likely a valid low-privileged account to reach the endpoint - though the supplied vector claims PR:N (unauthenticated), which conflicts with typical multi-tenant design and should be confirmed. The flaw is tied to the specific vulnerable version (0.24.0) and the trace_mindmap feature being deployed/enabled.

Signals conflict sharply and must be weighed together. The input CVSS is 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), which paints a worst-case remote-unauthenticated full-compromise picture. However, the description characterizes a CWE-284 incorrect-access-control / IDOR flaw in the trace_mindmap path - a missing owner/tenant/membership binding on a data-access operation - which is fundamentally a data-exposure issue, so the I:H and A:H impacts in the supplied vector appear overstated for what is essentially unauthorized read access. EPSS is only 0.14% (3rd percentile), indicating very low modeled exploitation probability, and the CVE is NOT on CISA KEV, so there is no evidence of active exploitation. A public gist (Ro1ME) is referenced and likely contains proof-of-concept/write-up details, meaning exploit information is probably public even though it is not weaponized or actively used. No SSVC decision data (exploitation/automatable/technical-impact) was provided in the input, so that framework cannot be applied. CONFLICT TO VERIFY: the vector asserts PR:N (unauthenticated), yet a cross-tenant IDOR in a multi-tenant application typically requires a valid low-privileged session to reach the endpoint before pivoting to other tenants' identifiers - authentication requirements should be confirmed with the vendor. Net assessment: this is a genuine, easy-to-exploit authorization flaw if an instance is exposed, but given the niche product footprint, very low EPSS, and absence of KEV, it is a moderate real-world priority rather than an emergency - treat it as a prompt-patch item, not a drop-everything incident.

An attacker able to reach a RAGFlow 0.24.0 instance sends a request to the trace_mindmap path while supplying another tenant's or object's identifier; because the endpoint performs the data-access operation without verifying that the caller owns or belongs to that tenant/workspace, the server returns data belonging to other tenants. A public gist referencing the issue suggests proof-of-concept details are available, lowering the effort required to reproduce it.