Kiteworks Core EUVD-2026-90312

Two explicit conditions from the description gate exploitation: (1) the file-request feature must be enabled for the attacker's own profile, and (2) the targeted recipient must actively act on (respond to) the spoofed request - this is the UI:R requirement. The attacker must also hold a valid authenticated account on the Kiteworks Core instance (PR:L). There is no code execution, no memory corruption, and no availability impact; the flaw only lets the attacker misrepresent the originating identity of a file-request to solicit files/information under a trusted name. These limiting factors - authenticated attacker, feature-enabled profile, and required victim action - substantially reduce real-world risk below what the network attack vector alone suggests.

This is a genuinely low-priority issue despite being remotely reachable. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N = 4.6 Medium) is well-calibrated and I agree with it: exploitation requires an authenticated attacker (PR:L), depends on victim interaction (UI:R - the recipient must act on the spoofed request), and yields only low confidentiality/integrity impact with no availability effect. This is a CWE-639 authorization/business-logic flaw (identity spoofing), not a memory-corruption or code-execution bug. There is no EPSS score, no CISA KEV listing, and no public POC identified at time of analysis, so there is no signal of active or automated exploitation - this reads as a targeted social-engineering enabler rather than a mass-exploitable vulnerability. No SSVC decision data was provided. The main caveat: the 'Authentication Bypass' tag overstates the flaw - nothing here bypasses authentication; the attacker is already authenticated and merely spoofs which authorized identity a file-request appears to come from. Net: real but low.

An authenticated Kiteworks user with the file-request feature enabled crafts a file-request that the server renders as originating from a different (trusted) colleague, because it never verifies the requester is authorized to act as that account. A targeted recipient, trusting the apparent sender, uploads sensitive files or information in response to the attacker. No public exploit code has been identified; success depends on the victim acting on the deceptive request.