Kiteworks Core EUVD-2026-90375

Requires an authenticated administrative session on Kiteworks Core before 9.5.0 whose role specifically includes limited (non-Sysadmin) role-management/user-role-assignment permissions - this delegated-admin capability is the exact prerequisite named in the description. The flaw is that the role-assignment function does not enforce restrictions tying a grantor to the privileges they are themselves authorized to confer, allowing escalation of a target account to full Sysadmin. Limiting factors: no unauthenticated path (PR:H - attacker must already hold or compromise a delegated admin account), no user interaction, and exposure depends on how many delegated/junior administrators exist and how tightly their role scopes are managed in the deployment.

This is a genuine but access-gated integrity risk rather than a broadly exploitable emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, 7.2 HIGH) is internally consistent with the description: exploitation requires an already-authenticated administrative user (PR:H) who holds limited, non-Sysadmin role-management permissions - so this is a privilege boundary bypass by an existing insider/compromised delegated-admin account, not an unauthenticated remote attacker. No EPSS score, no CISA KEV listing, and no public POC are provided, so exploitation status is: no public exploit identified at time of analysis; there is no evidence of active or automated exploitation. The high C/I/A impact is realistic because the end state is full system-administrator control of the platform, but it is reached only after clearing the PR:H prerequisite, which sharply limits the realistic attacker population. No key signals conflict; the main caveat is the absence of exploitability telemetry (EPSS/KEV/POC all unavailable), so prioritization should rest on the trust model of who currently holds delegated role-management rights rather than on exploitation-probability data.

A delegated Kiteworks administrator whose account is limited to restricted role-management duties (and who should not be able to grant Sysadmin) - or an attacker who has phished/compromised such an account - issues a role-assignment request that the backend fails to validate against the actor's own authorization scope. The request promotes a chosen user account to full system-administrator, handing the attacker complete control of the platform through that elevated account. No public exploit code is identified, and the action requires an existing authenticated admin session (PR:H).