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 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
- 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
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.
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
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 __.
- 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
Thanks for helping!