Kiteworks did not correctly enforce which roles a shared folder's manager was permitted to assign. In a default configuration, an authenticated user holding the Manager role on a folder could grant the Owner role to themselves or to other members of that folder.
A Kiteworks appliance setup interface did not confine a user-supplied file path to its intended directory, which could allow an unauthenticated attacker to write a file to any location writable by the affected service account, potentially compromising the integrity of the appliance or rendering it unavailable until an operator intervenes. Exploitation requires network access to the affected interface, which is not reachable on a fully configured appliance in its default configuration; reaching it depends on either the transient window while an appliance is first being provisioned or a non-default appliance configuration.
A Kiteworks appliance setup interface did not enforce authentication once the appliance had completed initial configuration. An unauthenticated attacker with network access to the appliance could read and modify a limited set of setup records, including a contact name and email address captured during initial configuration.
The sandbox that isolates document conversion on a Kiteworks appliance did not fully confine the code running inside it. Code already executing within that sandbox could potentially escape its confinement and act with the privileges of the service account that runs the application, which could allow an attacker in that position to read or modify application data and configuration, or to disrupt the service on the affected appliance.
A stored cross-site scripting (XSS) weakness in Kiteworks Core could allow an administrator holding only a single, narrowly scoped delegated permission to store crafted content that later executes arbitrary JavaScript in the authenticated session of a System Administrator who views the affected page. This could have permitted the lower-privileged administrator to escalate to full administrative control of the tenant, including the creation of a new administrative account.
Kiteworks Core did not correctly validate a parameter submitted to the password reset workflow. An unauthenticated attacker who knew the email address of a user with a locally stored password could potentially reset that account's password without access to the emailed reset link and then authenticate as that user, including where the account holds administrative privileges.
-A weakness could have allowed an authenticated Kiteworks Email Protection Gateway administrator to write a file outside its intended location and cause the application to execute it, potentially resulting in remote code execution as the underlying service account.
A local privilege escalation vulnerability in Kiteworks could have allowed an attacker with an existing shell under a low-privileged service account to escalate to root privileges on the appliance.
On deployments where the remote-support capability is licensed and enabled, an authenticated System Administrator who also possessed the key protecting the submitted data could redirect the underlying system's outbound support connection to a destination of their choosing. That destination could then have operating-system commands executed on the node and receive their output, potentially resulting in remote code execution with the privileges of a local service account.
A path traversal weakness in an optional, non-default administrative feature allowed an authenticated administrator to move files to unintended locations outside the feature's designated directory. This could potentially be leveraged to execute arbitrary code on the underlying system.