eladmin CVE-2026-111604

Requires an authenticated eladmin account that holds the user:edit or user:del permission (a delegated department-scoped user manager role); the attacker must also know or enumerate target user ids in other departments. The flaw is in the write handlers of the /api/users PUT and DELETE endpoints, which omit the department data-scope check that read endpoints enforce. Limiting factors: this is NOT remote-unauthenticated - an account with these management permissions is mandatory (PR:H), there is no confidentiality exposure, and impact is confined to account state (disable/reassign/alter/delete) rather than code execution. It affects standard multi-department deployments of eladmin through 2.7 without special configuration.

This is a genuine but moderate-severity access-control flaw (CWE-639, IDOR/broken access control), not a high-urgency emergency. The provided CVSS 4.0 vector (AV:N/AC:L/PR:H/UI:N/VC:N/VI:L/VA:L, base 5.1) and the description agree on the core picture: exploitation requires an authenticated account that already holds user:edit or user:del permissions (a department-scoped user manager), so PR is elevated (PR:H in input, arguably PR:L given the delegated/limited role) and there is NO confidentiality impact - only integrity and availability of user accounts. No EPSS score, no CISA KEV listing, and no public exploit code were provided in the intelligence. The only exploitation-relevant artifact is a hackmd technical writeup and a VulnCheck advisory describing the root cause (write handlers in UserController skip department data-scope checks); these are vulnerability analyses, not weaponized exploits. Signals are internally consistent (no contradictions between vector and description), so the net assessment is a real, patch-worthy insider/privilege-boundary issue for organizations that run eladmin with multiple departments and delegated user managers, but it is low priority relative to unauthenticated RCE-class bugs. Missing data: EPSS and any vendor fix confirmation are absent from the input.

A department-scoped user manager who legitimately holds user:edit/user:del rights sends a crafted PUT or DELETE request to /api/users referencing a target user id belonging to a different department. Because the write handlers never enforce the caller's data scope, the request succeeds, letting the manager disable, reassign, alter, or delete accounts they should not control. No public exploit code was provided; exploitation requires only an authenticated account with those management permissions and a target user id.