Summary
REDAXO's mediapool component allows authenticated backend users with upload permissions to store JPEG/PHP polyglot files that bypass extension checks.
On servers configured with multi-extension PHP handlers, these uploaded files can be executed as PHP scripts, enabling code execution under the web server account.
Affected context
This vulnerability occurs in REDAXO installations where:
- The mediapool addon is used to manage uploaded media files
- Backend accounts are granted
media[upload]permissions - The web server is configured with multi-extension PHP handlers (e.g., treating files like
*.php.any.jpgas PHP-executable)
Under these conditions, extension validation in rex_mediapool::isAllowedExtension can be bypassed using polyglot filenames that appear as images but contain PHP code.
Exploit preconditions
- Attack surface: REDAXO administrative web interface (backend mediapool upload feature)
- Required access: Authenticated backend user with
media[upload]permission - Trigger point: Uploading a crafted JPEG/PHP polyglot file named with multiple extensions (e.g.,
shell.php.any.jpg) through the mediapool - Why exploitation is possible: The extension checking logic focuses on the last extension segment and does not account for multi-extension PHP handler configurations, allowing a file that the server treats as PHP to be stored in a web-accessible location
Why this happens
The underlying bug is an inadequate file type and extension validation routine in rex_mediapool::isAllowedExtension, mapped to CWE-434: Unrestricted File Upload.
The mediapool logic assumes that examining the final extension segment is sufficient to ensure safety, implicitly trusting server behavior and ignoring multi-extension execution rules.
This insecure pattern allows attackers to upload files that appear to be benign images while embedding executable PHP code, which servers may interpret as scripts due to handler configuration.
Potential impact
- Remote execution of arbitrary PHP code as the web server user
- Creation of persistent web shells within the application's media directories
- Unauthorized access to application data and configuration files
- Lateral movement to other services reachable from the compromised server
- Defacement or manipulation of site content and stored media
General mitigation guidance
Effective mitigation focuses on strict file upload controls and defensive server configuration rather than version-specific changes.
Common patterns include:
- Validating uploads using a whitelist of trusted file types and single extensions, independent of server handler behavior
- Inspecting file content (MIME type, image headers) rather than relying solely on filename extensions
- Storing uploaded media outside executable web roots or under configurations that prohibit script execution
- Applying least-privilege principles to backend roles, limiting who can upload files and where they are stored
- Configuring web servers to avoid multi-extension execution patterns that treat media as scripts
How teams detect issues like this
Organizations can detect unrestricted file upload risks by:
- Reviewing backend upload endpoints for reliance on extension-only checks and absence of content validation
- Using static analysis to flag upload routines that do not enforce strict whitelists or non-executable storage locations
- Conducting code reviews focusing on file handling logic, especially around user-controlled filenames and media libraries
- Applying security policies that regularly scan uploaded directories for unexpected executable content
- Employing web application firewalls or upload filters that block known polyglot patterns and multi-extension filenames
