TABLE OF CONTENTS

• Ground Rules & Code of Conduct
• Disclosure Policy
• Safe Harbour
• Response Time
• General Assessment Rules
• Detailed Rules and Reward Scheme
  • Web Vulnerabilities
  • Mobile Vulnerabilities
  • Hardware Vulnerabilities
  • Privacy Vulnerabilities
• Out of scope Vulnerabilities
• FAQ

---

Ground Rules & Code of Conduct

• The security of our products is vital to us, and we constantly strive to guarantee our users' security. Xiaomi hopes to provide solid and comprehensive security protection to our products and services by working closely with individuals, organizations, and companies around the world. To protect the interests of our users, we thank and reward researchers who help us improve security.
• Respect users' privacy - Xiaomi hopes to respect our users’ privacy, and we oppose and condemn the actions of hackers who use vulnerability testing as an excuse, eg: exploiting vulnerabilities to steal user data, editing, copying, or stealing data from related system services through the intrusion into Xiaomi’s services, or maliciously disseminating vulnerabilities which may disclose users' data.
• Cause more good than harm - You should never leave a system or users in a more dangerous state when you find any vulnerabilities. You shall not engage in activities that may degrade, damage, or destroy the information in our systems, or that may impact our users, such as Denial of Service, social engineering, or spam.
• Dispute resolution - When the results of the vulnerability review are disputed, we will handle in accordance with the principle of prioritizing the interests of the reporters, and if necessary, external parties may be invited to jointly decide and introduce CVSS standard.
• Note: This platform is for international white hats. White hats from Mainland China must submit reports to the Xiaomi Security Center via https://sec.xiaomi.com/

---

Disclosure Guidelines

• Please do not disclose or discuss any security vulnerabilities (even resolved vulnerabilities) in Xiaomi products without express consent from Xiaomi, regardless of whether the vulnerability is involved in this bug bounty program.
• Please follow the disclosure guidelines of HackerOne. If you believe you have discovered a security vulnerability, please report it with a thorough explanation of the vulnerability and comply with the format stated in the Eligibility for Bounty section.

---

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

If you have any suggestions for our program, please send us an email at [email protected] to give us feedback. If the suggestions are adopted, Xiaomi will send you a thanks reward.

Thanks for keeping Xiaomi and our users secure and safe!

---

Response Time

Xiaomi will make a best effort to meet the following target response time for the white hats participating in our program:

• Time to first response (from report submission) - 2 business days
• Time to triage (from report submission) - 5 business days
• Time to bounty (from triage) - 7 business days

We’ll try to keep you informed about our progress.

Please do not send spam messages and follow-ups if our response doesn't exceed the target response time above. We appreciate your patience.

---

General Assessment Rules

• Please include as much detailed information as possible in the vulnerability report, such as the steps to reproduce the vulnerability and the expected results of each step. If the information you submit is insufficient to help us verify the vulnerability, you will not be eligible for the reward.
• If you discover a security vulnerability through the use of automated tools or scanners, please perform a manual reproduction and provide relevant details, otherwise, the vulnerability report may be ignored or receive a smaller reward than expected.
• If multiple vulnerability reports are submitted, all caused by the same reason, these reports will only be confirmed as ONE valid submission. For example, vulnerabilities are caused by common server configurations affecting multiple products.
• When duplicate vulnerability reports appear, we will verify them based on the order of submission time, and the first vulnerability report that meets the confirmation requirements will be rewarded.
• For vulnerability reports involving third-party components, we only accept unknown or 0-day vulnerabilities, and only reward the first valid submission.
• For vulnerability reports involving the cooperative manufacturers of Xiaomi, we only confirm the vulnerabilities that affect the products and services of Xiaomi and give reasonable ratings based on the actual situation.
• We set up a "sheriff" service for SSRF testing. If you believe you have found an SSRF vulnerability in our production environment, please test it via https://ssrf.dun.mi.com/ssrf/hacker. Please provide the necessary information when submitting the report based on your testing results as follows -
  • If there is an echo display, a complete page screenshot of the echo display (including text length, and complete/partial echo) shall be provided in the report.
  • If there is no echo display, the content and access time of the custom field shall be provided in the report. We will verify your submitted information.
• For the vulnerabilities related to the data leakage from cloud storage buckets, e.g. S3, KSS, FDS, etc., the following factors will be considered before confirmation -
  • whether the data or link should have access restricted,
  • if yes, the sensitivity of the data or link is exposed to the public.
• The final assessment result of each vulnerability report depends on multiple factors, including but not limited to the severity and risk, the difficulty of being exploited, the scope of impact, and whether there are mitigation measures.
• Xiaomi has the final decision and interpretation rights on the final assessment results, including whether a vulnerability report should be rewarded and the specific amount of the reward

---

Detailed Rules and Bounty Scheme

WEB VULNERABILITIES

Scope & Categorization

• Important businesses: account.xiaomi.com , jr.mi.com, mi.com, xiaomiyoupin.com, mipay.com, miui.com, miwifi.com etc
• General businesses: miliao.com, duokan.com, c.mi.com, game.mi.com, Xiaomi’s entertainment services
• Edge business: such as virtual banking, Xiaomi Chaoshen, financial technology, and other Xiaomi cooperative investment businesses, as well as some third-party businesses, such as imilab.com, zhimi.com, zmifi.com, etc., there are also some operation and maintenance monitoring, test pages, testing environment, and open source systems that lack access rights (according to the name to determine whether the suspected Xiaomi-related business needs internal evaluation to confirm whether it has actual impact on Xiaomi);

Please note that the above list may be updated due to business development at any time.

Bounty Scheme and Examples

Please note that vulnerabilities with low severity will be triaged and receive reputation points accordingly, but will not be eligible for bounties.

Examples of CRITICAL vulnerabilities

• Direct access to core system permissions can directly harm vulnerabilities in the intranet, including but not limited to command execution, remote overflow, and other vulnerabilities;
• Vulnerabilities that can obtain a large amount of Xiaomi user core data or involve trade secret contracts include but are not limited to DB injection of core SQL ;
• Payment-related vulnerabilities include but are not limited to serious logic errors, vulnerabilities that can obtain a large number of benefits and cause losses to companies and users;
• Vulnerabilities that endanger the Xiaomi account system: If there is no interaction, any Xiaomi account login can obtain detailed user information, log in to Xiaomi Cloud to control mobile phones, user payment, and other permissions

Examples of HIGH vulnerabilities

• Vulnerabilities that can obtain sensitive user information, including but not limited to SQL injection from ordinary sites;
• The logical vulnerabilities of individual activities and businesses, such as those that can obtain higher benefits, such as points and red packets;
• Weak password or authentication information bypasses into the background, and there are actual permissions or sensitive information code leaks in the business, which can actually operate an online business and cause greater harm.
• Can SSRF intranet, support a variety of protocols, can detect vulnerabilities in intranet services (SSRF vulnerability verification method see the points for attention in the scoring rules);
• Vulnerabilities in specific scenarios or through some user interaction to log in to individual Xiaomi accounts and have actual user operation permissions;
• Access to sensitive information such as core cookies or storage xss

Examples of MEDIUM vulnerabilities

• General user information disclosure;
• Vulnerabilities that require interaction to affect users, including but not limited to stored XSS, CSRF for important sensitive operations;
• Destructive ultra vires, such as editing, deleting comments, changing function attributes, etc.
• File inclusion, directory traversal, and vulnerabilities that can view some sensitive information;
• Code leaks, vulnerabilities that have sensitive information but have not been successfully exploited;
• Can be SSRF intranet, no echo, or partial echo but failed to obtain information or service permissions vulnerability (SSRF vulnerability verification method see the scoring rules note);
• Vulnerabilities in Github that disclose employee email account passwords, online server account passwords, and other file uploads can only cause phishing, (important business) storage XSS vulnerabilities that are not limited by browser security policies Domxss requires strong interaction, multi-step interaction (two steps or more) to have a greater impact on users;
• The domain name can be hijacked arbitrarily by an attacker

Examples of LOW vulnerabilities

• Vulnerabilities that can obtain user information under certain circumstances, including but not limited to reflective XSS, Csrf , temporary file traversal, Url jump, SMS bombing minor information disclosure;
• Including but not limited to debugging information, Phpinfo, SVN file disclosure, GitHub employee intranet survival test server account password and other machine log files with certain sensitive information;
• Confirmed as a vulnerability, but there are more difficult vulnerabilities;
• Denial of service class attacks caused by application layer defects;

---

MOBILE VULNERABILITIES

Scope & Categorization

• Important businesses: Latest version of Xiaomi mobile apps preinstalled on Xiaomi Mobile Phones, MIUI vulnerabilities

• General businesses: Single-issue apps, non-pre-installed but downloadable Xiaomi mobile apps

• Edge businesses: Special Edition Business APP

• Please note that the above list may be updated due to business development at any time.*

Bounty Scheme and Examples

Examples of CRITICAL vulnerabilities

• Bypass the Secure Boot
• Launch a permanent denial of service attack remotely, causing the device to no longer be usable and requiring flashing and erasing of all data to recover
• Obtain ROOT permissions
• Remote execution of arbitrary code in a privileged process
• Execute arbitrary code in TEE
• Unauthorized access to TEE-protected data (only fingerprints, faces and other data that can cause user property damage are rated as serious)

Examples of HIGH vulnerabilities

• Remotely obtain user-related sensitive information (photos, address books, audio, etc.)
• Remotely execute arbitrary code in order to application processes
• Remote access to protected data (data accessed by privileged processes only)
• Local execution of arbitrary code in privileged applications, TCB, or ICE
• System-level lock screen bypass (needs to test the latest development version and be universally reproducible)
• Launch a permanent denial of service attack locally, causing the device to no longer be usable and requiring flashing and erasing of all data to recover
• Remotely read arbitrary data in the victim APP sandbox
• Remotely turn on or off functions that are usually initiated by users without user interaction, or functions that require user permission before they can be used
• Bypassing device protection functions (e.g. mobile phone retrieval)
• Modify security settings locally without user interaction
• Obtain user-sensitive information locally

Examples of MEDIUM vulnerabilities

• Remotely launch a temporary denial of service attack, which can cause the system to hang or the device to restart *Logic vulnerabilities that can be used to deceive users
• Locally read arbitrary data from the victim APP sandbox
• Bypass APP lock screen bypass
• Locally Obtain sensitive user information (for example: mobile phone number) without permission
• Locally execute arbitrary code in ord application processes
• Locally turn on or off functions that are usually initiated by users without user interaction, or functions that require user permission before they can be used

Examples of LOW vulnerabilities

• Vulnerabilities that require multiple (more than two) user interactions to trigger
• Hijacking vulnerability in APP upgrade function
• Requires physical contact. In some scenarios, information security-related vulnerabilities will only occur with the user cooperation
• Obtain non-user-related sensitive information
• Launch a temporary denial of service attack remotely, causing the application to crash and restart
• Execute arbitrary code in restricted processes through local

Terminology Explanation

Remote: refers to exploiting vulnerabilities to carry out attacks without installing applications or actually touching the device, including web browsing, reading SMS and MMS messages, sending and receiving emails, file downloads, and wireless network communications (excluding short-range communications with a communication distance less than 10 cm) ) and other methods. Local: Refers to exploiting vulnerabilities to carry out attacks that require the installation of applications on the victim system, or require physical contact with the device and short-range communication with a communication distance of less than 10 centimeters. Restricted process: A process that is subject to stricter permission constraints than ordinary application processes, or that runs in a highly restricted SElinux (or SEAndroid) domain. Ordinary application process: refers to an application or process running in the untrusted_app or platform_app domain of SELinux (or SEAndroid), such as a third-party application process or a built-in application process without system-level permissions. Privileged process: refers to applications or processes running in the system_app domain of SELinux (or SEAndroid), including processes running with system-level permissions and processes with root permissions. TCB: TCB is the abbreviation of Trusted Computing Base, which refers to the overall protection device in the computer, including hardware, firmware, software and the combination responsible for executing security policies. It establishes a basic protection environment and provides additional user services required by a trusted computer system, including but not limited to part of the kernel and drivers, or user services equivalent to the kernel, such as init, vold, etc. TEE: TEE is the abbreviation of Trusted Execution Environment, which coexists with the Android system on the device. It is mainly used to provide Android with an operating environment for trusted computing, trusted storage , and other security services. ICE: ICE is the abbreviation of Independent Computing Environment, which refers to a combination of relatively focused functional services and an independent computing unit, firmware program, and simple OS, such as a baseband Modem.

---

HARDWARE VULNERABILITIES

Scope & Categorization

• Xiaomi and Mijia brand hardware & IoT products.
• For hardware & IoT products not using Xiaomi and Mijia brand, please submit the vulnerability by selecting “Other hardware assets”.
• Important businesses: Routers, Cameras, TV,and other intelligent hardware related to user privacy, personal safety, and property security.
• General businesses: Devices that do not store user information and do not pose significant risks to users ,like Smart bulb. etc.

Bounty Scheme and Examples

Examples of Critical vulnerabilities

• Vulnerabilities that could cause significant financial loss to users
• Universal RCE targeting different device models
• Remotely render a device permanently inoperable

Examples of HIGH vulnerabilities

• Non-interactive command execution in LAN environment
• Vulnerabilities that can acquire large amounts of detailed sensitive user information within WAN environment

Examples of MEDIUM vulnerabilities

• Interactive or authorized command execution in LAN environment
• Denial-of-service (not including traffic and performance attacks) in WAN environment

Examples of LOW vulnerabilities

• Insecure Configuration
• Implant malicious code or tamper with firmware into the target device physically but without dismantling the device
• Denial-of-service (not including traffic and performance attacks) impact on the device via LAN

---

PRIVACY VULNERABILITIES

Scope Mobile apps preinstalled on the smartphones of Xiaomi.

** Bounties **

Privacy vulnerabilities refer to violations of laws and regulations related to privacy or data protection in the country or region where the user is located. If it is not fixed in time, it will infringe the user's rights and interests, or cause negative impact or damage to the company's operations or reputation. The severity of a privacy vulnerability will be comprehensively determined based on factors such as the degree of violation of laws and regulations, the degree of damage to user rights and interests, the degree of impact on the company, and the impact scope.

---

Out-of-Scope Vulnerabilities

When reporting vulnerabilities, please always consider the attack scenario and exploitability, as well as the security impact of the vulnerability. For vulnerabilities that are difficult to exploit and have low impact, we may ignore this submission. The following types of issues will not be accepted and are considered beyond the scope of our bug bounty program.

For Web

• Design flaws and best practices that do not lead to security vulnerabilities
• Vulnerabilities that cannot be used to exploit other users or Xiaomi. Eg. Self-XSS/having a user paste JavaScript into the browser console/Unserviceable exposure of third-party API keys with no significant security impact
• Subdomain takeovers - Unable to prove it can be taken over
• Minimal security implications such as logout/Unauthenticated/Low-impact CSRF/Low-impact CRLF/Self-use CSRF /Low-impact clickjacking, low-impact UI redressing/misconfiguration that lead to CORS but without any information leak
• Content Spoofing / Text Injection that cannot be leveraged for XSS or sensitive data disclosure.
• Session not invalidated after logout
• Insensitive disclosure information such as:
  • Error message: Software version/IP
  • Uploaded file cannot be parsed
  • Vulnerabilities that can only be reproduced by certain low-level IE browsers
  • HTTP codes/pages or,other HTTP non- codes/pages etc/insensitive information files
  • Public links, such as social media profile pictures, live videos, etc
• Reflected file download attacks
• SSRF vulnerability that cannot obtain the relevant server information of the Intranet, but simple accessed dns log without any impact
• Misconfigurations such as:
  • DNS issues (i.e. mx records, SPF records, etc.)
  • Reports of insecure SSL/TLS ciphers(unless you have a working proof of concept, and not just a report from a scanner)
  • Presence of autocomplete attribute on web forms
  • Mixed content warnings
  • Missing security-related HTTP headers which do not lead directly to a vulnerability

For Mobile Code security and user data storage

• Absence of certificate pinning
• Sensitive data in URLs/request bodies when protected by TLS
• User data stored unencrypted on external storage (Except for APP logs with sensitive information or user data for which encryption has been promised)
• Lack of obfuscation is out of scope
• OAuth & App secret hard-coded/recoverable in APK
• Any kind of sensitive data protected by the APP private directory
• Lack of binary protection control in android app
• APP setting allowbackup:True

** Local DoS attacks with limited impact**

• Sending malformed intents to the exported component causes the APP to crash only
• Browser crashes due to excessive resource requests
• Local DoS attacks that users can resolve by restarting the browser

Others

• Any data leak because the malicious APP has acquired the appropriate permissions
• Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)
• Spoofing vulnerability with less deceptive
• Attacks that are only available in lower versions of Android

---

FAQ

• Will Xiaomi secretly fix the neglected vulnerability？

Absolutely not! If the ignored vulnerability is later fixed, it is possible that the vulnerability has already been discovered internally and is being fixed, or that the vulnerability no longer appears during the change of the product itself, rather than Xiaomi ignoring the report and fixing it based on the report information.

---