Updates

September 2026

• Launch of this new public bug bounty program.

Kiteworks

Kiteworks’ mission is to empower organizations to effectively manage risk in every send, share, receive and save of sensitive content. To this end, we created a platform that delivers content governance, compliance, and protection to customers. The platform unifies, tracks, controls, and secures sensitive content moving within, into, and out of their organization, significantly improving risk management and ensuring regulatory compliance on all sensitive content communications.

Useful Documents/Links

• Documentation on Kiteworks and EPG can be found by clicking on the Question Mark Icon in the Kiteworks UI
• New Features can be found via "What's New" under the Question Mark dropdown
• Documentation on MFT can be found in the MFT UI
• User Roles (useful to view role limits to bypass)
• Basic application usage

Program Rules

We believe that no technology is perfect and that working with skilled security researchers across the globe is crucial in identifying weaknesses in our technology. If you believe you've found a security bug in our service, we are happy to work with you to resolve the issue promptly.

Please note, it is forbidden to perform any of these actions including but not limited to:

• Attempting any type of Denial of Service attacks
• Attempting to interfere with network equipment or Kiteworks infrastructure
• Interfering with any box that is not listed within the program scope
• Decommissioning any boxes
• Changing the IP restriction for admin access
• Changing the IP address/DNS, etc
• Changing the password of other accounts unless it's your own account
• Deleting other user accounts
• Changing the settings for external services like mail, SNMP, proxy, etc - We are mainly focusing on privilege role escalation, RCE possibilities, XSS, LDAP injection, etc.
• Setting the log retention less than 30 days
• Changing the roles of any of the nodes in the cluster

Monitoring of our hunting environments

Please be advised that we monitor all activities on our hunting environments and on the relevant network interface.

Eligibility and Responsible Disclosure

We are happy to thank everyone who submits valid reports which help us improve our security however, only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability (see below)
• Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through yeswehack.com.
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary.
• You must avoid tests that could cause degradation or interruption of our service (refrain from using automated tools, and limit yourself about requests per second).
• You must not leak, manipulate, or destroy any user data.
• You must not be a former or current employee of our company or one of its contractor.

This program is managed by YesWeHack and our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.

No vulnerability disclosure, including partial is allowed.

Kiteworks ecosystem

Kiteworks ecosystem is divided into four logical environments:

1. A Kiteworks Core Node – this includes everything to do with the operation of a single Kiteworks Core node, on a hardened Kiteworks appliance.
2. Email Protection Gateway (EPG) – this includes everything to do with the operation of the EPG solution, on a hardened Kiteworks appliance.
3. Advanced Forms (AF) – this includes everything to do with the operation of Advanced Forms, on a hardened Kiteworks appliance.
4. Managed File Transfer (MFT) - this includes everything to do with the operation of the MFT solution, on a hardened Kiteworks appliance.
5. User Endpoint – this is whatever device the user is on when using any of the above applications.

Instances description

Kiteworks Access

KW Access: https://ywh-kw-public.bounty.kiteworks.dev

Reward Guidelines

We are mostly focusing on HIGH and CRITICAL vulnerabilities.

All of our in-scope assets have an assigned asset value, which defines the bug bounty payout. We apply linear interpolation between the maximum values of the respective severity levels in 0.1 increments.

👑👑👑 Crown Jewels Heist 💰💰💰

For Kiteworks Core, which holds our crown jewels, we offer a $25,000 bonus bounty (on top of the asset reward grid HIGH) for a very specific scenario:

If you report a new, previously unreported vulnerability (or a chain of new vulnerabilities) that allows an unauthenticated attacker (CVSS PR:N) to achieve remote code execution (RCE) as root on the Kiteworks Core appliance, you qualify for this bonus.

Important notes:

• Root access must be achieved on the underlying hardened appliance itself—root access limited to a single container does not qualify
• "Unauthenticated" means the attacker has initially no credentials or user account on the system (CVSS Privileges Required: None)
• "New vulnerability" means not previously reported to or tracked by Kiteworks

Here is the reward grid for such a CRITICAL finding that we will apply:

Important information about vulnerabilities that require admin privileges

In Kiteworks we consider a vulnerability to be critical only if it poses an immediate threat to a significantly large percentage of our customer base. Kiteworks is deployed single-tenant and operated by each customer's own administrators. A corporate administrator already has effective control of the underlying appliance — including legitimate means to reach the host operating system, impersonate users, access content, or take the system down. In that light, vulnerabilities that require administrator privileges (CVSS PR:H) are, by definition, a localized threat and are not classified as critical.

Rather than capping the number by hand — which would break the relationship between the vector and the score — we express this through the CVSS v3.1 Environmental metrics: we set Modified Scope: Unchanged (MS:U), reflecting that an administrator's authority already spans the impacted component, and report the resulting environmental score. We apply this MS:U adjustment to every PR:H finding, not only to those that would otherwise rate as Critical. In practice it lowers the score only where the base vector asserts a scope change (S:C); where the base is already S:U, the score is unaffected. For example, the only PR:H base vector that otherwise reaches Critical, AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H (base 9.1), becomes 7.2 (High) once MS:U is applied.

This does not apply where the admin privileges let you cross into another tenant, a shared multi-tenant service, or otherwise exceed the authority an administrator legitimately holds — in that case the scope change is real, MS:U does not apply, and the finding can remain critical. The same is true if the issue is chained with another vulnerability that provides the required privilege escalation, or where you provide compelling arguments to the contrary.

XSS Reporting Requirements

Please note that for any reports involving Cross-Site Scripting (XSS), a basic proof-of-concept such as a JavaScript alert box (e.g., alert(1)) will not be considered sufficient for triage or reward. To qualify for a valid report, you must demonstrate a clear and actionable impact resulting from the XSS vulnerability. This includes, but is not limited to:

• Performing actions on behalf of another user (e.g., creating a new user account or modifying user settings)
• Exfiltrating sensitive data (e.g., sending authentication cookies or session tokens to an external server)
• Bypassing security controls or escalating privileges

The goal is to understand the real-world risk and exploitability of the issue, so please ensure your report includes a well-documented and impactful demonstration.

Note on the CVSS Scope:Changed

• We do not separate between the Kiteworks Web Application and the Kiteworks Operating System. They are one and the same.

  • To be clear, a vulnerability that allows Remote Code Execution, in and by itself, does not constitute as a Scope Change.
    It could be, however, a pre-requisite in a chain with other vulnerabilities that constitute Scope Change, as described below.

• We do not separate between various permissions level within Kiteworks.

  • To be clear, a vulnerability that allows an attacker to escalate from a regular applicative user to an administrative applicative user – does not constitute as Scope Change
  • To be clear, a vulnerability that allows an attacker to escalate from our regular system account to ‘root’ – does not constitute as Scope Change

• We do separate between different Kiteworks Nodes/Servers.

  • If an attacker successfully attacks one node, and can then utilize that control in order to successfully attack another node in the cluster – this constitutes a Scope Change

• We do separate between different applications inside a cluster based on the asset value

  • We run a growing number of applications on the Kiteworks platform, defined in the YWH asset scopes. While Kiteworks Core holds our crown jewels, some other applications, like Advanced Forms, are of less importance as they do not hold data of the same criticality.
    When you identify a high-impact vulnerability (like RCE) in an asset of higher value, moving laterally to an asset of lower value does not constitute a Scope Change. So in order to achieve a Scope Change, moving to an asset of equal or higher asset value is mandatory. This also implies, that vulnerabilities in Kiteworks Core will not receive a Scope Change for lateral movement to another app as there is nothing of similar value today.

• We do separate between the applications running on the Kiteworks platform and the applications running on users' devices

  • Kiteworks users may use the services of the platform on different devices using the applications we provide for this. The asset value of those applications is considered "very low" – so leveraging a vulnerability of the backend to attack the locally running app would not be considered a Scope Change as, from a Kiteworks perspective, the data on the local device is only a subset of what we have in the backend. However, if a vulnerability in the local app on the user's device can be used to have an impact on the Kiteworks backend, this constitutes a Scope Change.

• We do separate between the various solutions (Kiteworks Core, EPG, MFT) and the user’s device.

  • If an attacker can successfully utilize a Kiteworks solution in order to attack the end user’s environment – this constitutes a Scope Change
  • For example, an XSS attack would very likely be considered a Scope Change. However, because this effectively makes XSS a significant finding, we will require an actual proof of concept of the projected impact, such as the ability to perform arbitrary actions in the system in the name of the user.

Notes on MFT

Infrastructure managers, enterprise architects, and operations managers need a platform they can depend on for secure, reliable back-office file transfers. Tens of thousands per hour, massive files, and tough SLAs. Constant onboarding of new trading partners. Employee turnover. Relentless insider and outsider attacks, and endless compliance audits. You can rely on Kiteworks revolutionary security-first MFT Server. Simply configure your security and governance policies, schedule your forms-based MFT flows, and manage operations with its Web-based console. Get a complete and consolidated picture of the sensitive content shared with customers, suppliers, and partners—where content is going, who is accessing it, and how it is shared—whether via MFT, secure folders, secure email, SFTP, or other channels.

The code that powers MFT, Apache Airflow, is open sourced here.

Notes on EPG

Email protection, control, and tracking that meets the industry’s toughest standards by applying a flexible selection of Email Protection Gateway and automated encryption features. Rest assured that sensitive emails are encrypted per your policies while users simply work as usual, with their standard clients, and without the need for plugins, training, or extra steps. Meanwhile, administrators save time and reduce mistakes with centralized policy controls and automation of key and certificate handling. Finally, execute on strategic risk-reduction requirements, such as keeping content out of the hands of cloud service providers, interfacing with partners’ differing encryption standards, or applying DLP, anti-malware, anti-phishing, and Microsoft RMS and AIP.

Known Issues/Accepted risks

• Bypassing AV or filetype restrictions (by renaming files or changing content type, etc.)
• Listing internal users by ID. Only restricted users and recipient should not be able to send a message to other users. (ID will be replaced by UUID in the next release.)
• For file disclosure, ensure that the file is not marked as "anyone after authentication". To be valid you must be able to bypass "Recipient Only" or accessing a file without being authenticated.