Redaxo Backup Path Traversal: Archiving the Crown Jewels

Backup utilities are the unsung heroes of system administration. They run with high privileges, they touch every file, and they bundle everything up into neat, portable packages. From a security perspective, they are also a terrifying double-edged sword. If you can control what the backup tool reads, you don't need a fancy exploit chain to exfiltrate data; you just need to ask nicely.

CVE-2026-21857 is exactly that kind of scenario. It affects Redaxo CMS, a flexible and popular content management system. Specifically, it targets the Backup Addon, a core component designed to help admins sleep better at night. Ironically, this vulnerability turns that safety net into a data exfiltration hose.

The premise is simple: the tool lets you export specific folders (like media or modules). But what if, instead of asking for the media folder, you asked for the ../../redaxo/data/core folder? The application, in a moment of naive trust, would obligingly zip up your database credentials and hand them to you on a silver platter.

The vulnerability lies in a classic breakdown of the "Trust Boundary." In web applications, anything coming from the client (the browser) is tainted, radioactive waste until proven otherwise. The Redaxo developers, however, treated the EXPDIR POST parameter as a trusted command.

Located in redaxo/src/addons/backup/pages/export.php, the code handles requests to generate a .tar.gz archive of selected directories. The UI presents a nice list of checkboxes, leading the developer to assume that only those checkboxes could be sent. But HTTP doesn't care about your UI.

The logic flaw was stark:

1. The script accepts an array of directory names via rex_post('EXPDIR', 'array').
2. It iterates through this array.
3. It concatenates these names with the base path to locate files.
4. It never checks if the resulting path is actually inside the intended directory.

This is a textbook Path Traversal (CWE-22). The code essentially said, "Go to the frontend directory, then go where the user tells you." If the user tells you to go ../../, the code listens.

Let's look at the smoking gun. In the vulnerable version (<= 2.9.3), the code grabbed the input and ran with it.

Vulnerable Code Logic:

// The code blindly accepts the array from POST
$EXPDIR = rex_post('EXPDIR', 'array');
 
if ($func == 'export') {
    // ... setup tarball ...
    foreach ($EXPDIR as $dir) {
        // $dir is unvalidated user input!
        // It gets concatenated to the path and added to the archive
        $archive->addDir(rex_path::frontend($dir));
    }
}

The fix, introduced in version 2.9.4, applies a whitelist approach. Instead of trying to sanitize the input (which is prone to bypasses), it builds a list of actual valid directories on the disk and forces the user input to intersect with that list.

Patched Code:

// 1. Get the base directory
$dir = rex_path::frontend();
 
// 2. Find all valid subdirectories physically present on disk
$folders = rex_finder::factory($dir)
    ->dirsOnly()
    ->ignoreDirs('.*')
    ->ignoreDirs('redaxo') // Explicitly ignore the core folder
;
 
// 3. Normalize the list to basenames
$folders = array_keys(iterator_to_array($folders));
$folders = array_map(rex_path::basename(...), $folders);
 
// 4. The Magic Fix: Intersection
// If 'EXPDIR' contains '../', it won't match anything in '$folders'
$EXPDIR = array_intersect($EXPDIR, $folders);

This array_intersect is a robust patch. Even if you send ../../, that string does not exist in the $folders array (which only contains clean names like assets, media, etc.), so the malicious input is silently dropped.

Exploiting this requires an authenticated user with access to the Backup addon. In many organizations, this role might be delegated to junior admins or automated service accounts, making it a prime target for privilege escalation.

Here is the attack chain:

1. Recon: Log in and navigate to Backup > Export > Files. Observe the legitimate request when you export a folder.
2. Interception: Use a proxy like Burp Suite to catch the POST request to index.php.
3. Modification: Locate the EXPDIR[] parameter. Replace a legitimate value (like media) with a traversal payload pointing to the configuration directory.

Payload:

POST /redaxo/index.php HTTP/1.1
Host: target.com
Cookie: ...
Content-Type: application/x-www-form-urlencoded
 
page=backup/export&func=export&EXPDIR[]=../../../../redaxo/data/core

4. Execution: Forward the request. The server processes the traversal, steps out of the webroot (or up to the core folder), and recursively adds the contents of redaxo/data/core to the tarball.
5. Exfiltration: The server responds with a 200 OK and a file download named backup_files_...tar.gz.

Inside that archive lies config.yml. This file contains the database hostname, username, and—most importantly—the password in plain text (or easily crackable formats depending on the setup), along with the installation's secret salt.

Why is this a high-severity issue if it requires authentication? Because it breaks the security model of the application completely. A "Backup" user is not supposed to have raw database access or the ability to read system-level configurations.

With the config.yml file, an attacker gains:

• Database Credentials: Direct access to the backend database. This allows creating new admin users, dumping customer data, or injecting malicious JavaScript (XSS) into content.
• System Secrets: Access to salts and API keys often stored in .env files or the config, enabling session forgery or bypassing CSRF protections.
• RCE Potential: In many CMS environments, database access is a stepping stone to Remote Code Execution. An attacker can often modify settings to allow PHP file uploads or execute code via serialized objects in the database.

Essentially, this vulnerability turns a maintenance feature into a "Download Root Access" button.