Kiteworks Core CVE-2026-102100

Exploitation requires (1) a valid authenticated account on the target Kiteworks Core instance, even at a low privilege level (PR:L), and (2) a second, typically higher-privileged, user to subsequently view the attacker-supplied content in the web UI (UI:R) - the payload does not fire until the content is rendered. It affects Kiteworks Core before version 9.5.0. The limiting factors are the account requirement (external/anonymous attackers cannot inject directly) and the dependence on a victim viewing the stored content; impact is greatest when that viewer is an administrator, enabling account takeover. Applies to default configurations of the affected Core versions.

The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N = 8.7 High) describes a network-reachable, low-complexity stored XSS that requires a low-privileged authenticated attacker and victim interaction (viewing the content), with a scope change to the victim's browser session. There is no EPSS score, no CISA KEV listing, and no public PoC in the provided data, so exploitation status is 'no public exploit identified at time of analysis' - this is a patch-and-prioritize item, not an emergency. The two constraints that meaningfully lower real-world risk are PR:L (attacker must already hold a valid, if unprivileged, account on the Kiteworks instance) and UI:R (a victim must actually render the malicious content). These are why the score sits at 8.7 rather than the ~9.3 of the unauthenticated Core XSS sibling (CVE-2026-102147). The C:H/I:H rating is justified by the stated account-takeover potential against higher-privileged users; a captured admin session would give the attacker full-tenant confidentiality and integrity impact, though A:N correctly reflects no direct availability effect. No signals conflict here - the vector, description, and CWE-79 are mutually consistent. The one metadata gap: the affected-product tags omit the vendor (kiteworks), which should be corrected for accurate inventory matching.

An attacker with an ordinary low-privileged Kiteworks account submits content (e.g. a file/folder name, comment, or metadata field in Kiteworks Core) containing a stored JavaScript payload. When an administrator or other higher-privileged user later views that content in the web UI, the script executes in their authenticated session and performs actions on their behalf - creating a rogue admin, exfiltrating data, or hijacking the session for full account takeover. No public exploit code is identified at time of analysis, but stored XSS of this kind is straightforward to weaponize once an account is obtained.