Cool Admin Midway EUVD-2026-102505

The attacker must already be authenticated to the cool-admin-midway admin panel as a non-superadmin administrator who has been granted sys:role permissions; with that access they supply an arbitrary (another admin's) role id to /admin/sys/role/info, /admin/sys/role/update, or /admin/sys/role/delete because the base CRUD role endpoints do not verify role ownership. Limiting factors: exploitation is not possible for anonymous or external users - it requires a valid admin session with role-management rights, so the realistic threat is a malicious or compromised low-privilege admin account rather than a remote unauthenticated attacker. Affected: cool-admin-midway through 8.0.0.

This is an authenticated privilege-escalation / IDOR issue (CWE-639), not an internet-facing unauthenticated flaw, so real-world risk is moderate and insider-driven rather than widespread. The input CVSS 4.0 vector scores 7.0 with PR:H, but the description says the attacker only needs 'ordinary sys:role permissions' - a non-superadmin admin - which is better modeled as PR:L; either way exploitation requires a pre-existing admin account with role-management rights, substantially narrowing the threat population. Impact is weighted toward integrity (VI:H - rewriting menu/department grants to change other users' effective access) with lower confidentiality and availability impact. No EPSS score, no CISA KEV listing, and no explicit POC flag were provided in the input, so there is no signal of mass or active exploitation; a public technical write-up exists but does not equal weaponization. Net: a legitimate fix-worthy authorization defect for anyone running cool-admin-midway, but it ranks below internet-exposed pre-auth RCE/KEV items because it presupposes an already-trusted (if lower-privileged) admin session.

A low-privileged administrator who has been granted only sys:role permissions logs into the cool-admin-midway panel and calls /admin/sys/role/info, update, or delete while substituting another administrator's role id. By rewriting that role's menu and department grants, the attacker silently alters other users' effective permissions or deletes their roles. A public technical write-up describing the flaw exists, but no confirmed weaponized exploit code was indicated in the source data.