RuoYi EUVD-2026-97324

Requires a valid authenticated session on the RuoYi management console with at least a low-privileged account (CVSS PR:L) - exploitation is NOT possible unauthenticated. The attacker must reach the /system/role/authDataScope endpoint and supply a manipulated roleKey parameter, which the checkRoleAllowed function does not properly authorize, enabling improper privilege management. Limiting factors: the need for pre-existing authentication, the restriction to low integrity/availability impact (no data exfiltration/confidentiality loss per VC:N), and applicability to RuoYi versions up to and including 4.8.3. Risk rises sharply on instances that permit self-registration or expose low-trust user accounts.

This is a medium-severity (CVSS 4.0 base 5.3) improper privilege management flaw (CWE-269) in the RuoYi framework. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) indicates network-reachable, low-complexity exploitation requiring an already-authenticated low-privileged account, with only low integrity and availability impact (VI:L/VA:L) and NO confidentiality impact (VC:N) - so this is a scoped manipulation of role/data-scope authorization rather than a full account takeover or data breach. Exploitation signals are mixed-but-modest: a public exploit exists (POC=YES, consistent with the E:P 'Proof-of-Concept' exploit-maturity flag in the vector), but this is NOT on the CISA KEV list and there is no evidence of active exploitation in the wild. No EPSS score was provided in the input, so real-world exploitation probability cannot be quantified here. The PR:L requirement meaningfully limits risk: an attacker must first obtain a valid (even low-level) authenticated session, making this an insider/privilege-escalation issue rather than a remote-unauthenticated compromise. Net: a real but not top-tier priority - patch in normal cycles, prioritize if the RuoYi instance exposes self-registration or low-trust user accounts. The vendor did not respond to disclosure, so an official fix/advisory may be absent; verify patch availability independently.

An attacker who holds a low-privileged authenticated account on a RuoYi 4.x admin panel sends a crafted request to /system/role/authDataScope manipulating the roleKey argument, which the checkRoleAllowed function fails to validate correctly. This lets the attacker alter role/data-scope authorization settings they should not control, escalating or tampering with privilege assignments. A public proof-of-concept for this exact parameter abuse is available on GitHub.