Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Try Vanilla Forums Cloud product

Linc · Vanilla's Bard (and Director of Development) · Vanilla Staff

Options are papercuts.


Last Active
Administrator, Staff
  • Vanilla 2.5 is now available

    Vanilla 2.5 - the stable gold release - can now be downloaded. The upgrade instructions are in the as part of the download. This release brings a completely revised Dashboard, a native RESTful API, "flat" categories, IPv6 support, enhanced security, and hundreds of bug fixes. Details in the pre-release discussion.

    Upgrading Notes:

    • Vanilla 2.5 requires PHP 5.6 which is a change from earlier versions. We strongly recommend upgrading to PHP 7.2 as soon as possible. Many hosting plans allow a seamless transition via their control panel. Vanilla will end support of PHP 5.6 in 2018.
    • To upgrade, first delete /applications/vanilla/controllers/class.settingscontroller.php, then follow the normal upgrade process, including running /utility/update.
    • We strongly recommend deleting the contents of your /cache folder after upgrading, and again if you experience issues after the upgrade.
    • Test your plugin & theme compatibility in a safe place before upgrading your production forum. We do sometimes accidentally break backwards compatibility.

    IF YOU HAVE TROUBLE UPGRADING AND NEED ASSISTANCE, PLEASE START A NEW DISCUSSION. If you are a developer and locate a reproducible issue, please file it on our GitHub tracker, noting your version as 2.5. We greatly appreciate the assistance.

    Please upgrade to 2.5 as soon as possible.

  • Critical security release: Vanilla 2.3.1

    This upgrade includes:

    • A critical upgrade to the PHPMailer library to prevent remote code execution.
    • Mitigation of a medium-level exploit of the HTTP_HOST header.
    • Additional minor fixes I will detail in a comment.

    BEFORE making this upgrade:

    IF you run Vanilla in an environment where you explicitly declare HTTP_HOST, for example:

    • Many nginx server setups
    • Using Varnish
    • Using a load balancer

    READ the new documentation about how to modify your install to accommodate (quoted below).

    FAILURE to heed this will result in a BROKEN upgrade to Vanilla 2.3.1 to the point of it being inaccessible via the web.

    If you're using a default Apache setup, you are very likely unaffected by this, and in fact the security patch herein is for you most especially.

    I apologize for this ungainly preamble, but the public publication of a medium-severity exploit has forced this half-baked workaround out the door immediately.

    Download It Now

    Use the standard upgrade steps

    If upgrading from 2.2 or earlier, see the 2.3 release discussion.

    If you have problems upgrading from 2.3, please report them immediately.

    Note that neither of these vulnerabilities effected our cloud customers. I include this note because I know some cloud customers do follow this forum. I will explain further why that is in a comment.

    Advanced Handling of Headers

    To utilize advanced handling of request and networking headers, it is recommended you make the necessary modifications in a bootstrap.before.php file. You may need to create this file in your config folder, if it does not already exist. The contents of this file are executed at the very beginning of Vanilla's bootstrapping process.

    If, for example, you wanted to use the Host header from an incoming request to set the host Vanilla sees, you would add the following into bootstrap.before.php:

        if (isset($_SERVER['HTTP_HOST'])) {
            $_SERVER['SERVER_NAME'] = $_SERVER['HTTP_HOST'];

    This will overwrite the host set by the server with the value of the Host header. It is crucial to verify the validity of any such data. If you cannot verify the hosts provided in these headers, do not attempt to use them.

    Permanent link to these new docs is here: Advanced Handling of Headers

  • Re: Critical security release: Vanilla 2.3.1

    Just past noon (ET) we were contacted for comment about "vulnerabilities in Vanilla Forums that were apparently reported back in December" by a blog. We were linked to two vulnerabilities that were published sometime today on ExploitBox. We received no advanced warning of their publication. An article was published which falsely implied our cloud customers had open vulnerabilities and were at risk, which has since been amended.

    After spending several hours tracking down the relevant communications and talking to folks internally, this was our statement regarding the issue that explains the nature of the issues reported, why there was a delay in releasing fixes, and why cloud was not effected:

    You've forwarded two published security vulnerabilities. This is the first we've been made aware of their publication. They both effect our free and open source product. Neither is currently present in our cloud service at, nor were they at the time of their publication.

    1. A HTTP_HOST vulnerability in Vanilla 2.3.
    2. A vulnerability in the version of PHPMailer bundled in Vanilla 2.3.

    Golunski contacted us December 22 regarding the HTTP_HOST vulnerability (but did not disclose the specific workflow detailed in the publicly published report - it was discussed only in the abstract). We thanked him for his discretion and investigated the issue. On January 6, we responded with our findings and cautioned that it would take us some time to release a fix due to the complexity of unwinding the use of this server variable without breaking the myriad scenarios it can be used for in open source environments. In the interim, Golunski had expressed a more simplistic view of the issue and was openly impatient with us. We received no further communication from the researcher after our explanation and request for time, nor prior to its publication.

    While a developer was already assigned and working on a careful general-case fix, we are not ready to move forward with said fix and this publication has forced our hand. We will issue a new version that simply strips its use, making it inappropriate for some setups which will also likely confuse the messaging around its release. The HTTP_HOST vulnerability never effected our cloud service.

    Golunski mentioned our PHPMailer library should be updated once in the middle of the communication chain about the HTTP_HOST vulnerability over the holidays. It was filed as a developer issue and patched, but a workflow error on our part caused us to miss following thru with a new public release (it remained conflated with the unresolved HTTP_HOST issue). We will expedite said release now, as we would have done had any followup been made by Golunski. Again, our cloud service was not vulnerable, having naturally received an update to PHPMailer last year as part of our transition to Composer-based dependencies.

    We believe these publications were hostile to the users of our free and open source software. Both the updated version of PHPMailer and the potentially breaking change to the use of HTTP_HOST will shortly be made available in a new open source version, Vanilla 2.3.1. The same outcome could have been achieved with sufficient communication.

  • Re: Critical security release: Vanilla 2.3.1

    If you are using master branch from git, please note the HTTP_HOST patch is not included in it yet. This is because we are still working on a nicer fix and/or our own internal systems have not yet been amended per the documentation above (a final decision about this hasn't been made yet).

    Anyone who is using these headers safely (as our cloud service is) can continue doing so without the patch included in 2.3.1. Anyone using master already had the remaining patches in this release.

    In any case, the worst scenario the researcher could come up with for this vulnerability was sending a password reset email to a user with the incorrect domain set in the (text) link, which is why it was graded as only "medium".

  • Re: Critical security release: Vanilla 2.3.1

    The critical security flaw in PHPMailer was already not present in the 2.4 prerelease. If you are using 2.4a, you may continue doing so. To close the HTTP_HOST flaw if you're not sanitizing HTTP_HOST already (as described above), see this patch to make the fix yourself for now. We'll have an updated release soon.