CVE-2026-102107 in Kiteworks
Summary
by MITRE • 10/01/2026
Kiteworks Core contains a business logic flaw in a Kiteworks file-request feature allowed an authenticated user to send a request that appeared to originate from another user, because the server did not verify that the requester was authorized to act as the specified account. This could be used to solicit files or information from a recipient under a trusted identity; exploitation requires the feature to be enabled for the attacker's profile and the targeted recipient to act on the request.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/01/2026
The vulnerability identified in Kiteworks Core represents a critical failure in server-side business logic validation, specifically within the file-request functionality. This flaw allows an authenticated user to manipulate requests such that they appear to originate from a different, potentially privileged or trusted account. The root cause lies in the absence of rigorous authorization checks on the backend when processing these requests. Instead of verifying that the currently logged-in session holder has explicit permission to act on behalf of the specified target identity, the system blindly accepts and processes the provided sender information. This lack of ownership verification creates a significant trust boundary violation, enabling an attacker to impersonate other users within the organization without needing their credentials or multi-factor authentication tokens.
From a technical perspective, this issue aligns with CWE-284 Improper Access Control, as it involves a failure to enforce proper authorization policies for user actions. The vulnerability is further contextualized by MITRE ATT&CK technique T1098.003 Account Manipulation: Additional Email Accounts or T1556 Modifying Authentication Process, depending on the specific impact of the impersonation. By exploiting this flaw, an attacker can bypass standard identity verification mechanisms inherent in secure file-sharing platforms. The exploitation does not require complex buffer overflows or memory corruption; rather, it relies entirely on manipulating HTTP request parameters to inject a false sender ID into the business logic flow. This simplicity makes the vulnerability particularly dangerous as it is easily exploitable by automated tools and requires minimal technical sophistication beyond basic understanding of web application interactions.
The operational impact of this vulnerability is severe due to its potential for social engineering attacks within an enterprise environment. Since Kiteworks is often used for sensitive data exchange, the ability to send file requests under a trusted identity can lead to significant confidentiality breaches. An attacker could pose as a CEO, HR representative, or IT administrator to solicit confidential documents from employees who are conditioned to trust internal communications. If the targeted recipient acts on the request by uploading files or sharing information, the attacker gains access to proprietary data without detection through traditional authentication logs. The integrity of the audit trail is also compromised because the system records the impersonated identity as the actor, making forensic analysis and attribution difficult unless deep packet inspection or advanced behavioral analytics are employed.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Administrators should immediately disable the file-request feature for all users if it is not strictly necessary for business operations, thereby removing the attack vector entirely. If the feature remains enabled, strict role-based access controls (RBAC) must be implemented to ensure that only specific roles can initiate such requests. Furthermore, developers must enforce server-side validation of request ownership by cross-referencing the session token with any sender identity provided in the payload. Implementing multi-factor authentication for high-risk actions and adding explicit confirmation steps where users are warned when a file is being sent from an impersonated account can also reduce risk. Regular security audits focusing on business logic flaws, rather than just technical vulnerabilities, are essential to prevent similar issues in future updates.