ruoyi-ai CVE-2026-108112

Requires a valid authenticated ruoyi-ai account at any privilege level (PR:L) - exploitation is not possible unauthenticated. No special configuration or non-default feature is needed: the flaw is in the default code path because WorkflowService.softDelete() omits the PrivilegeUtil.checkAndGetByUuid() ownership check on the POST /workflow/del/{uuid} endpoint. The attacker must first obtain target workflow UUIDs, which the GET /workflow/search endpoint readily exposes. Limiting factors: only meaningful on multi-user/multi-tenant deployments (a single-user instance has nothing to cross-delete), requires an authenticated session, and impact is confined to deletion of workflow objects (integrity/availability) with no data disclosure.

This is a moderate-severity broken-access-control issue (CWE-862) best treated as a medium priority rather than an urgent one. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation requiring only low-privilege authentication (PR:L), with no user interaction - consistent with the description of any authenticated user deleting other users' workflows. Impact is deliberately scoped low (VC:N/VI:L/VA:L): no confidentiality loss, only partial integrity/availability damage to other tenants' workflow data, which is why the base score is 5.3 rather than critical. Publicly available exploit code exists (a HackMD writeup and VulnCheck advisory), raising practical exploitability, but the CVE is NOT in CISA KEV and no EPSS score was provided, so there is no evidence of active or widespread exploitation - the POC signal and the (absent) active-exploitation signal must not be conflated. Net: a credible, easy-to-abuse authorization gap against authenticated multi-user deployments, but bounded impact and no confidentiality exposure keep it below top-tier urgency.

A legitimate but malicious (or compromised) low-privilege user of a shared ruoyi-ai instance calls GET /workflow/search to enumerate other users' workflow UUIDs, then sends POST /workflow/del/{uuid} for each. Because softDelete() never invokes PrivilegeUtil.checkAndGetByUuid(), the server deletes workflows the attacker does not own. A public proof-of-concept exists, and the low attack complexity (AC:L, no UI) makes mass deletion trivial to script.