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 (https://open.vanillaforums.com) and our product repositories are at github.com/vanilla (https://github.com/vanilla). While we have gratefully accepted and promptly patched security reports from our users and contributors since the very beginning, we look forward to working with a wider range of individuals to make Vanilla as secure as it can be.
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 will be posted to our public GitHub issue tracker with our thanks. We may offer Vanilla swag for reports that do not qualify for a cash reward.
* $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.
* 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.
* We will publicly acknowledge reports that result in a security commit via our community at open.vanillaforums.com, usually in the effected release announcement. We will list your name, alias, Twitter handle, and/or email as desired. We will not link to a website.
* 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.
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.
* Any previously reported issues.
* 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 a
* dd 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.
* 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 (https://github.com/vanilla/vanilla) instead.
* Addons (including themes and locales) distributed via the open source community not maintained by Vanilla Staff.
* Vanilla employees and contractors may not receive bounties at this time.
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.
* 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 (http://docs.vanillaforums.com/developer/data-privacy/).
* We therefore consider this information to be sensitive unless you have the relevant 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 firstname.lastname@example.org to request clarifications to this policy or to suggest amendments.
Thanks for helping!
Hall of Fame