CVE-2026-104890: Remote Code Execution via Mixed-Case File Upload Bypass in Kunstmaan CMS MediaBundle

The Kunstmaan CMS MediaBundle component provides file upload and media management capabilities for web applications built on the Symfony framework. The vulnerability, tracked as CVE-2026-104890, resides within the file path generation and extension checking routines of this component. Specifically, the system employs a case-sensitive file extension blacklist that can be bypassed by uploading assets with mixed-case or uppercase extensions.

Because the CMS utilizes a default blacklist that covers only a narrow set of extensions, it fails to restrict multiple executable types. Furthermore, the component normalizes the extension to lowercase after executing the security check, leading to the storage of executable files on the disk. This order-of-operations discrepancy allows authenticated backend operators with media upload privileges to achieve remote code execution on the underlying hosting environment.

This security flaw represents a combination of unrestricted file upload with dangerous type (CWE-434) and loss of case sensitivity (CWE-178). It poses a significant risk to organizations where multiple administrative or editing roles exist, as any user with permission to upload media can execute arbitrary commands with the privileges of the web server process.

The root cause of CVE-2026-104890 lies in a logical flaw and temporal discrepancy during the validation and sanitization of user-supplied filenames. When a file is uploaded, the FileHandler::getFilePath method parses the original filename to determine its storage destination. To prevent malicious file uploads, the application matches the file extension against a configured array of blacklisted extensions using a regular expression.

The regular expression implementation, preg_replace('/\.(' . implode('|', $this->blacklistedExtensions) . ')$/', '.txt', $filename), lacks the case-insensitive modifier (i). Consequently, the blacklist match is strictly case-sensitive. An extension such as pHp or PHP does not match the default lowercase entry php in the blacklist array, and the input passes through the validation step unaltered.

Following the validation routine, the application extracts the file extension and normalizes it to lowercase via strtolower($parts['extension']) before appending it back to the filename for disk write operations. This design flaw performs normalization after the security check rather than before. As a result, the bypassed mixed-case file shell.pHp is normalized and persisted as shell.php on the web server filesystem.

Analyzing the vulnerable implementation in FileHandler::getFilePath highlights how the sequence of operations introduces the security gap. In the unpatched codebase, the application processes the path as follows:

// Vulnerable Order of Operations
if (!empty($this->blacklistedExtensions)) {
    // Case-sensitive check fails to match mixed-case extensions
    $filename = preg_replace('/\.(' . implode('|', $this->blacklistedExtensions) . ')$/', '.txt', $filename);
}
 
$parts = pathinfo($filename);
$filename = $this->slugifier->slugify($parts['filename']);
if (\array_key_exists('extension', $parts)) {
    // Normalization occurs after the validation check has passed
    $filename .= '.' . strtolower($parts['extension']);
}

The official patch introduced in version 7.3.2 restructures this logic to perform case folding before any security decisions are executed. The updated code extracts the extension, converts it to lowercase, and then evaluates it against both the blacklist and a newly introduced whitelist:

// Patched Implementation
$parts = pathinfo($filename);
$basename = $this->slugifier->slugify($parts['filename']);
 
if (!\array_key_exists('extension', $parts)) {
    return sprintf('%s/%s', $media->getUuid(), $basename);
}
 
// Normalize the extension to lowercase first
$extension = strtolower($parts['extension']);
 
// Validate the normalized extension
if (!$this->isAllowedExtension($extension)) {
    $extension = 'txt';
}

This change ensures that all extension checks occur on the normalized representation, preventing any case-sensitivity bypasses. Additionally, the helper method isAllowedExtension performs strict type comparisons against lowercase arrays of blacklisted and allowed extensions.

Exploitation of CVE-2026-104890 requires the attacker to hold an authenticated account with media management or upload privileges. The attack is highly reliable due to the deterministic nature of the filename normalization logic. The process begins with the preparation of a script container containing server-side code, such as PHP instructions designed to execute system commands.

The attacker names the payload file with a mixed-case extension such as payload.pHp to avoid matching the default case-sensitive blacklist entry php. Upon uploading the file to the media asset manager, the application accepts the file without altering its extension to .txt. The system then lowercases the extension and saves the file to the public upload directory.

To complete the execution cycle, the attacker requests the file directly through the web server. Because the files are stored within the web-accessible directory (/public/uploads/media/<uuid>/), and because standard web server configurations pass .php requests to a PHP interpreter, the script is executed by the server, allowing remote command execution.

The security impact of successful exploitation is critical, as it leads to execution of arbitrary operating system commands within the context of the web server daemon (e.g., www-data or nginx). Depending on the hosting configuration, an attacker can leverage this execution capability to perform local privilege escalation, compromise database credentials stored in environment variables, and access local system files.

The CVSS v3.1 score is calculated at 7.2 (High), reflecting network accessibility and low attack complexity, although tempered by the requirement for high privileges (PR:H). Despite the prerequisite of administrative or publisher-level authentication, the impact on confidentiality, integrity, and availability is maximum (C:H/I:H/A:H).

In containerized environments, the compromise may be restricted to the container instance, but it still exposes adjacent infrastructure via lateral network movement. On shared or poorly configured servers, this compromise can lead to complete host takeover, installation of persistent backdoors, or deployment of additional malicious payloads.

The primary remediation mechanism is the installation of Kunstmaan Bundles CMS version 7.3.2 or later. This upgrade addresses both the case-sensitivity loophole and expands the default blacklisted extensions array to cover related script types such as .phtml, .phar, and .php5. If immediate upgrade is not feasible, administrators must configure web server controls to block execution in upload directories.

For Nginx environments, script execution within the media directory can be disabled by adding a specific location block that denies execution of PHP assets within the media upload directory path. For Apache environments, administrators can disable script interpretation by placing a configuration directive that removes handlers for executable extensions in the target folder.

Furthermore, developers should define an explicit allowed-extensions whitelist in the CMS configuration. Defining a strict whitelist ensures that only expected, passive media types such as images, documents, and stylesheets are processed and saved, providing defense-in-depth against future bypass variants.