MyBB Upgrade Module Local File Inclusion

A path traversal vulnerability exists in the upgrade mechanism of MyBB, specifically within the install/upgrade.php script. This component is responsible for handling database schema updates and version migration tasks during the software's installation or upgrade process. The vulnerability stems from improper handling of the action HTTP parameter, which determines which upgrade module to load.

The application fails to adequately sanitize user-supplied input before using it to construct a file path for inclusion. By manipulating this parameter, an attacker can break out of the intended directory structure (install/modules/) and point the application to files located elsewhere on the server. While the inclusion logic appends a .php extension to the file path, this still permits the execution of any PHP file accessible to the web server user.

Access to the vulnerable script is typically restricted by the presence of an install/lock file in a production environment. However, if this file is missing, or if the attacker possesses administrative credentials to bypass the lock check, the vulnerability becomes exploitable. This flaw is tracked as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory).

The root cause of CVE-2025-48940 lies in the logic used to parse the action parameter in install/upgrade.php. The application intends to split this parameter into a module name and an operation. The parsing logic uses the PHP explode function with an underscore delimiter to separate these components.

The code blindly trusts the first segment of the exploded string ($bits[0]) and assigns it to the variable $from. This variable is subsequently passed to the next_function(), which is responsible for loading the appropriate upgrade module. Crucially, there was no validation to ensure $from contained only safe characters (such as alphanumeric characters) before it was used in a file path.

Inside next_function(), the application constructs a path using the pattern "upgrade" . $from . ".php" and passes this string to a custom load_module() function. Because $from is user-controlled and unvalidated, an attacker can inject directory traversal sequences (e.g., ../../) to navigate out of the install/modules directory. The lack of a whitelist or a sanitization routine for directory separators is the direct cause of this LFI.

The vulnerability is evident in the pre-patch logic of install/upgrade.php. The code extracts the action parameter and splits it without verifying the content of the resulting segments.

Vulnerable Code (Pre-Patch):

// The 'action' input is split, and the first part is trusted implicitly.
$bits = explode("_", $mybb->input['action'], 2);
if(!empty($bits[1])) 
{
    $from = $bits[0]; // $from is tainted user input
    $runfunction = next_function($bits[0], $bits[1]);
}
 
// ... inside next_function($from, ...)
// The tainted variable is used to construct a file path.
load_module("upgrade".$from.".php"); 

Patched Code (Fix):

The fix, applied in version 1.8.39, introduces strict validation using ctype_alnum(). This function verifies that the input consists solely of alphanumeric characters, effectively rejecting any payload containing dots (.) or slashes (/), which are required for path traversal.

$bits = explode("_", $mybb->input['action'], 2);
if(!empty($bits[1])) 
{
    // Validation: Ensure the input is only alphanumeric
    if(ctype_alnum($bits[0]))
    {
        $from = $bits[0];
    }
    else
    {
        $from = 0; // Fallback to safe default on failure
    }
    $runfunction = next_function($from, $bits[1]);
}

Additionally, a defense-in-depth check was added inside next_function to enforce the same alphanumeric constraint immediately before the load_module call.

Exploiting this vulnerability requires the attacker to have network access to the install/upgrade.php script. In a secure MyBB installation, this directory is locked via a lock file. Therefore, the attacker must either be an authenticated administrator (who is allowed to run upgrades) or target a server where the install/ directory was left unlocked or the lock file was deleted.

Attack Vector:

The attacker constructs a GET or POST request to install/upgrade.php. The malicious payload is injected into the action parameter. Because the application appends .php to the include path, the attacker is limited to including files that end in .php or files that the server will execute as PHP regardless of extension (if configuration allows, though the code explicitly adds the extension).

Payload Example:

GET /install/upgrade.php?action=../../../../tmp/malicious_payload_next&step=... HTTP/1.1
Host: target-forum.com
Cookie: [Admin Session Cookies]

In this scenario, if the attacker has previously managed to upload a file named malicious_payload.php to /tmp/ (perhaps via a separate avatar upload vulnerability or session file poisoning), the application would execute load_module("upgrade../../../../tmp/malicious_payload.php"). This resolves to /tmp/malicious_payload.php, resulting in Remote Code Execution (RCE).

The impact of this vulnerability ranges from sensitive information disclosure to full Remote Code Execution (RCE), depending on the attacker's ability to introduce files onto the server's filesystem.

Confidentiality: While the LFI is restricted by the appended .php extension, an attacker might be able to execute sensitive PHP configuration files. However, since they are executed rather than printed, reading source code is difficult unless the attacker uses PHP wrappers (e.g., php://filter), which may be difficult given the string concatenation structure.

Integrity & Availability: The primary risk is RCE. If an attacker can upload a file (e.g., a disguised image containing PHP code) or manipulate session files, they can use this LFI to execute that code. This grants full control over the web application, allowing the attacker to modify the database, delete forums, redirect users, or pivot to the underlying server operating system. The CVSS score of 7.2 reflects this high impact, tempered only by the high privileges or specific race conditions (unlocked installer) required for exploitation.