Bug Bounty Program

Vulnerability Disclosure: General Information

Thank You for helping to keep VTube Studio safe 😄

VTube Studio is built with user-safety as the central focus. However, various parts of VTube Studio are exposed to the local network and internet, so there is definitely a significant risk of malicious actors trying to break into your PC via potential security vulnerabilities in VTS to steal your personal data or models.

If you are a security researcher and would like to analyze/research VTube Studio, you have full permission. Bug bounties for specific high user-impact exploits are also available (more information below), as long as the responsible disclosure guidelines outlined on this page are followed.

For information about how VNet secures user data, please refer to this: https://github.com/DenchiSoft/VTubeStudio/wiki/VNet-Security

All reports should be sent only to support at denchisoft dot com. To keep the process organized, please do not use any other channels.

Please feel free to report anything you think may be relevant. However, there are specific things I am especially interested in and things I consider irrelevant.

Disclaimer

Redistribution of VTube Studio assets and code (in text form or binary form) is strictly prohibited. This includes offering tools to modify the VTube Studio source code.

Very interested in:

• Anything related to RCE, meaning you are able to execute arbitrary code on a PC running VTS through sending specially crafted packets to it over the network, including:
  • Over the VTS API (authenticated or unauthenticated plugin)
  • Over the VNet Collab System
  • Over the tracking data server
• Being able to steal decrypted models remotely via VNet WITHOUT being invited to the session and/or having the session password.
• Gaining any kind of personal information/data from people in a VNet Collab you are not invited to, just by knowing the Steam IDs of one or more participants.
• Forcing your way into a VNet collab without being invited and/or having the session password.
• Accessing the VTS API with a remote plugin (meaning it's running in the web browser and NOT locally) without authenticating the plugin first.
• Accessing VNet server admin controls.

Moderately interested in:

• Being able to list files on the VNet servers. Those files are encrypted, but attackers still shouldn't be able to just get a list of all of them.
• Being able to "guess" VNet file URLs for collabs you aren't invited to and/or do not have the password.
• Exploits that gain access to the VTube Studio website admin panel.
• Exploits that gain access to VTube Studio social media or Discord/Steam/email accounts.
• Exploits that target the Live2D Cubism Core library, used for loading Live2D models. Please report those directly to Live2D Inc. and remember to get permission from Live2D Inc. first if you plan to analyze their software as it may be prohibited by their EULA.

Not interested in:

• Anything that requires an attacker to already have a process/app running on the target PC. At that point, the system should be considered fully compromised, so any vulnerabilities that require this are not relevant to the security of VTS users.
• Anything related to VNet Collab participants who are invited and have the password being able to dump models. This is documented and users are actively warned that this is possible by using specialized hacking tools. Mitigation would require invasive measures (anticheat/DRM) which I am not willing to implement considering the low risk: VNet is a tool people use with their friends only, there are no public "lobbies".
• Unauthorized uploads to and downloads from the VNet servers. Files are automatically deleted after 24 hours.
• "Denial of service"-type attacks, such as sending a lot of packets via VNet, the tracking data server or the VTS API. I plan to add mitigations for this in the future, but it's not a big concern at the moment.

Please feel free to still report these if you think they are relevant, but I likely won't take any action.

Please exploit your vulnerabilities first before contacting me about them, as long as they do not cause harm to VTube Studio or any 3rd party, on your own systems and with your own model files of course. Do not under any circumstances try to exploit any vulnerabilities on any other VTube Studio users unrelated to you.

Bug Bounties

Bug bounties are available for vulnerabilities that have a high impact on VTS users, particularly those listed under "Very interested in". Bounties of up to $1000 USD are available (depending on the severity) for exploits in this category if a step-by-step walkthrough is provided, including a working Proof of Concept (PoC). Smaller bounties (up to $500 USD) will be paid for vulnerabilities listed under the "Moderately interested in" category.

To be eligible:

• Vulnerabilities must not already be public.
• Reports must include a detailed explanation of the impact and exploitability of the vulnerability.
• PoCs should demonstrate the vulnerability clearly, detailing steps, tools, payloads, and expected vs. actual results.
• Videos showing the process are also welcome.
• Theoretical vulnerabilities or simple crashes do not qualify for bounties. Exploitability must be shown for RCEs.
• Testing must be performed on your own systems and files.

Bounties are awarded on a first-come, first-served basis. The timestamp of the email will determine the first reporter. Subsequent duplicate reports will not be eligible for rewards unless they include significant new information, at which point partial bounties may be awarded at my discretion.

Payments will be processed within 14 days of validating the vulnerability and can be made via PayPal, SEPA, or SWIFT.

Profiting from vulnerabilities in VTube Studio in any way other than bug bounty rewards is strictly prohibited.

How to report vulnerabilities

1. All reports should be sent to support at denchisoft dot com. To ensure a smooth and clear process, please do not contact me about vulnerabilities in any other way.
2. With your initial report email, please send ALL relevant information.
3. After the report has been received, I will address it in reasonable time. Please allow up to 14 days for the first response.
4. As soon as I have read it, I will contact you via email to confirm receipt of the report.
5. Once I have analyzed the provided information and confirmed the validity of the vulnerability, I will contact you again with a detailed schedule for the planned fix. I will then wait for your confirmation.
6. At that point, I will also pay out any potential bug bounties (via PayPal or SWIFT/SEPA).
7. If a bug bounty was paid, the details of the vulnerability will not be disclosed publicly by you, unless you receive written permission to do so. If you received a payment, you may of course publicize this fact, but you will not disclose any details about the nature of the fixed vulnerability. You will of course also receive official credits for the fixed vulnerability in the VTS changelog like this: Fixed vulnerability reported by <YOUR-NAME> that allowed attackers to <WHAT-WAS-POSSIBLE>.
8. If the vulnerability is not eligible for a bug bounty but I still plan to fix it, you may publicize the vulnerability after it has been fixed based on the timeline I provided you. You will of course also receive official credits for the fixed vulnerability in the VTS changelog.
9. If I do not plan to fix the vulnerability, you may disclose it publicly at your own discretion. I will provide a statement explaining my decision and request that it be included at the beginning of your disclosure document.