youlai-boot CVE-2026-110215

Requires an authenticated session on the youlai-boot application - any low-privileged role suffices, explicitly including the built-in GUEST test account present in default/demo deployments. The specific prerequisite is reachability of the PUT /api/v1/roles/{roleId}/menus endpoint, which performs the role-to-menu/button permission assignment without an authorization (CWE-862) check, allowing a user to modify permissions of their own role. Exploitation is LIMITED by the need for valid credentials (no unauthenticated path) and by whether the deployment exposes open registration or leaves default test accounts enabled; instances that disable the GUEST/demo accounts and restrict account provisioning substantially reduce exposure.

This is a credible, non-theoretical priority within its deployment niche, though not a mass-exploitation threat. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H, score 8.7 High) is internally consistent with the description: a network-reachable endpoint, low attack complexity, and only low privileges required to achieve full confidentiality, integrity, and availability compromise through privilege escalation to administrator-equivalent access. No EPSS score was provided in the input, so exploitation probability cannot be quantified. This CVE is NOT listed in CISA KEV and no public exploit (POC) flag is present, so exploitation status is 'no public exploit identified at time of analysis' - although a VulnCheck advisory and a HackMD technical write-up describe the mechanism in detail, which lowers the barrier to independent exploit development. The signals are consistent rather than conflicting: the one caveat is that PR:L requires the attacker to already hold a valid (even if minimal) account, so this is an insider/post-authentication escalation rather than a remote-unauthenticated breach; its real-world severity is therefore gated by how exposed the application's account registration or default test accounts are.

An attacker logs in with any low-privileged account - for example the built-in GUEST test account shipped in demo deployments - and issues a single PUT request to /api/v1/roles/{roleId}/menus targeting their own role, assigning the full set of menu and button permissions. Because the endpoint omits an authorization check, the grant succeeds and the Redis permission cache is refreshed, instantly elevating the attacker to administrator-equivalent access. No public exploit code is identified, but a VulnCheck advisory and HackMD write-up document the exact request and endpoint.