Addressing Security Vulnerabilities

At PingCAP, we place great importance on security-related issues concerning our products. If you discover a security vulnerability while using or testing our products, we encourage you to report it to our security team to help TiDB improve the security of our products and services, thereby providing better security for our users.

Scope of Application

This risk handling standard applies to PingCAP’s core open-source products and publicly available internet applications, including but not limited to: tidbcloud.com, tidb-cloud.com, tidbapi.com, pingcap.com, as well as components directly related to the TiDB product, such as TiKV, TiDB, TiFlash, PD, etc.

Code of Conduct

PingCAP encourages security researchers to actively discover and report security vulnerabilities in our products or services. However, we expect your actions to adhere to the following guidelines:

1. Do not exploit any security vulnerabilities beyond minimal verification;
2. Do not conduct Denial of Service (DoS or DDoS) testing;
3. Do not perform physical testing, proximity attacks, social engineering tests, or any other non-technical vulnerability testing;
4. Avoid accessing any data stored in our information systems. If you discover sensitive data such as user identity information, order details, bank card information, or business data during testing, please cease testing immediately and contact us promptly;
5. Under no circumstances should you disclose any information obtained during vulnerability testing;
6. We strongly oppose and condemn any destructive actions carried out under the guise of vulnerability testing, especially those that exploit security vulnerabilities to harm PingCAP systems and users’ interests. In such cases, we will exercise our right to pursue all available criminal and civil legal remedies.

Vulnerability Submission and Processing Process

Vulnerability Submission

Vulnerability reporters can report vulnerabilities to the TiDB security team via security@pingcap.com. Please provide as much information about the vulnerability as possible in the following format (* indicates required fields):

• Vulnerability Title*:
• Description of Harm*:
• Affected Components and Version Numbers*:
• CVE Number (if available):
• Steps and scripts to reproduce the vulnerability*:
• Contact Information*:
• Fix Recommendations*:

Vulnerability Fix

Once the risk is confirmed, the security team will notify the business department to address the security issue as soon as possible. The fix timeline will depend on the severity and difficulty of resolving the issue.

Vulnerability Rating Standards

Vulnerabilities will be rated based on their severity, divided into five levels: Critical, High, Medium, Low, and Ignored. Each level corresponds to a different base score range.

This rule serves as a reference, and the final score of the vulnerability will be based on factors such as the impact range, actual exploitability, report detail, reporter cooperation during re-testing, and the feasibility of the fix. PingCAP reserves the final interpretation right.

[Critical]

• Direct System Access (Server-side Access): For example, remote command execution, arbitrary code execution, web shell upload, SQL injection to gain system access, buffer overflow, and other vulnerabilities that allow remote access to the system, container, or POD.
• Critical Sensitive Information Disclosure: For example, core DB SQL injection vulnerabilities, unauthorized access to sensitive data such as core DB (funds, user identities, other sensitive user data), leading to mass exposure of sensitive information.
• Denial of Service (DoS) in Core System Services: For example, vulnerabilities that directly cause core API service or TiDB components to be unavailable.
• Critical Logical and Process Defects: For example, arbitrary account login, takeover, batch modification of any account password, arbitrary payment of any amount, and other critical issues.

[High]

• Unauthorized Access to Sensitive Information: For example, bypassing authentication to directly access the management backend to modify a large number of sensitive frontend data or using weak passwords/SSRF to obtain internal cloud-sensitive information.
• Sensitive Information Disclosure: For example, vulnerabilities causing sensitive data leakage through traversal, non-core DB SQL injection, source code leaks, hardcoded keys, passwords, etc.
• Unauthorized Sensitive Operations: For example, unauthorized access to sensitive user information.
• Core Business-Impacting Vulnerabilities: For example, stored XSS vulnerabilities that propagate across important pages or stored XSS that can be exploited to gain administrator credentials.

[Medium]

• Vulnerabilities that Require Interaction to Impact Users: For example, reflected XSS in general business, CSRF in important operations.
• Non-Critical Information Disclosure: Including but not limited to GitHub leaks of non-critical internal TiDB information.
• Minor Unauthorized Operations: Including but not limited to unauthorized queries of tenant IDs, unauthorized queries of cluster IDs, and other non-sensitive function violations.
• Normal Logical Design and Process Defects Leading to Security Risks: Including but not limited to bypassing SMS verification or email verification.

[Low]

• Minor Information Disclosure: Including but not limited to git leaks of non-sensitive information, debug page leakage, server configuration information leaks without potential harm.
• Denial of Service Vulnerabilities: Including but not limited to local DoS vulnerabilities on the server or client caused by issues such as exposed permissions in client-side components.
• Difficult to Exploit but Present Security Risks: Including but not limited to hard-to-exploit SQL injection points, reflected XSS, CSRF in ordinary operations.
• Other Low Impact Vulnerabilities: Including but not limited to non-interactive arbitrary URL redirection.

[Ignored]

• Vulnerabilities that have already been identified by other white-hat hackers or internally by the company.
• Issues based on user assumptions, unverified problems, or meaningless scan reports.
• Social engineering attacks, proximity attacks, physical attacks.
• Lack of HTTP security headers or requirements to enable specific HTTP methods.
• Email SPF configuration issues.
• Brute-force attacks on any API interfaces.
• Website page clickjacking.
• HTML content injection.
• Leaks of robots.txt files.
• Email spoofing.
• Page error messages.
• Errors in Golang or JavaScript functions.
• No rate-limiting on API interfaces.
• Leaks of non-sensitive files.
• DDoS or HTTP flood attacks leading to DoS.
• Server version information disclosure.
• Weak password policies or database hash salting issues.
• SSL/TLS version too low.
• Vulnerabilities in third-party components that cannot be verified or reproduced.

Reward Rules

The final amount of the vulnerability reward will be determined based on the following factors:

• Business Importance: Whether the vulnerability affects core business systems, which are critical to the operation of the overall system or services.
• Severity of the Vulnerability: The severity level of the vulnerability, such as whether it could lead to data leakage or critical logical design flaws.
• Feasibility of the Fix: Whether the submitter provides a clear and actionable fix recommendation that facilitates the prompt resolution of the vulnerability.

We strive to offer rewards in a fair and transparent manner to encourage participation and enhance the security of our products. However, in special cases (e.g., duplicate reports, reports that do not meet validity criteria, or reports that fail to meet reward conditions), we reserve the right to decide whether to issue a reward.

Business Classification

Core Business: tidbcloud.com, tidb-cloud.com, tidbapi.com, and core components related to TiDB products

General Business: Online sites and components other than core products

Reward Details

Disclosure of fixed vulnerabilities

Confidentiality Principle

We greatly appreciate your input concerning any actual or potential security vulnerability. To minimize undesired consequences of premature public disclosure and in accordance with legal requirements, we kindly ask you to observe the following code of conduct:

• The vulnerability will not be disclosed externally or to third parties before TiDB releases a patch: Vulnerability information should not be disclosed before TiDB stakeholders have received the information, completed the vulnerability handling, and before the scheduled disclosure date. The timeline for disclosure may vary depending on the nature of the vulnerability and the required time for resolution, and should be discussed and agreed upon after assessment.
• Do not disclose detailed vulnerability information, such as exploit code, to prevent improper use of the vulnerability information.
• Comply with intellectual property protection laws, regulations, and confidentiality agreements.

Contact Information

If you have any questions regarding this policy, or if you have any disputes during the vulnerability handling process, evaluation, or reward rules, please contact us via email at security@pingcap.com.