LaunchDarkly Managed Bug Bounty Engagement

Description

LaunchDarkly is the runtime control platform for releases, AI behavior, and customer experiences in real time with no redeploys required. As the pioneer of feature management, LaunchDarkly introduced a new way for engineering teams to separate code deployment from feature release, allowing organizations to innovate faster while reducing risk in production. Ratings/Rewards Our rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). However, it is important to note that in some cases a vulnerability priority will be modified due to its likelihood or impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher - along with the opportunity to appeal, and make a case for a higher priority.

Targets

Testing is only authorized on the targets listed as in scope. Any domain/property of LaunchDarkly not listed in the targets section is out of scope. This includes any/all subdomains not listed above. If you happen to identify a security vulnerability on a target that is not in scope, but it demonstrably belongs to LaunchDarkly, you can report it here. However, be aware that it is ineligible for rewards or points-based compensation. Engagement Guidelines We do not accept reports that contain low-effort or AI-generated content. Submissions must demonstrate original analysis, clear understanding of the issue, and actionable detail. Reports lacking meaningful human input will be rejected All accounts must be created using your @bugcrowdninja email address, or otherwise include the substring bugcrowd (eg, [email protected] is permissible) Submissions related to SSRF vulnerabilities, including webhook-based SSRF attacks, must include proof that the target endpoint was reached along with the associated metadata Potential post-exploitation scenarios: If you believe you've identified a vulnerability that may lead to post-exploitation activity including modification or destruction of data please stop testing and submit your finding. We will work with you to evaluate the vulnerability and award you accordingly for the final impact and severity You are testing on production. Behavior that compromises the stability and integrity of the target(s) is out of scope. For example, do not target other users' data (use one of your other sets of credentials), delete/remove/edit parts of the site, engage any sort of DoS attack, and/or compromise any target's ability to function for other users. If you believe that you have found a vulnerability of this nature, please stop further testing and report it Report Guidelines Vulnerabilities discovered on multiple paths, endpoints, parameters will be treated as duplicates. This includes findings across different environments (e.g., development, staging, production) unless the impact or exploitation method is materially different. Please submit only one report Reports must contain the role used for testing, a clear explanation of the issue and the security impact along with detailed steps to reproduce it. If the issue cannot be reliably reproduced based on your report, it may be considered ineligible for a reward Do not submit more than one vulnerability per report. In cases where demonstrating impact requires chaining multiple vulnerabilities together, those can be included in the same report as long as the linkage is clearly explained Access All targets within scope are publicly accessible. Credentials To gain access to the application, please sign up for an account using your @bugcrowdninja.com email address. For more info regarding @bugcrowdninja email addresses, see here . Focus Areas To support your testing, we’ve highlighted several key areas of interest. While we ask that you report any efforts related to these areas, please note that testing is not limited to them. Submissions outside of these focus areas are equally welcomed and appreciated. app.launchdarkly.com Improper authentication/access control User privilege escalation to perform actions not defined in role XSS/SSRF in user input fields Additionally, we'd like to call special attention to the following application components that we recently released for general availability: Custom Contexts: We've recently updated the platform's user model to support customer-defined contexts (e.g. users, devices, business units, organizations) for flag targeting. While this change in the underlying model should generally be a 1 for 1 replacement (i.e., users -> custom contexts), we'd be interested to see if the new infrastructure, UI components, etc. created to support custom contexts are susceptible to any web application vulnerabilities or business logic errors. For more details, see the following docs: Introduction to contexts Best practices for upgrading users to contexts Experimentation: In 2022 we launched a refresh our experimentation offering which allows customers to use feature flags in conjunction with events tracking to evaluate how feature flags affect key performance metrics. We'd be interested in any potential vulnerabilities or logic errors that arise from creating and running experiments within the platform. app.launchdarkly.com/api/v2/ Unauthenticated/unauthorized access to APIs APIs returning unexpected data (e.g. data from different accounts/environments, data the user role should not have access to, etc.) Handler logic errors that cause unexpected/undefined behavior LaunchDarkly SDKs Our SDKs are open source and are available on Github (e.g. React client SDK). We encourage researchers to dig into the open source code if interested. N-day/Third party 0-day Policy When N-Day bugs are released to the public and can be exploited within our target(s), please let us know immediately. Each report will be reviewed on a case by case basis Leaked Credentials LaunchDarkly credentials that have been leaked are only eligible if : Customer credentials that were leaked through some action or inaction of LaunchDarkly (ie, a customer checking their own API token into Github would not be eligible) They are not meant to be made public (the browser SDK operates using a token that is intended to be embedded in publicly-exposed source code) Tokens belonging to LaunchDarkly-controlled accounts, that have the "bountyEligible": true value in the /api/v2/caller-identity response. This excludes testing accounts, and other accounts with no valuable data stream.launchdarkly.com Generally, we're looking for ways that attackers could exploit our flag evaluation logic to improperly retrieve flag information meant for other users. Client-side SDKs are specifically meant to prevent attackers from accessing things such as flag evaluation rules due to the untrusted nature of client devices, so any improper handling/exposure of this data may be considered noteworthy. events.launchdarkly.com We'd be interested in ways that attackers may want to exploit our event recording mechanisms. docs.launchdarkly.com The site is mostly static, but there are user input fields (e.g. search bar) that we'd want to ensure are not vulnerable to any XSS or other injection vulnerablities. The site also makes cross-origin requests to app.launchdarkly.com, so any potential CSRF vulnerabilities would be noteworthy. Known Issue Please note that the following issues are considered known risks and will not be eligible for bounties: Rate limiting on account verification and forgot password pages Excluded Submission Types Support team interfaces, such as chat bots, forms, or other methods which generate emails, tickets, or notifications for the LaunchDarkly support teams. There are real people on the other end, and junk requests are a drain on their resources. Third party integrations and endpoints LaunchDarkly provides a handful of third party integrations for use by customers. While these aren't considered in scope today, we are working on refining our testing methodologies for these integrations and plan on making these available for testing in our program in the future. Availability/volumetric testing e.g.: DoS/DDoS/Network DoS Rate limiting bypass attempts Email bombing or flooding ALL forms of social Engineering 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 specific to the LaunchDarkly platform. Vulnerabilities related to Excel interpreting and executing injected text are not in scope. 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 bruteforce issues on non-authentication endpoints Missing best practices in Content Security Policy. Missing HttpOnly or Secure flags on cookies, except the ldso cookie. 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] Vulnerabilities only affecting users of uncommonly-used browser extensions (eg, an extension designed to find redirect URLs embedded in the URL are designed to create open redirects on all URLs) 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 Findings related to non-SDK repositories (i.e., repos not ending in -sdk) Vulnerability/dependency scan results of our source code. Please try and dig into our source code more deeply than just reporting a scan result that we may already be aware of. Client-side SDK keys (used by the JS SDK and mobile SDKs) are not required to be kept secret. Please don’t report that these are visible in a properly-deployed application of the service. Client-side keys or tokens used on our website that are also not required to be kept secret. Examples include: Algolia search API key, TrackJS analytics token, etc. Jira ServiceDesk allowing public registration Verification email inbox spam HTML injection on text fields within the app or emails generated by the application Password reset link not expiring if email address changed Vulnerability scans / dependency scans on open source repositories Open source Github findings not related to our client and server SDKs (i.e., repos not suffixed by -sdk) P5 vulnerabilities Safe Harbor When conducting vulnerability research according to this policy, we consider this research to be: Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) (and/or similar state laws), and we will not initiate or support legal action against you for accidental, good faith violations of this policy; Exempt from the Digital Millennium Copyright Act (DMCA), and we will not bring a claim against you for circumvention of technology controls; Exempt from restrictions in our Terms & Conditions that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy; and Lawful, helpful to the overall security of the Internet, and conducted in good faith. You are expected, as always, to comply with all applicable laws. If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please inquire via our FreshDesk Portal before going any further.

In Scope (in scope)

Target Overview LaunchDarkly frontend app.launchdarkly.com The main LaunchDarkly application and point of entry. LaunchDarkly customers use this interface to log into the application and manage feature flags, context types, segments, and so on. Admin level users may also manage their LaunchDarkly organization (i.e. users, roles, environments) from this interface. How to test: Please create an account with your @bugcrowdninja email address in order to receive an account with full access to all features on the LaunchDarkly platform. Documentation for how to use LaunchDarkly may be found on our docs website . LaunchDarkly APIs app.launchdarkly.com/api/v2/ Provides the backend APIs for the LaunchDarkly application The /api/v2/ and /internal/ subroutes are customer-facing APIs and require either a valid ldso session cookie or an access token in the Authorization header for authentication. You may create an access token from the Account Settings page in the UI for use in API testing. If you prefer to use the session cookie, the ldso token may be retrieved from your own browser after logging into the UI. Conversely, the /private/ APIs are not meant to allow authentication to any non-LaunchDarkly users and use a separate authentication mechanism. Any cases where these endpoints are improperly accessible are worthy of note. Our external-facing API documentation may be found here: API docs LaunchDarkly SDKs What they do: SDKs are integrated into customer applications to evaluate LaunchDarkly feature flags the application. LaunchDarkly provides a wide range of SDKs for various languages and platforms, documented here: SDK docs We encourage researchers to integrate SDKs with custom applications and test the communication between the SDKs and LaunchDarkly's servers (see more details in the streamer/event recorder sections below). You'll need to generate an SDK key/client ID from the UI in order to initialize the SDK's connection with LaunchDarkly. We'd be interested in any general API vulnerability findings as well as any handler logic vulnerabilities that you may find. Additionally, our SDKs are open source and are available on Github (e.g. React client SDK). We encourage researchers to dig into the open source code if interested. However, we will not be accepting the following types of findings : Findings related to non-SDK repositories (i.e., repos not ending in -sdk) Vulnerability/dependency scan results of our source code. Please try and dig into our source code more deeply than just reporting a scan result that we may already be aware of. Streamer stream.launchdarkly.com Streamer provides flag information for server and client SDKs for flag evaluation. SDKs maintain connectivity with distributed streamer nodes and receive flag updates as changes are made in the platform in real time, allowing end user clients to react instantaneously and update the application accordingly. streamer.launchdarkly.com exposes a set of routes for retrieving flag data depending on whether the SDK is client or server-side (see the distinction here: client vs server SDKs ). Event Recorder events.launchdarkly.com Once flags are evaluated by the client/server SDKs, these SDKs will record and send events to events.launchdarkly.com for metrics collection. This allows customers to collect data about things such as which flags are being evaluated, how many times flags are evaluated, which contexts are being targeted, etc. Docs Site docs.launchdarkly.com Static site hosting LaunchDarkly documentation (i.e. installation/user/admin guides, API references, etc.)