| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| -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. |
| An authenticated administrator of Kiteworks Email Protection Gateway could submit a crafted serialized object to a cluster management interface that was deserialized without sufficient validation, potentially allowing arbitrary code execution in the context of the gateway service account. Exploitation requires an administrator account holding a specific queue-management privilege. |
| Improper authentication in a Kiteworks Email Protection Gateway administrative service. An administrative service in Kiteworks Email Protection Gateway did not consistently enforce administrator authentication, so the required password check could be bypassed. An attacker who referenced a valid administrator account could potentially create, modify, or delete internal users and managed domains and change their security-feature configuration without authenticating; deleting a managed domain also removes its user accounts and could lock administrators out of the gateway. |
| Kiteworks Email Protection Gateway before version 9.5.0 is vulnerable to Server-Side Request Forgery (SSRF). A server-side request forgery (SSRF) weakness in Kiteworks Email Protection Gateway could allow a remote, unauthenticated attacker to induce the gateway to issue crafted requests to internal or otherwise unintended network destinations. The requests are triggered while the gateway renders message content that references external resources. Depending on the services reachable from the gateway, this could disclose sensitive internal information or trigger unintended actions on internal systems. |
| A stored cross-site scripting (XSS) weakness in Kiteworks Core could allow an unauthenticated attacker to store crafted content that later executes arbitrary JavaScript in the authenticated session of an administrator who views the affected page. This could have permitted the attacker to gain full administrative control, including the creation of a new administrative account. |
| 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 administrator could initiate an administrative import using a file whose contents were not fully verified, because the import validated only the file's header rather than the complete file. This could allow unverified or forged content to be accepted and processed, affecting the integrity of the imported data. |
| An authenticated administrator on a node with an optional, separately licensed gateway role enabled could supply a connector URL that the server retrieved without sufficient validation of its scheme or destination, causing the server to issue requests to internal network services. Exploitation requires the licensed gateway role to be active. |
| An authenticated administrator could bypass the content validation applied to an administrative file upload and store a file containing dangerous content on the appliance. This did not by itself result in code execution, which would require a separate vulnerability to run the stored file. |
| 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. |
| An optional, separately licensed repository-connector feature in Kiteworks Core did not neutralize special characters in a user-supplied path before passing it to an external command. An authenticated system administrator could inject additional commands and write arbitrary content to files owned by the service account running the connector, enabling code execution in that account's context; exploitation additionally requires network egress from the appliance to a system under the attacker's control. |
| A user-provisioning interface in Kiteworks Core did not verify that the requesting administrator was entitled to grant the role being assigned. An administrator whose delegated permissions covered role changes alone could therefore raise an account to full system-administrator privileges. |
| 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 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. |
| A form-rendering interface in the Advanced Forms component is reachable without authentication so that published forms can be displayed to anonymous visitors, but it returned more data than the form itself required. Anyone who knew the web address of a published form could potentially retrieve the form owner's Kiteworks account profile, including personal details, along with parts of the deployment's configuration settings; no passwords, authentication tokens, or multi-factor secrets were exposed. |
| 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. |
| An endpoint used during initial appliance setup did not require authentication and did not correctly enforce its intended state precondition, so during the initial activation window an unauthenticated network attacker could repeatedly re-trigger the privileged activation process. This could disrupt setup and leave the appliance in an incompletely configured state. The issue is only reachable while an appliance is being activated for the first time and not yet fully configured. |
| A SQL injection vulnerability existed in Kiteworks Secure Data Forms, where a value derived from the authenticated user's stored account data was incorporated into a database query without proper sanitization. An authenticated user could potentially influence that value to inject SQL. Exploitation requires an authenticated session and applies only to deployments where a specific optional feature is in use. |
| Kiteworks Secure Data Forms before version 9.5.0 is vulnerable to Server-Side Request Forgery that could allow an unauthenticated, remote attacker to make the server issue arbitrary outbound network requests and read back the responses. This could potentially be used to reach internal-only services or other network-restricted resources. |
