CVE-2026-53599: Authenticated Remote Code Execution in REDAXO CMS via Mediapool File Upload Validation Bypass

The REDAXO Content Management System (CMS) is a modular web publishing framework utilizing system addons to manage digital assets. A critical component within this framework is the Mediapool addon, which provides a centralized interface for uploading, validating, and managing administrative media files. This component exposes a significant attack surface because it acts as the primary gateway for untrusted files entering the web server filesystem. An authenticated backend user possessing the media[upload] privilege can interact with this component to write files to the public-facing directory of the application.

During a security evaluation of REDAXO versions between 5.18.2 and 5.21.0, a critical file upload validation bypass was identified. This vulnerability is classified under CWE-434 (Unrestricted Upload of File with Dangerous Type) and is tracked as CVE-2026-53599 or GHSA-98pp-vccm-qm25. The flaw is rooted in a logical validation regression introduced in the rex_mediapool::isAllowedExtension method within the media pool addon's library file (redaxo/src/addons/mediapool/lib/mediapool.php).

The failure to thoroughly validate user-supplied filenames allows attackers to upload files containing arbitrary server-side scripting code, such as PHP, disguised with complex, multi-segment extensions. When deployed on web servers configured with permissive mime-type handlers or unanchored interpreter mappings (such as Apache modules using certain configurations), these files can be directly executed by navigating to the public asset URL. This execution leads to unauthenticated remote code execution on the host operating system under the context of the web server daemon user.

The vulnerability is categorized as a logical evaluation regression originating from a patch introduced in version 5.18.2 (specifically commit 9d008697dcec6bf5a972bdc081fadb68e9dab7fa). Previously, the application protected against double-extension attacks by verifying that a filename did not contain any blocked extensions anywhere within its structure using a broad substring check. While secure, this implementation generated false positives, blocking completely benign filenames such as example.json because the string contained the blocked extension .js followed immediately by the characters on.

To mitigate these false-positive blocks, developers refactored the validation block to perform two specific suffix checks. The modified logic checked whether the filename ended directly with a blocked extension, or if it ended with a blocked extension followed by the detected file extension (e.g., filename.php.jpg). This assumed that a filename structure would never exceed two segments following the initial delimiter. This assumption created a logical blind spot for any filename containing three or more extension segments.

When a filename like shell.php.any.jpg is uploaded, the core system parses the primary extension as jpg. The validation method then evaluates whether the string ends with .php (which is false) or whether the string ends with .php.jpg (which is also false). Because both logical checks return false, the validation routine concludes that the file is safe and permits the upload process to complete. This logical disconnect allows dangerous scripts containing internal .php markers to bypass the defensive block list entirely.

To understand the mechanics of the bypass, it is necessary to examine the vulnerable source code from redaxo/src/addons/mediapool/lib/mediapool.php as it existed prior to the fix. The routine used standard suffix matching logic that failed when processing multi-segmented filenames:

// Vulnerable Code block from REDAXO 5.18.2 to 5.21.0
$blockedExtensions = self::getBlockedExtensions();
foreach ($blockedExtensions as $blockedExtension) {
    // Suffix-based checks to detect blocked extensions
    if (str_ends_with($filename, '.' . $blockedExtension)
        || str_ends_with($filename, '.' . $blockedExtension . '.' . $fileExt)
    ) {
        return false;
    }
}

The remediation introduced in commit 462e36896bb65d292ba22d711044c23c9cfb0340 replaces string-suffix matching with a strict tokenization-based strategy. Rather than evaluating the filename as a continuous string, the fixed code tokenizes the filename by splitting the string into an array of individual segments using the period character as the delimiter:

// Patched Code in REDAXO 5.21.1
$blockedExtensions = self::getBlockedExtensions();
// Convert to lowercase and split by dots to isolate all individual segments
foreach (explode('.', mb_strtolower($filename)) as $segment) {
    // Strict validation against the complete array of blocked extensions
    if (in_array($segment, $blockedExtensions, true)) {
        return false;
    }
}

This refactored logic successfully closes the multi-extension bypass vector. If an attacker uploads shell.php.any.jpg, the function converts the filename to lowercase and explodes it into the array ['shell', 'php', 'any', 'jpg']. The loop iterates over each element, matching the token php directly against the array of blocked extensions. The match causes in_array to return true, which immediately triggers a return of false, rejecting the upload.

Exploitation of CVE-2026-53599 requires the attacker to possess a low-privileged user account with permissions to upload assets to the REDAXO Mediapool (media[upload]). Once authenticated, the attacker prepares a web shell or remote execution payload. To bypass defensive controls that validate file headers or MIME types, the payload can be constructed as a valid image file, such as a JPEG/PHP polyglot, containing a small PHP execution block within its metadata headers.

The attacker renames the prepared polyglot file to use a multi-segment structure designed to evade the suffix validation checks. The target filename is set to exploit.php.any.jpg. Since this filename ends in .any.jpg, the suffix check passes, and the file is uploaded. The architecture of the exploitation flow can be represented as follows:

Once uploaded, the file is saved to the public-facing media/ directory. The success of the final execution stage relies on how the underlying web server processes files with multi-segment extensions. On Apache web servers employing the mod_mime module with configurations such as AddHandler application/x-httpd-php .php, the server processes extensions from right to left. Because .php is present as an internal segment of exploit.php.any.jpg, Apache treats the entire file as a PHP script and routes it to the PHP interpreter, executing the embedded web shell payload.

The security impact of CVE-2026-53599 is classified as High, receiving an official CVSS v3.1 base score of 7.5. The CVSS vector is defined as CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. The complexity is rated high due to the dependency on the target environment's specific web server configuration (such as Apache multi-extension processing or AddHandler directives).

Upon successful exploitation, an attacker achieves arbitrary code execution within the context of the running web server daemon (e.g., www-data or apache). This access level allows the attacker to read, modify, or delete sensitive files, including the REDAXO database configuration file config.yml containing administrative credentials. Attackers can leverage this access to establish persistent backdoors, escalate privileges on the host operating system, or access internal network segments.

Currently, there is no evidence of active, automated exploitation campaigns in the wild, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, because functional proof-of-concept steps are publicly documented, the risk of target exploitation remains elevated for any REDAXO deployment operating on legacy or permissive Apache hosting platforms.

The primary remediation strategy for CVE-2026-53599 is upgrading the REDAXO installation to version 5.21.1 or higher. This release contains the updated segment-based parsing logic that prevents multi-extension validation bypasses. Administrators should review the update logs to confirm that the mediapool addon is properly updated along with the system core.

In environments where an immediate system upgrade is not feasible, server-level hardening can effectively neutralize the attack vector. Specifically, administrators must avoid utilizing the permissive AddHandler directive in Apache configurations, as it maps PHP processing to any file containing the .php substring. Instead, the PHP interpreter should be mapped using an end-anchored regular expression within a FilesMatch block:

# Hardened PHP handler mapping in Apache configuration
<FilesMatch ".+\.php$">
    SetHandler "proxy:fcgi://127.0.0.1:9000"
</FilesMatch>

Additionally, ensuring that Options -Multiviews is set within the web server's directory options will prevent Apache from attempting to search for alternative file types when a specific file path is requested. Restricting write permissions on the media/ directory so that files cannot be executed as scripts is also a highly recommended defense-in-depth practice.