Submit bug report: http://avast.com
@avast_antivirus

Please submit bugs to email address [email protected]. It is recommended to encrypt your email - here's our PGP key.
Policy: https://www.avast.com/bug-bounty
Domains
avast.com

Submit bug report: https://algolia.com
@algolia
Algolia
Hosted search API that delivers instant and relevant results from the first keystroke.

Algolia is committed to working with security experts across the globe to stay up to date with the latest security techniques. If you have discovered a security issue that you believe we should know about, we'd welcome working with you. Please let us know about it and we'll make every effort to quickly correct the issue.
DO NOT use automated scanning tools
Scope
Website related endpoints on www.algolia.com
API related endpoints on .algolia.net or .algolianet.com
Bounty
Minimum reward is $100 for security vulnerabilities. 
Issues without security impact are not eligible for a bounty, yet still welcomed and will be treated like any other report.
Eligibility
You must be the first reporter of the vulnerability.

You do not access data of other users and solely use your created accounts.
You may not publicly disclose the vulnerability prior to our resolution.
You are not an individual on, or residing in any country on, any U.S. sanctions lists.
You provide a working proof of concept that exploits the security issue
Exclusion
Login/Logout CSRF
DDoS
Social engineering on customers or employees of Algolia
Self-XSS (we require evidence on how the XSS can be used to attack another Algolia user)
Miss of rate limits
Report from automated tools and scans
Vulnerabilities sending spam or unauthorised messages
Bugs in 3rd party software
X-Frame-Options related
Customer's sites
Relating to HSTS
DNSSEC
Missing security headers which do not lead directly to a vulnerability
Physical attack on the infrastructure
Theoretical attacks
Breaking of SSL/TLS trust
Compromising of browser/device (ex. computer sharing, physical access to a user's device, ...)
Vulnerabilities only affecting users of outdated or unpatched browsers and platforms
Password and account recovery policies, such as reset link expiration or password complexity
Vulnerabilities without solution on our side (HEIST, ...)
Outdated DNS record pointing to system which does not belong to Algolia
Any DNS record outdated for less than 48 hours
Broken links

Submit bug report: https://getadmiral.com/

@getadmiral

Admiral provides publishers with a suite of products aimed at engaging and recovering adblock users.

No technology is perfect, and Admiral believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you believe you've found a security issue in our product or service, we encourage you to notify us. We welcome working with you to resolve the issue promptly. Please review the following program rules before you report a vulnerability. By participating in this program, you agree to be bound by these rules.
Scopes
The following domains and applications are within the scope of this program:
*.getadmiral.com
*.levenlabs.com
JS script (provided via property's install page)
Third-party applications that are hosted on a subdomain are eligible for our program. Only severe vulnerabilities that affect our users, service, or infrastructure will be accepted for third-party applications and others will be reported/forwarded to the third-party vendor for the application.
Disclosure Policy
Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.
Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.
Vulnerabilities that are exposed publicly as a part of putting together a proof of concept (e.g. website defacement, stored XSS on a public site) are not eligible for a bounty.
Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.
Exclusions
While researching, we'd like to ask you to refrain from:
Denial of service to Admiral services or customers' services
Degrading performance or service of Admiral services or our customers' services
Spamming (even self-spamming)
Social engineering (including phishing) of any Admiral staff or contractors
Any physical attempts against Admiral or Admiral customers' property or data centers
Accessing private information of Admiral customers
Eligibility
In order to be eligible for a bounty, you must meet the following requirements:
You must be the first reporter of the vulnerability
Vulnerability must be associated with a domain or application listed above and not applicable to the above exclusions
You must not publicly disclose the vulnerability without our prior discretion
Vulnerability must have a clearly identified security impact and presented with enough information for investigation and reproduction by Admiral staff
Any vulnerabilities reported with the following criteria are not eligible for a bounty:
Affecting an ineligible scope
Bugs caused by a third-party website that our JS client is embedded on
Only affecting outdated browsers/platforms
Only affecting the executing user (self-XSS and similar)
Caused by misbehaving third-party software/website
Applicable only through social engineering
Pretense being you already have access to affected account (or user's browser)
Vulnerabilities considered by Admiral to be of low severity
Fine Print
Admiral will determine in its own discretion whether a reward should be granted and the amount of the reward. Depending on their impact, not all reported issues qualify for a monetary reward. However, all reports are reviewed on a case-by-case basis.
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.
Thank you for helping keep Admiral and our users safe!
Domains
getadmiral.com

Submit bug report: https://launchdarkly.com
@LaunchDarkly

LaunchDarkly Program Policy
At LaunchDarkly, our vision is to create a world in which software releases are safe and unceremonious. LaunchDarkly gives product delivery teams the safeguards to move fast without breaking things through the use of feature flags.
As a platform that our users trust to handle their user and customer data, application security and data protection are crucially important to us. LaunchDarkly looks forward to working with the security community to find security vulnerabilities in order to keep our businesses and customers safe.
Response Targets
LaunchDarkly will make a best effort to meet the following response targets for participating in our program:
Time to first response (from report submit) - 2 business days
Time to triage (from report submit) - 5 business days
Time to bounty (from triage) - 10 business days
We’ll try to keep you informed about our progress throughout the process.


Program Rules
All testing should be done on accounts associated with an email address on the domain. Once you have confirmed your email address, accounts on this domain will automatically be activated on a plan that provides access to all features on the LaunchDarkly platform. These accounts must only be used for testing for the purposes of the LaunchDarkly Bug Bounty Program. If you would like an account for other purposes, you may sign up for another account with a different email address.
If you need to test features on accounts without access to these features, you may create a trial account using a different email address, as long as it contains the string (for easy identification as a tester account).
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. Only interact with accounts you own or with the explicit permission of the account holder.
Disclosure Policy
As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.

Testing and Guidance
LaunchDarkly frontend (app.launchdarkly.com)
What it does: 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.

What to look for: In addition to the usual web vulnerability concerns, we'd be particularly interested in any findings related to:
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.
What it runs on: React/NodeJS
LaunchDarkly APIs (app.launchdarkly.com/api/v2/)
What it does: Provides the backend APIs for the LaunchDarkly application
How to test: Our external-facing API documentation may be found here: API docs
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.
What to look for: In additional to the usual API vulnerability concerns, we'd be particularly interested in any findings related to:
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
What it runs on: Golang
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
How to test: 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.
What it runs on: The SDKs cover a wide range of languages and platforms depending on the SDK, see the docs referenced above for details.
Streamer (stream.launchdarkly.com)
What this does: 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.
How to test: 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).
What to look for: 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.
What it runs on: Golang
Event Recorder (events.launchdarkly.com)
What this does: 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.
How to test: events.launchdarkly.com exposes a set of routes for handling and processing event data. No authentication is needed to access these endpoints, but the endpoint may expect certain metadata to be considered valid input.
What to look for: We'd be interested in ways that attackers may want to exploit our event recording mechanisms.
What it runs on: Golang
Third Party Integrations (not currently in scope)
What these do: 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.
Rewards
Our rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of LaunchDarkly.
Known issues
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
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:
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
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.
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)
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.
Thank you for helping keep LaunchDarkly and our users safe!

Submit bug report: http://artsy.net          
@0nlymohammed
We welcome security researchers that practice responsible disclosure and comply with our policies. Programs by Google, Facebook, Mozilla, and others have helped to create a strong bug-hunting community. The Artsy bug bounty program gives a tip of the hat to these researchers and rewards them for their efforts.
In order to be eligible for a reward under our bug bounty program, you must comply with the terms outlined below.
BASIC RULES
In addition to complying with our Terms of Use and any other applicable terms and conditions, you must also follow these basic rules when participating in our bug bounty program:
Do not access (or attempt to access) any user’s account or non-public data.
Do not affect or harm other users (or their access to or use of our services).
Do not perform any attack that could harm the reliability or integrity of our services or data. For example, DDoS/spam attacks are strictly prohibited.
Do not publicly disclose a vulnerability before we have resolved it.
Do not perform (or attempt) non-technical attacks, including spam, social engineering, phishing, or physical attacks against our employees, users, or infrastructure.


WHAT KINDS OF REPORTS DO NOT QUALIFY?
The following is a non-exhaustive list of reports that do not qualify for a reward under our bug bounty program:
Disclosure of public information or information that in our opinion does not present a significant risk.
Bugs, such as XSS, that only affect legacy browser/plugin versions, bugs that require exceedingly unlikely user activity or interaction, or timing attacks that prove, for example, the existence of a user.
Cookies shared between different *.artsy.net domains.
Bugs that have already been reported to us (i.e. first-come, first-served), or bugs that we are otherwise already aware of.
Scripting or other automation and brute forcing of intended functionality (all of which is strictly prohibited).
Issues related to software or protocols not under our control.
REWARDS
We may issue monetary rewards for reported issues that we decide to fix, with higher rewards for distinctly creative or severe security issues. Issues that we determine to be an insignificant or accepted risk will not be eligible for a reward. A typical reward for a single reported issue is U.S. $25. Some more severe issues can be $100. The maximum amount for any issue that the bug bounty program pays for single issue is of $250. If we determine that an issue you report does not qualify for a monetary reward, or if you're unable or unwilling to provide the personal information we require to issue a monetary reward, we may still send you a t-shirt or a tote, stickers, or some other token form of recognition to say thanks. Please note that only reports submitted by email to [email protected] may be eligible for a reward under our bug bounty program.
Policy: https://www.artsy.net/security
Domains
artsy.net

Submit bug report:  http://www.appdirect.com
AppDirect's Private Bug Bounty Program
AppDirect maintains a private bug bounty program since 2018. The program is invitation-only based on factors like the researcher’s reputation and previous work.
How does a researcher qualify to enter this program?
Our team individually invites researchers to enter the program. Typically, these are individuals who have established reputations, non-negative signals, and clear records with zero code of conduct violations. At times, we may also reach out to additional reputable individuals we believe would benefit the program.
Can I still submit a bug to AppDirect even though I am not part of the program?
Yes. If you have found an issue with our product i.e https://marketplace.appsmart.com/, www.appdirect.com, please send out an email notification to [email protected]. We encourage anyone to report vulnerabilities that could impact AppDirect and our customers.

All valid reports will be reviewed and assessed by AppDirect's security team to determine if it is eligible. AppDirect shall respond to eligible submissions with a proposed timeline for remediation and steps to handle any other issues.
What is out of scope for vulnerability disclosure?
Social engineering of AppDirect employees, contractors, vendors, or service providers.
Physical attacks against AppDirect employees, offices, and data centres.
Any vulnerability obtained through the compromise of AppDirect customer or employee accounts.
Being an individual on, or residing in any country on, any U.S. sanctions lists.
Subdomain takeover.
Issues with the SPF, DKIM, or DMARC records on appdirect.com or other AppDirect domains.
Clickjacking and Tab nabbing vulnerabilities.
Denial of service attacks at the network layer.
Software version disclosure
CSV and Hyperlink Injections
Missing best practices in SSL/TLS configuration.
CSRF with minimal security implications.
Self-XSS without a reasonable attack scenario.


Vulnerability guidelines
Critical
Severity level includes but is not limited to:
Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and/or data with limited exploitation difficulty and/or attacker skill.
Vulnerabilities that could be easily exploited by a remote or unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data of any kind without requiring user interaction.
High
Severity level includes but is not limited to:
Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and data.
Vulnerabilities that could be easily exploited by an internal and/or external, authenticated/unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data without requiring user interaction.
Vulnerabilities that allow local users to gain increased privileges.
Vulnerabilities that allow unauthenticated remote users to view sensitive information.
Medium
Severity level includes but is not limited to:
Vulnerabilities that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances.
Vulnerabilities that could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.
Low
Severity level includes but is not limited to:
Vulnerabilities that may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.
These types of vulnerabilities require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.


   Vulnerability                             Severity Range
1   Remote Code Execution             Critical
2   SQL Injection                          Medium - High
3   XXE                                          Medium- High
4   XSS                                             Low - High
5   Server-Side Request Forgery     High - Critical
6   Authentication/Authorization Bypass (Broken Access Control)   Low - Critical
7   Privilege Escalation                     Low - High
8   Security Misconfiguration             Low - Medium
Vulnerabilities not in the above list will be evaluated case by case.


Domains
https://marketplace.appsmart.com
https://appdirect.com