RuoYi-Vue-Plus EUVD-2026-114063

The attacker must possess a valid authenticated account that holds the system:user:list permission and whose role is department-restricted (data-scope limited); they then call GET /system/user/list/dept/{deptId} supplying any department id. The root cause is that SysUserServiceImpl.selectUserListByDept queried via userMapper.lambda().voList() without applying the data-scope filter. Limiting factors: exploitation requires authenticated access with that specific permission (so it is not remote-unauthenticated), the disclosure is read-only and confined to user metadata (usernames, nicknames, account status, last login IP and time, remarks) with no write capability, and it affects deployments on versions through 6.0.0 before the vendor patch.

This is a CVSS 4.0 5.3 (Medium) IDOR / data-scope bypass (CWE-639). The vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N confirms network reachability and low attack complexity, but PR:L means the attacker must already hold an authenticated account carrying the system:user:list permission under a department-restricted role - this is an insider/over-broad-account abuse case, not an anonymous internet-facing exploit. Impact is confidentiality-only and limited (VC:L): disclosure of usernames, nicknames, account status, last-login IP and time, and remarks for users outside the attacker's permitted department; there is no integrity or availability impact (VI:N/VA:N) and no scope change (SC/SI/SA:N). The vuln.today Decision label is 'this_month' rather than act_now/emergency, consistent with the moderate score. No EPSS score and no CISA KEV entry were provided in the input, so widespread or automated exploitation is not evidenced; absence of these is not proof of safety but, combined with the authentication requirement and limited data exposure, this reads as a genuine but moderate-priority access-control defect rather than a high-urgency flaw. A vendor patch exists (commit a8b1bea), and the fix is small - the service was changed from an unfiltered userMapper.lambda().voList() to userMapper.selectUserList(...build()), which reintroduces the data-scope-aware query. EPSS and KEV data are the main missing signals.

A low-privileged operator whose role restricts them to a single department, but who holds the system:user:list permission, iterates department IDs against GET /system/user/list/dept/{deptId}. Because selectUserListByDept applied no data-scope filter, each request returns the user roster of an arbitrary department, letting the attacker harvest usernames, account status, and last-login IP/time across the whole organization. A public PoC reference (hackmd writeup) describes the technique; it is not verified as working exploit code.