Temu looks forward to working with the security community to find vulnerabilities in order to keep our businesses and customers safe.
Response Targets
Temu will make a best effort to meet the following SLAs for hackers participating in our program:
| Type of Response | SLA in business days |
|---|
| First Response | 2 days |
| Time to Triage | 2 days |
| Time to Bounty | 14 days |
| Time to Resolution | depends on severity and complexity |
We’ll try to keep you informed about our progress throughout the process.
Disclosure Policy
- Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.
- Follow HackerOne's disclosure guidelines.
Program Rules
Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
- Social engineering (e.g. phishing, vishing, smishing) is prohibited.
- Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service.
- Ask the program team before submitting vulnerabilities on unscoped subdomains
- Only interact with accounts you own or with explicit permission of the account holder.
Test Plan
- Users are able to sign up for a free account through our website.
- Please use your hacker email alias when testing ([email protected]).
- Claim credentials (when applicable) for additional testing.
Session Layer: HTTP Headers
Researchers should add headers to requests such as:
“X-HackerOne-Research: [H1 username]”
Out of scope vulnerabilities
When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) potential security impact of the bug. The following issues are considered out of scope:
- CRLF
- ==Self-XSS==
- Tabnabbing
- Email Spoofing
- Session fixation
- Content Spoofing
- Account brute force
- Missing cookie flags
- Best practices/issues
- HTML content injection
- Clickjacking/UI redressing
- ==DOM Cross-site Scripting (XSS)==
- ==Reflected Cross-site Scripting (XSS)==
- HTTPS/SSL/TLS Related Issues
- Physical or social engineering attacks
- Issues that require unlikely user interaction
- Login/logout/unauthenticated/low-impact CSRF
- Unverified Results of automated tools or scanners
- No SPF/DMARC/DKIM in non-email domains/subdomains
- Attacks requiring MITM or physical access to a user's device
- Any activity that could lead to the disruption of our service (DoS)
- Vulnerabilities affecting users of outdated browsers or platforms
- Rate limiting or bruteforce issues on non-authentication endpoints
- Error information disclosure that cannot be used to make a direct attack
- Previously known vulnerable libraries without a working Proof of Concept
- Open redirect - unless an additional security impact can be demonstrated
- Comma Separated Values (CSV) injection without demonstrating a vulnerability
- Missing security-related HTTP headers which do not lead directly to a vulnerability
- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
- Public Zero-day vulnerabilities that have had an official disclosure less than 1 month before are on a case by case
- Information leakage that cannot be used to make a direct attack,like server IP, server version, path, error message, internal IP, etc
Out of Scope vulnerabilities for Mobile Apps (Android & iOS)
When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) potential security impact of the bug. The following issues are considered out of scope:
- Hardware attacks
- Path disclosure in the binary
- Absence of certificate pinning
- Lack of obfuscation and binary protection
- Intent or URL Redirection leading to phishing
- User data stored unencrypted on the file system
- Shared links leaked through the system clipboard
- Clickjacking/UI redressing with minimal security impact
- Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries
- Any kind of sensitive data stored in app private directory
- Attacks requiring MITM or physical access to a user's device
- Reports on outdated version/builds of in-scope Mobile Apps
- Vulnerabilities requiring a rooted, jailbroken, or otherwise modified device
- Scenarios requiring excessive user interaction or tricking users like phishing
- Any URIs leaked because a malicious app has permission to view URIs opened
- Vulnerabilities on third-party libraries without showing specific impact to the target application
- App logging (logcat, console logs) sensitive information unless you can provide a proof with a malicious app stealing the data from logs
- Third-party API Keys/Secrets embedded in mobile applications, without a clear impact, as many third- parties require this for their own client attribution purposes
- Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope) and due to malformed URL Schemes
Thank you for helping keep Temu and our users safe!