By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
PreferencesDenyAccept

Responsible Disclosure Policy

‍

Last Updated: March 13, 2024

‍

At Lark, the security of our systems, and our users’ data, is a top priority. No matter how much effort we put into our security, there might still be vulnerabilities or security issues present. If you discover a security issue in the Lark environment, kindly inform us so we can take corrective actions to address it as quickly as possible. We welcome submissions from security researchers whose reports adhere to the rules set forth in this Policy.  

‍

To contact us with your findings, please fill the following form: Vulnerability Disclosure Form and provide the required details that will allow us to understand, validate and remediate the issue.

‍

We are also active on OpenBugBounty to attract valuable findings: OpenBugBounty.

‍

Lark Bug Bounty Policy 

‍

Only test and submit reports on in-scope services and vulnerabilities. The following are the services, vulnerabilities, and methods that are considered in-scope and out-of-scope.

‍

In-Scope
  • https://www.lark.com- only if vulnerability allows manipulation of access controls or it is a critical web application issue.
  • Lark Health Android App (send an email to security@lark.com to get an account to test the app -- if you live outside of the United States we may not be able to give you a test account).
  • Lark Health iOS App (send an email to security@lark.com to get an account to test the app ‍-- if you live outside of the United States we may not be able to give you a test account).‍
  • https://www.careers.lark.com – only if vulnerability allows write access on site.
  • https://support.lark.com -- see below regarding Zendesk.
Out-of-Scope
  • Vulnerabilities that require access to an already compromised account (unless access to an account exposes other accounts).
  • Policies as opposed to implementations – email verification, password length or reuse, rate limiting, etc.
  • Missing security headers or ‘best practices’ (except if you can demonstrate a vulnerability that makes use of their absence).
  • Vulnerabilities in our open source software (unless you have a proof of concept of how the specific vulnerability can be used on the Lark app).
  • Vulnerabilities in a Lark vendor like Zendesk (unless you have a proof of concept of how the specific vulnerability can be used specifically against Lark).
  • Denial of Service attacks (DoS) or Distributed Denial of Service (DDoS), unless the researcher can demonstrate that the bug is severe enough to disable OTHER sessions and site functionality without many resources.
  • Social engineering attacks.
  • Third-party applications Lark makes use of, but doesn’t control (e.g. a blog or newsletter hosted on an external service).
  • Automated scan reports. (This includes reports from sites like but not limited to SecurityScorecard and SSLTest.)
  • Subdomain takeovers require strong proof of concept. Lark’s Security team will evaluate if the domain has any business value before rewarding the bounty.
  • Brute force attacks, attacks on physical security, social engineering, or spam to gain access to the system are prohibited.
Please adhere to the folliowing guidelines
  1. Provide sufficient information to reproduce the problem. This allows Lark to validate your findings and resolve the issue as quickly as possible. Please submit a proof of concept (PoC) video/screenshot along with the explanation of the issue you found. If a PoC is not submitted, we cannot work on your finding.  Include a URL if appropriate.
  2. Report the vulnerability as quickly as is reasonably possible, to minimize the risk of hostile actors finding it and taking advantage of it.
  3. Don’t reveal the vulnerability or problem to others until it is resolved. We strive to resolve all validated reports within a reasonable timeframe, which we will communicate to you following your submission. To reduce the risk of security exploits, we require researchers to withhold disclosure of submitted vulnerabilities until we confirm that we have resolved the issue.
  4. Comply with our Terms and Conditions at all times. This means, for instance, that you may not introduce viruses, trojans, or backdoors to our system in the course of your research.
  5. Do not utilize a vulnerability further than necessary to establish its existence. Once you have verified the existence of a vulnerability and recorded the proof of concept, please submit a report and refrain from additional testing. Unnecessary repeated access or sharing access is prohibited.
  6. Avoid copying, modifying, downloading, or deleting data on the system, and immediately report any access to personal or confidential information. If you inadvertently download or access personal or confidential information in the course of your research, alert us immediately and do not further disclose the information you obtained. We will ask you to securely delete any copies or screenshots of personal/confidential information after we validate your report. 
  7. Don’t make changes to the Lark systems. If you detect a vulnerability that you suspect would allow unauthorized system changes, please report the vulnerability without actually making the change.
Our commitment to you
  • If you have adhered to this Policy, we will not take any legal action against you in regard to the report.
  • We will handle your report with strict confidentiality, and not pass on your personal details to third parties without your permission.
  • If you are the first person to report a vulnerability in accordance with the rules of this Policy, and we validate the existence of your vulnerability, you are eligible for a minimum of a $100 (paid through a prepaid Visa gift card) payment per evaluated and confirmed vulnerability. 
Additional Guidance

While we welcome any report that conforms to this Policy, reports are most likely to be successful if they focus on areas of most interest to our security team.

‍

Focus Areas:
  • SSRF
  • Any stored XSS
  • Any remote code execution
  • Any local file inclusion
  • Any privilege escalation
  • Any business logic bypass
  • Access control bypass/directory traversal
  • Any finding that has significant business impact  
  • Common misconfigurations on the Lark mobile app
Guidance on Common Findings / Known Issues

The following are an intended design or are in the process of being remediated, so please avoid spending time here as you are more likely to earn a bounty when working on Lark’s Focus Areas listed above.

‍

  • Failure to Invalidate Session > On Password Reset and/or Change  – support.lark.com. Please note, other authorization and session-based vulnerabilities can be valuable.
  • No Rate Limiting on various forms, if you can find other ways to leverage the password reset then you are welcome to submit your finding.
  • Self-Signed Certificates
  • Email HTML Injection
  • Cookie enumeration
  • Missing security headers and similar problems
  • Session token in URL
  • Some information disclosure vulnerabilities (metrics, config, status)

‍

‍