CVE-2026-40488: Remote Code Execution via Blocklist Bypass in OpenMage LTS File Uploads

The vulnerability exists within the Mage_Catalog module of OpenMage LTS, specifically concerning the handling of customer-provided file uploads. This module allows store administrators to configure products with "Custom Options" that require users to upload a file prior to checkout. This functionality is common in ecommerce environments for products requiring custom designs, printing, or user-provided reference materials.

The core issue is classified as CWE-434: Unrestricted Upload of File with Dangerous Type. The application attempts to restrict malicious file uploads, but the implementation relies on a deficient blocklist approach rather than a strict allowlist. The default configuration fails to account for the numerous file extensions that modern web servers associate with the PHP interpreter.

Successful exploitation results in high-impact consequences for the affected environment. An attacker can upload a web shell or arbitrary PHP script to a public-facing directory. Because the storage path logic is deterministic, the attacker can easily compute the final URL of the uploaded file.

Once the uploaded file is accessed via a standard HTTP request, the web server executes the payload within the context of the web server user. This grants the attacker a foothold on the system, leading to data theft, persistent access, and full application compromise.

The root cause of CVE-2026-40488 is an inadequate validation mechanism within Mage_Catalog_Model_Product_Option_Type_File::_validateUploadedFile(). When a user submits a file, this function checks the file extension against a predetermined list of forbidden extensions. The application fetches this list from the XML configuration node catalog/product/options/custom/forbidden_extensions.

The default values defined in this configuration node only restrict the php and exe extensions. This naive blocklist fails to consider alternative file extensions that Apache with mod_php or Nginx with PHP-FPM routinely process as valid PHP code. Web servers are frequently configured to execute extensions such as .phtml, .php3, .php4, .php5, .php7, .pht, and .phar.

Blocklisting is inherently brittle for security validation because the list of dangerous extensions varies based on the underlying operating system, web server configuration, and installed modules. A secure implementation should employ a strict allowlist of explicitly permitted extensions (e.g., jpg, png, pdf) and reject any input that does not match.

Because the Mage_Catalog module operates independently of the application's central file validation routines in earlier versions, it missed system-wide security enhancements applied to other upload vectors. The isolated nature of this validation logic allowed the vulnerability to persist even if administrators hardened other parts of the platform.

The vulnerable code path initiates when the Mage_Catalog module processes the custom option file input. The application attempts to identify forbidden extensions by splitting the configuration string and directly comparing it against the uploaded file's extension. The implementation fails to leverage the robust core validator, opting instead for a narrow, module-specific check.

// Vulnerable Implementation (Conceptual representation)
protected function _validateUploadedFile()
{
    // Retrieves only 'php,exe' by default
    $forbidden = Mage::getStoreConfig('catalog/product/options/custom/forbidden_extensions');
    $forbiddenArray = explode(',', $forbidden);
    $extension = pathinfo($_FILES['options']['name'], PATHINFO_EXTENSION);
 
    if (in_array(strtolower($extension), $forbiddenArray)) {
        Mage::throwException('File type not allowed.');
    }
    // Proceeds to save the file
}

The fix introduced in OpenMage LTS 20.17.0 addresses this by migrating the validation logic to use the global Mage_Core_Model_File_Validator_NotProtectedExtension validator. This centralized validator synchronizes the restricted extension list with the system-wide protected_extensions list located in Mage_Core/etc/config.xml.

// Patched Implementation (Conceptual representation)
protected function _validateUploadedFile()
{
    // Leverages the global, comprehensive validator
    $validator = Mage::getModel('core/file_validator_notProtectedExtension');
    $file = $_FILES['options']['name'];
    
    if (!$validator->isValid($file)) {
        Mage::throwException('File type not allowed.');
    }
    // Proceeds to save the file safely
}

The protected_extensions node in the core configuration includes a much broader array of dangerous file types. The updated list covers .htaccess, .phtml, .php7, .phar, .sh, .pl, and .py, effectively neutralizing the bypass vector. While transitioning to an allowlist would provide stronger guarantees, centralizing the blocklist significantly reduces the attack surface and ensures consistency across the application.

Exploiting this vulnerability requires minimal prerequisites. The attacker needs access to a product configuration page that includes a file upload option. If the application permits guest checkout, no authenticated session is required. The attacker crafts a standard PHP webshell but names the file with a bypassed extension, such as shell.phtml or payload.phar.

The storage mechanism utilizes a predictable algorithm that allows the attacker to locate the file after upload. The application saves the file in the publicly accessible media/custom_options/quote/ directory. It creates a dispersion subdirectory using the first two characters of the original filename. For a file named shell.phtml, the subdirectory is sh/.

The final filename is constructed by generating the MD5 hash of the raw file content and appending the original file extension. Because the attacker controls the file content and the original extension, they can calculate the exact storage path locally before executing the attack. The predictable path formula is [first_two_chars]/[md5_of_content].[extension].

The final step involves sending an HTTP GET request to the computed URL, for example, http://example.com/media/custom_options/quote/sh/[md5_hash].phtml. The web server receives the request, identifies the .phtml extension as a PHP executable script, and processes the malicious code. The attacker now possesses remote command execution capabilities on the server.

The security impact of this vulnerability is severe, meriting a CVSS 4.0 score of 8.7. The vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N reflects the network-based attack vector, low attack complexity, and the profound consequences to confidentiality, integrity, and availability. Exploitation requires only basic customer-level access, which is easily obtainable on public ecommerce sites.

Successful execution grants the attacker code execution privileges matching the web server process (e.g., www-data or nginx). This level of access enables the attacker to read the app/etc/local.xml file, which contains cleartext database credentials. With database access, the attacker can extract customer Personally Identifiable Information (PII), administrative password hashes, and active session tokens.

The attacker can also modify application files to plant persistent backdoors, alter payment gateway configurations to skim credit card data, or deface the website. This broad access facilitates lateral movement within the hosting environment, especially if the web server process operates with excessive permissions or if local privilege escalation vulnerabilities exist on the system.

The EPSS score of 0.00117 indicates a currently low probability of mass exploitation in the wild, placing it in the 30.57th percentile. However, the Exploit Maturity is classified as Proof-of-Concept, meaning the technical details required to construct an exploit are public. The ease of exploitation means that automated scanners and opportunistic threat actors can rapidly incorporate this vector into their toolsets.

The primary and most effective remediation is to upgrade the OpenMage LTS installation to version 20.17.0. This release contains the official patch that implements the centralized Mage_Core_Model_File_Validator_NotProtectedExtension validator. System administrators should test the upgrade in a staging environment to ensure compatibility with existing modules and custom themes before deploying to production.

If immediate patching is not feasible, administrators must apply server-level mitigations to prevent script execution in the affected directories. The media/ directory is designed to serve static assets and should never execute server-side code. For Apache environments, administrators should create or update an .htaccess file in media/custom_options/ containing the directive php_flag engine off or SetHandler None.

For Nginx environments, administrators should implement a location block to deny access to executable extensions within the media path. The Nginx configuration should reject requests for .php, .phtml, .phar, and similar extensions residing in /media/custom_options/. This configuration change provides a robust defense-in-depth layer against all upload vulnerabilities.

As an additional temporary workaround, administrators can manually update the application configuration. By navigating to the catalog/product/options/custom/forbidden_extensions node in the database or XML configuration, administrators can expand the blocklist to explicitly include .phtml, .phar, .php3, .php4, .php5, .php7, and .pht. This manual update directly addresses the vulnerability mechanism without requiring an application restart or codebase alteration.