The security and privacy of your data are our utmost concern. Lark abides by rigorous security policies, and implements robust systems to protect user data. We encourage security research individuals as well as teams to test our security, and we offer rewards for valid reported vulnerabilities. As we keep on adding new features, we encourage community researchers to keep working on our projects to find new vulnerabilities.
Response Targets
Lark Technologies will make a best effort to meet the following response targets for hackers participating in our program:
- Time to first response (from report submit) - 1 business days
- Time to triage (from report submit) - 3 business days
- Time to bounty (from triage) - 5 business days
We’ll try to keep you informed about our progress throughout the process.
Disclosure and Confidentiality Policy
Lark Technologies supports public recognition and disclosure of contributions and findings for in-scope reports closed as resolved. We will seek to allow participants to be publicly recognized whenever possible.
- Public disclosure of a vulnerability (either full or partial) is only permitted after the Lark Team receives a Disclosure Request within the HackerOne platform and the Lark Team agrees to disclose the report.
- Retention, copying, or disclosure of Lark information gained as a result of participation is not permitted.
- Lark Technologies may redact any sensitive information prior to disclosure.
If requesting beyond a HackerOne disclosure (e.g. in a blog or at a conference):
- Request approval before commencing a write up.
- Share your final blog edits and where the content is to be hosted with Lark Technologies for approval.
- Do not publicly disclose information until you have explicit written consent to do so from Lark Technologies.
Program Rules
- You must be the first reporter to report the issue to us. We will only reward the first reporter.
- When submitting a vulnerability, please provide us with enough information so that we could reproduce and verify it.
- By submitting a report, you agree that materials will be shared with TikTok USDS Joint Venture LLC for independent triage, audit, verification, and patching based on impact to systems in the United States.
- Please use your own account for testing purposes. Do not gain access to another user's account or their confidential information.
- Please do not test for denial of service, spam, social engineering issues.
- All of the tests must not violate any law, or compromise any data that is not your own.
- Please contact [email protected] to report security incidents such as customer data leakage or breach of infrastructure
- 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.
Testing and Guidance
Signing Up
- You may register up to two test accounts on https://www.larksuite.com/ for free
- You will be required to create a domain name for each account which you will be using to do your testing
Treasure Map and Lark Suite Product Guidance
To better understand the Lark Suite Product and its core functions, please refer to the updated Treasure Map 2.1 we have created: https://bytedance.feishu.cn/docs/doccnlT329U2f6EFPV5Bvqa0f3A#ZWfYX1
Bug Bounty Rewards Assessment
Typical bug bounty rewards range from $100 to $5,000, depending on their severity and asset tier. No upper limits
Rewards Range:
Critical vulnerabilities examples:
- SQL Injection, which could get massive customer information
- Remote code execution on server side
- Remote code execution on client app
- Remote user sensitive information disclosure on client app
- Privilege escalation affecting all users
- Broken authentication affecting all users
- SSRF to lark internal service, with extremely critical impact, such as being able to access internal sensitive data
- And other critical severity issues
High vulnerabilities examples:
- Privilege escalation affection part users
- Broken authentication affection part users
- SSRF to internal services of Lark
- And other high severity issues
Medium vulnerabilities examples:
- Privilege escalation affecting single user
- Broken authentication affecting single user
- XSS which could attack other Lark users
- Logical vulnerabilities affecting sensitive operations
- Remote denial of service or app crash
- Information disclosure of service(with customer data)
- Remote information disclosure on client app, like program memory, log, etc
- Insecure storage of sensitive information on client app
- And other medium severity issues
Low vulnerabilities examples:
- Information leakage(without customer data)
- Server misconfiguration or errors
- Local denial of service or app crash
- Local information disclosure on client app, like program memory, log, etc
- And other low severity issues
Please refer to the rewards section for the bounty table. Our bounty table provides general guidelines, and all final decisions are at the discretion of Lark. We reserve the right to accept and review any security report including for out of scope issues, but we will not award a bounty for out of scope issues in fairness to other researchers who are adhering to program scope. This will be true regardless of the severity of the vulnerability.
Known Issues
- All paid feature bypass issues in Admin Setting Page reported after 11 Apr 2025
- Please note that these known issues will not be eligible for bounties:
- Cross-Site Request Forgery (CSRF)
- Cross-Origin Resource Sharing (CORS)
- Clickjacking
We are working on a fix for the above issues and seek your kind patience.
Out of Scope Vulnerabilities
When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:
- Reports from automated tools or scans
- False positive SQL Injection
- To avoid submitting a false positive, please ensure that you are able to provide a working PoC that demonstrates the ability to retrieve the current database / current user name
- Spam vulnerability, mail spoofing, mail bomb, etc.
- Self-XSS
- Use of known-vulnerable library or component
- Clickjacking on pages with no sensitive actions
- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
- Attacks requiring MITM or physical access to a user's device.
- Previously known vulnerable libraries without a working Proof of Concept.
- Comma Separated Values (CSV) injection without demonstrating a vulnerability.
- Missing best practices in SSL/TLS configuration.
- Any activity that could lead to the disruption of our service (DoS).
- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
- Rate limiting or brute-force issues on non-authentication endpoints
- Missing best practices in Content Security Policy.
- Missing HttpOnly or Secure flags on cookies
- Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
- Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]
- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).
- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.
- Tabnabbing
- Open redirect - unless an additional security impact can be demonstrated
- Issues that require unlikely user interaction
- Vulnerabilities that are already known (e.g. discovered by an internal team)
- Best practice reports are not eligible for bounties but are appreciated.
- Exposure of Google Maps API Key.
Notes about IDOR Vulnerabilities
Researchers must be able to prove a feasible way to gain an ID as an attacker and we will not accept reports where IDs are being brute forced.
- Example: An ID is 19 characters long. To guess this ID, an attacker will have to calculate 10^19 combinations which is not in the range of an online brute force attack. IDOR vulnerabilities with access to unimportant data will also not be eligible for bounty.
Out of Scope bugs for Android apps
- Any URIs leaked because a malicious app has permission to view URIs opened
- Sensitive data in URLs/request bodies when protected by TLS
- Lack of obfuscation and binary protection
- Any kind of sensitive data stored in app private directory
- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment & root permission)
- Shared links leaked through the system clipboard.
- Intent or URL Redirection leading to phishing
- Third party library 0day
Out of Scope bugs for iOS apps
- Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries
- Absence of certificate pinning
- Path disclosure in the binary
- User data stored unencrypted in the app private directory
- Lack of obfuscation is out of scope
- Lack of jailbreak detection is out of scope
- OAuth & app secret hard-coded/recoverable in IPA
- Crashes due to malformed URL Schemes
- Lack of binary protection (anti-debugging) controls
- Snapshot/Pasteboard leakage
- Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)
- Third party library 0day is out of scope
- URL Redirection leading to phishing
Contacting the Lark Technologies Team
If you require any clarifications regarding the scope of the program (eg: potential Lark's user data leaking in one of our third-party vendors) or face specific challenges when testing, you may email the Lark Team at [email protected].
However, please do not escalate questions about the validity or bounties of your existing reports. Such emails will not be responded to and discussions should be done within the report itself. If you are unsure about a potential vulnerability, please submit the report to us and we will assess it accordingly.
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.
