Kiteworks Core CVE-2026-102092

Requires an authenticated Kiteworks Core account (PR:L) able to store/share content, plus a victim who previews the attacker-controlled shared content (UI:R) in an authenticated session - the XSS fires specifically in the content-preview rendering path. Affected deployments are Kiteworks Core before 9.5.0. Limiting factors: the attacker must have valid platform credentials, the payload only triggers when another user opens the shared preview, and there is no impact to availability (A:N). It is not remotely exploitable without authentication and is not self-propagating.

This is a moderate-priority, contingent-risk finding rather than an urgent one. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, base 8.7 HIGH) reflects a scope-changing stored XSS where an authenticated attacker plants a payload that runs in a victim's authenticated session on content preview. Two signals temper the raw score: PR:L means the attacker must already hold a valid Kiteworks account, and UI:R means a victim must actually preview the malicious shared content. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so exploitation status is 'no public exploit identified at time of analysis' - there is no evidence of active or automatable exploitation. I assess C:H/I:H as slightly aggressive: the concrete demonstrated impact is session-token theft and account takeover, which is most cleanly modeled as high confidentiality with lower direct integrity, so my independent score is marginally below the vendor's. Net: a credible account-takeover vector on a security-sensitive file-sharing/MFT platform, worth patching promptly, but gated by authentication and victim interaction rather than a wormable unauthenticated bug.

An attacker with a low-privileged Kiteworks Core account uploads or shares a file/comment containing crafted content with an embedded JavaScript payload. When a higher-privileged colleague (or admin) previews that shared content in their authenticated browser session, the script executes in their context, exfiltrating session tokens or performing actions as the victim, enabling account takeover. No public exploit code is identified at time of analysis, and success requires the victim to open the malicious preview.