Kiteworks Core CVE-2026-102141

Exploitation requires two concrete, stacked prerequisites: (1) the attacker must already hold backend ROOT on at least one node of a multi-node Kiteworks Core CLUSTER (single-node deployments are not exposed to the cross-node vector), and (2) a software patch must be PENDING/staged on the target node, which provides the execution trigger for the planted file. The vulnerable surface is two specific cluster-management operations that fail to validate supplied file paths (CWE-73). Limiting factors: local-only access (AV:L, not remotely reachable), high pre-existing privilege (backend root), and the AC:H timing/configuration dependency on a pending patch - meaning this is realistically a lateral-movement primitive for an already-compromised cluster, not an initial-access vulnerability. Fixed in Kiteworks Core 9.5.1.

This is a genuine but heavily gated post-compromise flaw, not a top-of-queue emergency. The CVSS 3.1 vector (AV:L/AC:H/PR:H/UI:N/S:C/C:L/I:H/A:L, 6.7 Medium) makes clear this is local-only (AV:L), requires high privileges (PR:H - backend root on a cluster node), and carries high attack complexity (AC:H) because it depends on a pending software patch being staged on the target node. The scope change (S:C) is the notable element: it crosses a trust boundary to compromise a SEPARATE node in the cluster, which is why integrity is rated I:H. No EPSS score, KEV listing, or public POC is present in the provided data - no public exploit identified at time of analysis. Because the attacker must ALREADY hold root on one node, real-world value is limited to lateral movement / blast-radius expansion inside an already-breached cluster rather than initial access. Note a data-quality conflict: the vendor Tag says 'Information Disclosure,' but the CVSS confidentiality impact is only C:L while integrity is I:H and the mechanism is write-and-execute code on another node - the tag understates and mischaracterizes the actual code-execution/integrity risk.

An attacker who has already achieved backend root on one node of a Kiteworks Core cluster invokes one of the two unvalidated cluster-management operations to write a malicious file, as root, into a path on a second node where a software patch is pending. When that node processes the pending patch, the attacker-planted file is executed as root, giving the attacker code execution on the second node. No public exploit code is identified at time of analysis, and the AC:H rating reflects the required pending-patch precondition on the target.