Kiteworks Email Protection Gateway did not sufficiently restrict which account a certificate could be assigned to. This could allow an attacker to associate a certificate with another user's account, affecting the confidentiality and integrity of that account's encrypted mail and, where certificate-based login is enabled, potentially permitting unauthorized access to the account.
A function in the Kiteworks Advanced Forms component was reachable without authentication. An unauthenticated attacker could potentially use it to carry out a limited set of internal service operations on the Kiteworks platform; it did not permit access to user accounts, stored files, or form submissions.
An unauthenticated attacker could cause a file with attacker-controlled content to be written to the appliance filesystem through an administrative upload handler that did not properly authenticate the request. This did not by itself result in code execution, which would require a separate vulnerability to place the file in an executable location.
An authenticated administrator could cause the server to issue requests to, and interact with, internal network services that are not meant to be reachable through this interface. On its own this did not result in code execution.
An authenticated Email Protection Gateway administrator holding only limited, delegated permissions could write files with attacker-controlled content to arbitrary locations accessible to the Email Protection Gateway service account. This exceeds the administrator's intended privileges and could be used to alter application files and configuration or to disrupt the availability of the service.
Kiteworks Core did not apply its gateway-level API security controls to every request authenticated through the platform's central authentication service. An authenticated user could reach REST API functionality over a request path on which those controls, including enforcement of signed-out and revoked sessions, were not applied.
On a Kiteworks Email Protection Gateway cluster with database replication enabled, a party trusted by the cluster could submit a crafted serialized object that was deserialized without sufficient validation, potentially allowing code execution as the gateway service account. Replication is disabled by default, and exploitation requires control of a trusted cluster peer or administrative access to the appliance.
An authorization check in the large file exchange feature of Kiteworks Email Protection Gateway did not correctly establish that the requesting user was a party to the package being requested. An authenticated user of that optional feature could read the subject, message body, and attachments of packages they neither sent nor received.
Two Kiteworks Core cluster-management operations did not validate file paths supplied to them, so an attacker holding root on one node of a cluster could write files as root onto another node and cause them to be executed there. Exploitation requires backend root access on a cluster node and a pending software patch present on the target node.
In multi-node deployments, an attacker who had already obtained code execution on one appliance node could submit a value through an internal cluster interface that was written into monitoring configuration on another node without sufficient validation, potentially allowing OS commands to be executed there. Execution was limited to an unprivileged service account on that node.