Looking for a fix? Check your Codebase security with multiple scanners from

Edit Report

Our sensors found this exploit at:

Below is a copy:

MyBB 1.8.6 Improper validation of data passed to evalSecurity Advisory - Curesec Research Team

1. Introduction

Affected Product:    MyBB 1.8.6
Fixed in:            1.8.7
Fixed Version Link:
Vendor Website:
Vulnerability Type:  Improper validation of data passed to eval
Remote Exploitable:  Yes
Reported to vendor:  01/29/2016
Disclosed to public: 09/15/2016
Release mode:        Coordinated Release
CVE:                 n/a
Credits              Tim Coen of Curesec GmbH

2. Overview

MyBB is forum software written in PHP. In version 1.8.6, it improperly
validates templates that are passed to eval, allowing for the disclosure of the
database password. If the database is writable from remote, it may also lead to
code execution.

An admin account is required.

3. Details


CVSS: Low 3.5 AV:N/AC:M/Au:S/C:P/I:N/A:N

MyBB allows an admin to edit templates. These templates can contain HTML, and
it is possible to read out the content of PHP variables as well as the
properties of objects. There are filters in place which should make it
impossible to call functions or to read out sensitive information such as
database credentials.

Templates are used as following:

eval('$variable = "'.$templates->get('templateName').'";');

$templates->get returns the template as saved in the database, with double
quotes and slashes escaped.

When saving a template, the template is passed to the check_template function
to check if it contains malicious content. The checks try to prevent the
reading of the database password as well as the calling of functions. This
means that none of the naive attempts to read out the database password - eg
$config['database']['password'], $config[database][password], or $config
["database"]["password"] - would work.

However, it is still possibly to read out the database password by setting the
value of an existing variable to "password" and using that variable when
reading out the password, thus bypassing the filter.

Proof of Concept

First, edit a template such as the usercp_profile_contact_fields_field template:

Add this line at the beginning:
    {$cfvalue}: {$config['database'][$cfvalue]}

Now, visit the profile:

As any of the "Additional Contact Information" values, use "password" to read out the database password, 
    "hostname" to read out the hostname, and "username" to read out the user.

In case that the database is writable from remote, an attacker could now also
gain code execution, as check_template is applied when saving templates, not
when loading them. Example query:

UPDATE mybb_templates SET template="{${phpinfo()}}" WHERE title=

Visiting the profile will execute the injected code.


    $config['database']['password'] = '[THE_DATABASE_PASSWORD]';

    function check_template($template)
            // Check to see if our database password is in the template
            if(preg_match("#database'?\s*]\s*[\s*'?password#", $template))
                    return true;

            // System calls via backtick
            if(preg_match('#$s*{#', $template))
                    return true;

            // Any other malicious acts?
            // Courtesy of ZiNgA BuRgA
0-9 ]+\2\]s*)*\}~', '', $template)))
                    return true;

            return false;

usercp.php (as one example)

        foreach(array('icq', 'aim', 'yahoo', 'skype', 'google') as $cfield)
                $contact_fields[$cfield] = '';
                $csetting = 'allow'.$cfield.'field';
                if($mybb->settings[$csetting] == '')


                $cfieldsshow = true;

                $lang_string = 'contact_field_'.$cfield;
                $lang_string = $lang->{$lang_string};
                $cfvalue = htmlspecialchars_uni($user[$cfield]);

                eval('$contact_fields[$cfield] = "'.$templates->get('usercp_profile_contact_fields_field').'";');
4. Solution

To mitigate this issue please upgrade at least to version 1.8.7:

Please note that a newer version might already be available.

5. Report Timeline

01/29/2016 Informed Vendor about Issue
02/26/2016 Vendor requests more time
03/11/2016 Vendor releases fix
09/15/2016 Disclosed to public

Blog Reference:

Curesec GmbH

Copyright ©2020 Exploitalert.

All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use.