Program Rules

Maintaining effective security is a community effort, and we are proud to have a vibrant group of independent security researchers who volunteer their time to help us spot potential issues. To recognize their efforts and the important role they play in keeping X safe for everyone, we offer a bounty for reporting certain qualifying security vulnerabilities. Please make sure you review the following program rules before you report a vulnerability. By participating in this program, you agree to be bound by these rules.

Rewards

• X may, at its sole discretion, provide rewards to eligible reporters of qualifying vulnerabilities.
• Issue severity is calculated by an internal 5x5 risk matrix based on X-specific data and use cases. Severity is considered a combination of Impact and Likelihood, each assigned a value of Informative, Low, Medium, High, or Critical.
• Payouts are determined by a panel of security experts

Legal

Fine Print

You must comply with all applicable laws in connection with your participation in this program. You are also responsible for any applicable taxes associated with any reward you receive.

We may modify the terms of this program or terminate this program at any time. We won’t apply any changes we make to these program terms retroactively.

SLA

X will make a best effort to abide by the following timelines:

• First Response: 2 business days
• Time to Triage: 10 business days
• Time to Bounty: 14 business days
• Time to Resolution: depends on severity and complexity

Rules of Engagement

When researching security issues, especially those which may compromise the privacy of others, you must use test accounts in order to respect our users’ privacy. Accessing private information of other users, performing actions that may negatively affect X users (e.g., spam, denial of service), or sending reports from automated tools without verifying them will immediately disqualify the report and may result in additional steps being taken.

Report Eligibility

General

• You must be the first reporter of the vulnerability
• The vulnerability must demonstrate security impact to a site or application in scope (see below)
• You must not have compromised the privacy of our users or otherwise violated the X Rules
• You must not have publicly disclosed the vulnerability prior to the report being closed, in compliance with the process described in the HackerOne Vulnerability Disclosure Guidelines
• We must not be legally prohibited from rewarding you

Open-Source Recommendation Algorithm

Reports for the open-source recommendation algorithm have additional requirements:

• In most cases, a working proof of concept is required for report acceptance.
• If a proof of concept is not provided, nor sufficient supporting documentation for X engineers to feasibly recreate and evaluate the issue, the report may not be accepted.
• Report quality for acceptance will be at the discretion of X's HackerOne program.

AI

• Model issues are out of scope for this program and should be reported through [email protected]

Ineligible Issues

The following issues are outside the scope of our vulnerability rewards program (either ineligible or false positives):

• Attacks requiring physical access to a user's device
• Any physical attacks against X property or data centers
• Forms missing CSRF tokens (we require evidence of actual CSRF vulnerability)
• Logout CSRF
• Password and account recovery policies, such as reset link expiration or password complexity
• Invalid or missing SPF (Sender Policy Framework) records
• Content spoofing / text injection
• Issues related to software or protocols not under X control
• Reports of spam (see here for more info)
• Bypass of URL malware detection
• Vulnerabilities only affecting users of outdated or unpatched browsers and platforms
• Social engineering of X staff or contractors
• Issues without clearly identified security impact, such as clickjacking on a static website, missing security headers, or descriptive error messages
• Issues that result in Denial of Service (DoS) to X's servers at the network or application layer.
• Cache poisoning techniques that impact service availability for other users.
• Reports of broken hyperlinks from X blog posts, press releases, or support articles to unclaimed X Handles or to a location where it is not possible to cause the controlled contents to be downloaded to the victim’s filesystem.
• Issues relating to unlocking client-side features in modified X applications, rooted devices, or jailbroken devices.
• Open redirects unless they can demonstrate a higher security risk than phishing.
• Manipulation of "likes/follows/views" count due to caching issues. We are already aware that some statistics on our site may temporarily display inaccurate figures when many requests are sent in a brief period of time. However, that is because the numbers are cached, and the cache may take a bit of time to synchronize with the accurate backend data store.
• Homoglyph attacks in URLs that can lead to phishing scenarios, unless the finding can demonstrate larger issues on our platform (e.g AuthN/AuthZ bypass)
• Reports that demonstrate bypassing rate limits on Grok or xAI APIs.

####The following are common reports that are not security concerns:

• Documents in the Ads Transparency Center do not disclose private account information. We intentionally disclose the advertising status of accounts to better inform our users of ads being run our platform.

Report Disclosures

We currently don't disclose reports marked as Informative. Exceptional reports may be considered for disclosure on a case-by-case basis.