JeecgBoot CVE-2026-108867

Requires a valid authenticated session on the target JeecgBoot instance - any low-privileged user account suffices (PR:L); the attacker does NOT need the system:user:queryUserRole permission, which is precisely the authorization check that is missing. No special product configuration or non-default deployment mode is required beyond the SystemApiController getUserRoleSetById endpoint being reachable. Limiting factors: exploitation is gated by needing an account (most impactful where self-registration or many low-trust users exist), and impact is confined to disclosure of other users' role codes/administrator identification - no data modification, no direct account takeover.

This is a moderate, information-disclosure-only issue, not a top-tier priority. The CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) consistently describes a low-severity flaw: network-reachable and low-complexity, but requiring an existing low-privileged authenticated account (PR:L) and yielding only low confidentiality impact (VC:L) with no integrity or availability impact. Publicly available exploit code exists (a Python POC published on GitHub and a VulnCheck advisory), which raises practical exploitability, but the CVE is not listed in CISA KEV and no EPSS score was provided in the input, so there is no signal of active or widespread exploitation - treat it as publicly exploitable but not confirmed in-the-wild. The signals are internally consistent (CWE-862 missing authorization aligns with PR:L and the description's 'any authenticated user' framing); there is no network-vs-local contradiction to flag. Realistically this is a reconnaissance/privilege-mapping primitive - it leaks role assignments and identifies administrator accounts, which is valuable as a precursor to targeted credential attacks but does not itself grant access or modify data. Prioritize patching where JeecgBoot exposes self-registration or many low-trust accounts; deprioritize relative to any RCE or write-capable flaw.

A low-privileged user (or attacker who registered or obtained any standard account) sends an authenticated request to the SystemApiController getUserRoleSetById endpoint supplying a userId belonging to another account. Because the handler omits the system:user:queryUserRole permission check, it returns that user's assigned role codes, letting the attacker enumerate accounts and pinpoint administrators to target next. A public Python POC for this exact endpoint is available on GitHub.