ELADMIN (eladmin-mp) EUVD-2026-102904

Requires an authenticated, non-admin ELADMIN (eladmin-mp ≤ 2.7) account whose role has been delegated the roles:edit permission; the attacker calls PUT /api/roles/menu and submits its own role id with an arbitrary list of menu ids. The flaw is present in the default logic because the endpoint authorizes solely by comparing the target role's level to the caller's minimum level, and neither validates the submitted menu set nor forbids a caller from editing its own role. The only meaningful limiting factor is possession of the roles:edit delegated permission - there is no user interaction, no non-default configuration, and no additional authentication step required beyond that.

This is a genuine, exploitable privilege-escalation flaw rather than an inflated high-CVSS score. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8) is internally consistent with the description: a network-reachable, low-complexity, no-user-interaction attack by an already-authenticated low-privileged user, yielding effectively full administrative control (High C/I/A) because the attacker can assign its own role an arbitrary menu set. The one caveat is the PR:L rating: exploitation is not available to any authenticated user but specifically to a user whose role holds the delegated roles:edit permission, so the realistic attacker population is narrower than a plain 'any logged-in user' reading of PR:L implies - this slightly lowers real-world likelihood versus the raw score. No EPSS score, no CISA KEV listing, and no public POC are present in the supplied intelligence, so there is no evidence of active or automated exploitation; risk is currently theoretical-but-credible. The lone 'Information Disclosure' tag understates the issue - the primary impact is privilege escalation via improper access control, and that mislabeling should not be used to downgrade triage. Net: a high-priority fix for any deployment that delegates roles:edit to non-admins, but not an emergency 'exploited-in-the-wild' item on current data.

A low-privileged ELADMIN user who has been delegated the roles:edit permission sends a PUT /api/roles/menu request specifying its own role id together with the full set of admin menu ids. Because the endpoint only compares role levels and never blocks self-modification or validates the granted menus, the user instantly grants its own account administrative menu access and escalates to effective admin. No public exploit code is identified at time of analysis, but the attack requires only a single crafted authenticated HTTP request.