Roborock Vulnerability Disclosure Policy

Roborock takes the security of its products and services very seriously. We welcome security researchers, developers and users to report potential security vulnerabilities to us and work with us to strengthen the security of our Products.

This policy applies to the disclosure and handling of security vulnerabilities affecting Roborock's smart hardware products, including robotic vacuum cleaners, wet and dry vacuum cleaners, washer-dryers and robotic lawn mowers, as well as their companion mobile applications, cloud services and related Internet of Things (IoT) systems.

1. Reporting a Vulnerability

1.1 Reporting Channel

This Vulnerability Disclosure Policy applies to any vulnerability you are considering reporting to us (the "Organization"). We recommend that you read this Policy in full before reporting a vulnerability and comply with it at all times.

We value those who take the time and effort to report security vulnerabilities in accordance with this Policy. However, we do not offer monetary rewards for vulnerability disclosures.

If you believe you have found a security vulnerability, please submit your report to us at the following email address:

Security contact email: security@roborock.com

Vulnerability Reporting: https://global.roborock.com/pages/roborock-report-a-vulnerability

You may use the email address above to submit an initial vulnerability report. If your report may contain sensitive technical information, logs, supporting evidence or other material requiring confidential handling, we may, as appropriate, establish a secure communication channel with you.

Initial reports submitted by email or another method will still be received and processed and will not be rejected solely because they were not transmitted through a secure channel.

1.2 Information to Include in Your Report

To help us verify and address the vulnerability promptly, we recommend that your report include the following information:

Vulnerability title (required)
Asset on which the vulnerability can be observed, such as the URL, IP address, product or service name (required)
Vulnerability impact (what could an attacker do?) (required)
Vulnerability description (include a summary, supporting files, and possible mitigations or recommendations) (required)
Steps to reproduce. These steps should constitute a benign, non-destructive proof of concept. This helps ensure that the report can be triaged quickly and accurately. It also reduces the likelihood of duplicate reports and the risk of malicious exploitation of certain vulnerabilities, such as subdomain takeovers. (required)
Your contact details: name (optional) and email address (required)
Weakness classification (e.g. CWE) (optional)
Severity rating (e.g. CVSS v3.0) (optional)

1.3 Researcher Conduct Requirements

When researching and reporting vulnerabilities, you must comply with the following requirements:

Do not violate any applicable law or regulation.
Do not access, obtain or disclose users' personal data.
Do not modify or destroy data in the target systems.
Do not use high-intensity or destructive scanning or testing tools.
Do not conduct denial-of-service attacks or other tests that affect service availability.
Do not disrupt the normal operation of any product or service.

1.4 Good-Faith Research and Safe Harbour

We support good-faith vulnerability reports intended to improve the security of our products and services, and we permit non-malicious security testing conducted within the scope of this Policy and in accordance with its conduct requirements.
As a general matter, we will not pursue legal action against researchers solely for conducting good-faith security research and reporting vulnerabilities in accordance with this Policy, provided that they comply with this Policy, avoid infringing privacy, avoid unnecessarily disrupting our products or services, and report vulnerabilities to us promptly.
This commitment does not apply to intentional damage to systems, disruption of service availability, access to or disclosure of user data, exploitation beyond what is reasonably necessary to validate a vulnerability, or any other conduct that violates applicable law.

2. Vulnerability Handling Process

After receiving a vulnerability report, we will handle it through the following process:

Receipt and acknowledgement: Log the report and confirm that the vulnerability-related information is complete.
Validation and assessment: Our security team technically validates the vulnerability and assesses its validity, scope of impact and risk level.
Remediation planning: Coordinate with the product development team to develop a remediation plan or mitigation measures.
Remediation development and verification: Develop a security patch and perform functional and security verification.
Security update release: Deliver the remediated version to users through over-the-air (OTA) updates, application updates and other means.
Public vulnerability disclosure: After the remediation has been released, disclose information about the vulnerability as appropriate.
Follow-up: Continue to monitor the security status of updated products.

3. Response and Remediation Timelines

3.1 Response Targets

Upon receiving a report, we will acknowledge receipt and begin a preliminary assessment, taking into account the severity of the vulnerability and subject to applicable local legal requirements.
Provided that the reporter has supplied valid contact details, we will acknowledge receipt promptly and, in all cases, no later than seven calendar days after receiving the vulnerability report.
An acknowledgement of receipt means only that we have received the report; it does not mean that technical validation, severity assessment or verification of a remediation has been completed.

3.2 Vulnerability Severity Classification

We use the Common Vulnerability Scoring System (CVSS) v3.1 and adjust it based on the product's actual deployment environment to classify vulnerabilities into four severity levels:

Severity	CVSS Score Range	Typical Scenarios	Remediation Priority
Critical	9.0 - 10.0	Unauthenticated remote compromise resulting in full device control; large-scale exposure of user data	P0 - Emergency remediation
High	7.0 - 8.9	Privilege escalation; exposure of sensitive information; remote control requiring specific preconditions	P1 - High-priority remediation
Medium	4.0 - 6.9	General information disclosure; cross-site scripting (XSS); unauthorised operations under limited conditions	P2 - Scheduled remediation
Low	0.1 - 3.9	Minor information disclosure; security issues with limited user impact; exploitation requiring highly restrictive conditions	P3 - Low-priority remediation

3.3 Target Remediation Timeframes

We prioritize remediation according to vulnerability risk level. Our target remediation timeframes are as follows:

Risk Level	Target Remediation Timeframe
Critical	Within 15 working days
High	Within 30 working days
Medium	Based on complexity and release schedule
Low	Based on complexity and release schedule

Note: The timeframes above are targets. Actual remediation may be affected by objective factors such as technical complexity, product architecture, hardware dependencies, and testing and verification requirements. If exceptional circumstances prevent us from meeting a target timeframe, we will keep you informed of progress promptly.

For Critical vulnerabilities under active exploitation, we will activate our incident response process and make any notifications to regulatory authorities required by applicable law.

3.4 Communications and Updates

During the vulnerability handling process, we will keep you informed of key progress as needed. Once the vulnerability has been remediated, we will notify you and may invite you to verify the effectiveness of the remediation.

You may enquire by email about the status of a vulnerability. We recommend making status enquiries no more than once every 30 days so that our team can focus on remediation.

If there is a material change to the validation outcome, severity, affected scope, remediation plan or disclosure timeline, we will provide additional updates as appropriate.

For Critical vulnerabilities, vulnerabilities under active exploitation, or vulnerabilities that could have a significant impact on users, we may adopt accelerated communication and handling arrangements.

4. Public Vulnerability Disclosure

We follow the principles of Coordinated Vulnerability Disclosure (CVD) and work with the reporter throughout the process, from validation through public disclosure.

4.1 Standard Disclosure Process

Vulnerability submission: The researcher submits a vulnerability report through an official channel.
Acknowledgement of receipt: We continuously monitor our vulnerability intake channels and promptly review and assign received reports.
Vulnerability validation: Reproduce the vulnerability, confirm its validity and assign a severity rating.
Impact assessment: Identify all affected product models and version ranges.
Remediation development: Develop a remediation plan and a security patch.
Verification testing: Verify the effectiveness of the remediation and ensure that it introduces no regressions.
Patch release: Deploy the security update.
Public disclosure: Publish a security advisory and acknowledge the reporter, with their consent.

4.2 Disclosure Timing and Embargo Period

Third-party information sharing: During vulnerability validation, remediation and coordinated disclosure, if a vulnerability involves third-party components, vendors, open-source projects, partners or other external dependencies, we may share with relevant third parties the information necessary for validation, remediation and coordinated disclosure. We may also share necessary information as required by applicable law or regulators, or to coordinate handling with the CVE Program, CERTs/CSIRTs or other relevant security organizations. Unless otherwise required by law or regulation, such sharing will be limited to what is necessary for vulnerability validation, remediation, notification and coordinated disclosure.

Standard embargo period: Vulnerabilities are generally disclosed only after a remediation has been released. The disclosure timing will be agreed based on the severity of the vulnerability and the complexity of remediation.
Accelerated disclosure: We may accelerate disclosure for vulnerabilities known to be exploited in the wild, for which publicly available proof-of-concept (PoC) code exists, or which pose an exceptionally high risk.
Delayed disclosure: If remediation is particularly difficult or the vulnerability has a broad impact, the embargo period may be extended as appropriate in consultation with the reporter.
Coordination: We welcome researchers' suggestions on disclosure timing and will work constructively with them to agree on an appropriate disclosure schedule.

4.3 Publication of Security Advisories

Once remediation is complete, we will publish a security advisory through our official channels (https://global.roborock.com/pages/disclosure). The advisory will include:

Vulnerability description and technical summary
Affected products and versions
Impact assessment
CVE ID (if assigned)
Fixed version and update instructions
Temporary mitigations (if applicable)
Acknowledgement of the reporter (with the reporter's consent)
Initial publication date of the security advisory and dates of subsequent revisions

For vulnerabilities affecting third-party components used in our products, the security advisory will, as appropriate, reference vulnerability information published by the relevant third party or upstream vendor, identify an updated version containing the remediation, or provide sufficient information to help users and other relevant parties determine whether the vulnerability affects a Roborock product.

For vulnerabilities that have been remediated and publicly disclosed, we will also make the relevant information available in a widely recognized machine-readable format, such as the Common Security Advisory Framework (CSAF). If we are unable to provide a machine-readable format for reasonable cause, we will document the rationale in accordance with our internal procedures.

5. Software Security Update Support Policy

5.1 Support Period

Roborock provides software security updates for its products for a period of at least five years from each product's official release date, or for the product's expected service life, whichever is longer.

The end-of-support date for each product model will be published on our official website. Once published, the support period will not be shortened. If it is extended, we will update the relevant list promptly.

5.2 Update Charges

During the security support period, all security updates will be provided to users free of charge, with no additional fees.

5.3 Update Delivery

Security fixes will be delivered through firmware over-the-air (OTA) updates, mobile application updates, cloud service improvements and other means. Users are advised to keep their products updated to the latest version to receive the latest security protections.

5.4 End-of-Support Information

Products that are beyond their security support period may no longer receive security updates. Users are advised to consult the official support list and upgrade promptly to a product model that remains supported.

For particularly critical security risks, we may still provide necessary security fixes based on the circumstances, even after the published support period has ended.

6. Additional Provisions

This Policy is based on applicable cybersecurity laws and regulations and industry practices. We will continue to improve our vulnerability management process in light of regulatory requirements and actual circumstances.

The timeframes stated in this Policy are operational targets and do not constitute a guarantee regarding the outcome or duration of handling any particular vulnerability. We reserve the right to adjust our handling approach as circumstances require.

Thank you for your interest in and support for the security of Roborock products. Your feedback will help us continue to provide users with a safer product experience.