Details

Objective

At Chargebee, we take data integrity and security very seriously. Due to the nature of the product and service we provide, we are committed to working with individuals to stay updated on the latest security techniques and fix any security weakness in our application or infrastructure reported to us responsibly by external parties.

Eligibility Criteria

To be eligible for a reward:

Be the first to report the issue to us.
Subject to the Sections below, the submitted vulnerability must have a demonstrable impact in Chargebee's context. We use CVSS v3 as the vulnerability scoring framework.
Must contain sufficient information including a proof of concept screenshot, video, or code snippet where needed.
The person submitting the request must not be an employee, former employee or an immediate relative of an employee or former employee of Chargebee.
You must comply with the Program terms and conditions.

Scope

The following are in scope for the purposes of this policy and subject to the terms of this policy, are eligible for a reward:

Out of Scope

Anything not defined in the "Scope" section above.
Reports from automated tools or scans

Non-Acceptable Category

There are some submissions that we can't accept for rewards. These are typically issues that we already are aware of, or issues that we think demonstrate business value that outweighs the low-level risk, or low-risk issues that are unlikely to result in a code change. Following vulnerability classes are ineligible for rewards:

Denial of Service
DMARC/SPF
Self-XSS
Malicious File Upload
Social engineering
Email Spamming / Spoofing
Content Spoofing
Clickjacking and issues that are only exploitable through clickjacking that has minimal impact
CSRF on forms that are available to anonymous users (e.g. the contact form)
CSRF with negligible security impact (e.g. adding to favourites)
Software version number disclosure
Username or Site Name enumeration
Unvalidated Open Redirects or Tab Nabbing
HTML injection
Username or email address enumeration
Phishing attack using RTLO, Unicode/Punycode
Any security weakness or missing best practice without a demonstrable security impact
Descriptive error messages
Information disclosure with minimal security impact (e.g. stack traces, path disclosure, directory listings, logs, robots.txt, etc)
Lack of Secure and HTTPOnly cookie flags
Weak or missing captcha/captcha bypass
SSL Attacks such as BEAST, BREACH, Renegotiation attack
SSL Forward secrecy not enabled
SSL Insecure cypher suites
Missing HTTP security headers (including Anti-MIME-Sniffing header X-Content-Type-Options) that do not lead to direct exploitation
XSS was only possible by an administrator (e.g. administrators can modify HTML templates, that is not an example of an XSS vulnerability)
Self-XSS that has no security impact (e.g. injecting HTML into your own RTE editor)
Reports of third-party libraries without an actual proof-of-concept (e.g. if you are aware of a vulnerable library, then you need to submit a proof-of-concept showing that our use of the library is vulnerable)

Objective

At Chargebee, we take data integrity and security very seriously. Due to the nature of the product and service we provide, we are committed to working with individuals to stay updated on the latest security techniques and fix any security weakness in our application or infrastructure reported to us responsibly by external parties.

Eligibility Criteria

To be eligible for a reward:

Be the first to report the issue to us.

Subject to the Sections below, the submitted vulnerability must have a demonstrable impact in Chargebee's context. We use CVSS v3 as the vulnerability scoring framework.

Must contain sufficient information including a proof of concept screenshot, video, or code snippet where needed.

The person submitting the request must not be an employee, former employee or an immediate relative of an employee or former employee of Chargebee.

You must comply with the Program terms and conditions.

Non-Acceptable Category

Denial of Service

DMARC/SPF

Self-XSS

Malicious File Upload

Social engineering

Email Spamming / Spoofing

Content Spoofing

Clickjacking and issues that are only exploitable through clickjacking that has minimal impact

CSRF on forms that are available to anonymous users (e.g. the contact form)

CSRF with negligible security impact (e.g. adding to favourites)

Software version number disclosure

Username or Site Name enumeration

Unvalidated Open Redirects or Tab Nabbing

HTML injection

Username or email address enumeration

Phishing attack using RTLO, Unicode/Punycode

Any security weakness or missing best practice without a demonstrable security impact

Descriptive error messages

Information disclosure with minimal security impact (e.g. stack traces, path disclosure, directory listings, logs, robots.txt, etc)

Lack of Secure and HTTPOnly cookie flags

Weak or missing captcha/captcha bypass

SSL Attacks such as BEAST, BREACH, Renegotiation attack

SSL Forward secrecy not enabled

SSL Insecure cypher suites

Missing HTTP security headers (including Anti-MIME-Sniffing header X-Content-Type-Options) that do not lead to direct exploitation

XSS was only possible by an administrator (e.g. administrators can modify HTML templates, that is not an example of an XSS vulnerability)

Self-XSS that has no security impact (e.g. injecting HTML into your own RTE editor)

Reports of third-party libraries without an actual proof-of-concept (e.g. if you are aware of a vulnerable library, then you need to submit a proof-of-concept showing that our use of the library is vulnerable)