Howdy, stranger!

Vanilla has been free and open source software since 2006. Our current version is offered as both an open source download and as a cloud service via Vanilla Forums, Inc. We have an active open source community at open.vanillaforums.com and our product repositories are at github.com/vanilla.

Our blog, 'library', and marketing forms (FREE TRIAL, CONTACT US, and REQUEST DEMO) are NOT covered under this program. Submitting those forms will DISQUALIFY you. See "Exclusions" below for more info.

Rewards (in USD):

We will triage all reports received to make a determination on their severity. To be eligible for a cash bounty, they must fall into one of these categories below. Issues deemed "Low" or not a security issue may be disclosed through the HackerOne disclosure program with our thanks if they relate to the Vanilla Forums code. We will consider issuing CVEs for issues rated Medium or higher related to the Vanilla Forums code.

• $150 Medium - Spoofing an error message with HTML; any highly difficult exploits; nuisance CSRF (ex: deleting your own post).

• $300 High - Most XSS; CSRF on critical actions; unauthorized access to private content.

• $600 Critical - Remote Code Execution; SQL injection; privilege escalation for critical actions.

Critical actions include posting, most administration actions (activating addons; editing templates), and high-impact moderation actions (deleting categories or other users' content; banning).

We pay a flat $100 bounty for any security issue discovered in the latest version of the Htmlawed library which we use to filter user-generated content (note: this offer becomes void if they start their own bounty program). This includes XSS flaws in user-generated content that is passed thru this filter.

We likewise pay a flat $100 bounty if a public security-patched version of any dependency we use has existed for more than 30 days which we have not updated our master branch to use. No other issues with dependencies are included in this program.

Disclosure:

• While we make every effort to deal with all reports as quickly as possible, we are the ultimate arbiter of what a reasonable timeframe for delivering a fix is. You agree to not impose your own deadline for disclosure.

• Do not publicly reveal security bugs for 90 days after a public patch release or until after a private patch (i.e. to code that is not open source) has been deployed to all effected cloud systems.

• Issues evaluated as "Medium" or higher may be disclosed through the HackerOne disclosure program at the request of the submitter 90 days after a patch has been made publicly available. We will consider issuing CVEs for issues rated “Medium” or higher that relate directly to the Vanilla Forums open source code. Issues evaluated as “Low” or “None” will typically not be disclosed through the HackerOne disclosure program or have CVEs issued for them.

• We will acknowledge any HackerOne disclosures related to the Vanilla Forums open source code via the community at open.vanillaforums.com and on the associated Github project. These disclosures and acknowledgement will occur no sooner than 90 days after the patched version has been made publicly available. These disclosures will consist of a link to the HackerOne disclosure and a link to any related CVE if one exists for the vulnerability.

Reports:

• There must be a significant security implication made clear in the report (severity, scope, vectors, and applications).

• Clearly-labelled proof of concept or detailed reproduction instructions.

• Do you have suggestions for remedying the issue?

• Demonstrate vulnerabilities only in ways that do not draw attention to them or compromise users' privacy.

• If a reported issue is a duplicate, we will provide the id of the original issue. We do not by default grant the duplicate reporter access to the original issue; the duplicate reporter may request access and at our sole discretion we may grant access. We will provide a rationale for not granting access if it is denied in this case.

Exclusions:

PLEASE READ ASSET EXCLUSIONS BELOW. Our blog, 'library' subdomain, and free trial form are all third-party software not covered under our program. Please do NOT request free trials. We are not currently providing cloud accounts for security testing to the general public.

Specific exclusions:

• Any previously reported issues.

• Do not post about an unbounce subdomain takeover unless you can explain how this is possible. We have an explicit CNAME that is tied to an account we own; there is no way to put content under that domain via some other unbounce account.

• Social engineering against our employees, contractors, or customers.

• Conducting Denial of Service attacks.

• Physical attempts against our offices, data servers, or property.

• Spamming other users with automated emails or notifications (e.g. abusing the forgot password form).

• Automated tools or scanning.

• Issues with our third-party Composer dependencies - please report those upstream.

• Reports of self-XSS or self-DoS (effecting only the initiating user).

• Reports of injecting XSS, stealing cookies, or similar issues by using administrator-grade permissions. This includes both the Settings.Manage and Community.Manage permissions. Administrators with wide Dashbord access have the ability to add unfiltered HTML to pages and this is by design.

• Reports relating to missing rate limiting on our APIs.

• Ability to game Reactions and other peer-curation methods.

• Ability to create a discussion via Vanilla Comments when embedding is enabled.

• Ability to attack jsConnect from the same IP as the victim.

• Data disclosure in Debug mode.

• Logout CSRF.

• Mixed content (non-secure assets included in a page) resulting from user actions (i.e. not present in a default install).

• Account enumeration (either username or email).

• Cloudflare IP addresses serving SSL certificate (WAF bypass).

• Attacks requiring physical access to a device.

• Issues with no obvious ability to cause immediate harm or are at best a parlor trick. E.g.: a CSRF that allows you to change the locale of a user. Please file these issues on our GitHub issue tracker instead.

• Addons (including themes and locales) distributed via the open source community not maintained by Vanilla Staff.

• Insecure form submissions, including sign-in. Hosted communities offer HTTPS and an option to force all requests to be secure. Not opting into this forced-HTTPS setting does not represent a security issue in the product.

• Timing attacks will be considered non-applicable unless a valid POC is also provided.

• Click-jacking that does not clearly result in a malicious activity, especially those resulting from X-Frame-Options not being set due to embedding being enabled without using Trusted Domains to limit it.

• Vanilla employees and contractors may not receive bounties at this time.

Reported issues:

This is to highlight a few low-priority issues that we are in the process of addressing over the next year or so. This is not an exhaustive list; it's only meant to help prevent duplicative issues in the interim.

• Inability to invalidate active sessions (broken session management).

We also suggest reviewing recent patches and testing against our current master branch whenever possible before submitting reports to avoid duplication.

Brute-force password attacks:

Vanilla uses a rate-limiting system that throttles password attempts to once per second for every username attempted or IP address origin. We explicitly do not employ a "lock out" system. Throttling to once per second ensures that no reasonably complex password can be brute-forced on any reasonable timescale. We are currently satisfied with our throttling strategy. Please do not report brute-force password vulnerabilities unless they present new information about a flaw in our throttling system.

Sensitive information:

• We consider personally identifying information (PII) to include: Email, IP addresses, login cookie data, personal API access token, and foreign token (UniqueID) used in SSO connections. Note that a user may choose to opt-in to revealing their email on their profile, in which case it is no longer protected by design.

• We do NOT consider the following to be PII: UserID, Username. We consider these to be public data.

• We therefore consider this information to be sensitive unless you have the relevant permissions (e.g. administration, moderation or user-management permissions) to view it:

• PII about other users.

• Roles specifically marked as "private".

• Category names for which a user does not have View (or higher) permission.

• Discussion name, body, and comments for which a user does not have View (or higher) permission.

• Database connection information.

• Any other credentials stored in the config, including foreign API keys.

• Data used in the secure steps of establishing a single sign-on connection.

• We specifically do NOT consider this information sensitive:

• Database structure.

• Server directory paths and structure.

• Software names and version numbers.

Please contact security@vanillaforums.com to suggest amendments or to ask questions about this policy. Please note that we are unable to evaluate possible reports via this email, if you have a report you would like us to evaluate please submit through HackerOne.

Thanks for helping!