Duplicator < 1.3.28 — Directory Traversal

The plugin registers an unauthenticated download handler in two places.

In duplicator.php (vulnerable 1.3.26), a function is hooked on init:

function duplicator_init() {
    if (isset($_GET['action']) && $_GET['action'] == 'duplicator_download') {
        $file = sanitize_text_field($_GET['file']);
        $filepath = DUPLICATOR_SSDIR_PATH.'/'.$file;
        // Process download
        if(file_exists($filepath)) {
            ...
            header('Content-Disposition: attachment; filename="'.basename($filepath).'"');
            ...
            try {
                $fp = @fopen($filepath, 'r');
                ...
                while (!feof($fp) && ($data = fread($fp, DUPLICATOR_BUFFER_READ_WRITE_SIZE)) !== FALSE) {
                    echo $data;
                }
                @fclose($fp);
            } catch (Exception $e) {
                readfile($filepath);
            }
            exit;
        } else {
            wp_die('Invalid installer file name!!');
        }
    }
}
add_action('init', 'duplicator_init');

The same logic exists as an AJAX action in ctrls/class.web.services.php:

add_action('wp_ajax_duplicator_download', array(__CLASS__, 'duplicator_download'));
add_action('wp_ajax_nopriv_duplicator_download', array(__CLASS__, 'duplicator_download'));
...
public static function duplicator_download() {
    $file = sanitize_text_field($_GET['file']);
    $filepath = DUPLICATOR_SSDIR_PATH.'/'.$file;
    ...
}

DUPLICATOR_SSDIR_PATH is defined in define.php as <ABSPATH>/wp-snapshots:

define('DUPLICATOR_SSDIR_NAME', 'wp-snapshots');
define('DUPLICATOR_SSDIR_PATH', duplicator_get_abs_path() . '/' . DUPLICATOR_SSDIR_NAME);

The file parameter is only passed through sanitize_text_field(), which strips tags and invalid UTF-8 but does not strip path traversal sequences such as ../. The value is then concatenated onto the snapshots directory and handed to file_exists() / fopen() / readfile(). There is no realpath() containment check, no basename() on the input, and no whitelist. Consequently a request such as ?action=duplicator_download&file=../wp-load.php resolves to <ABSPATH>/wp-snapshots/../wp-load.php = <ABSPATH>/wp-load.php, and the file is streamed back to the caller.

Both entry points are unauthenticated: the init hook runs for every request, and the AJAX action is registered with the nopriv variant. No nonce or capability check guards the download.

Version 1.3.28 removes the init-hooked duplicator_init() function from duplicator.php entirely and rewrites the AJAX handler in ctrls/class.web.services.php so that the caller can no longer supply an arbitrary path.

The patched handler requires three parameters and validates them:

public static function duplicator_download()
{
    $error = false;

    if (!isset($_GET['id']) || !isset($_GET['hash']) || !isset($_GET['file'])) {
        $error = true;
    }

    $packageId = (int) $_GET['id'];
    $hash      = sanitize_text_field($_GET['hash']);
    $file      = sanitize_text_field($_GET['file']);

    if ($error || ($package = DUP_Package::getByID($packageId)) == false) {
        $error = true;
    }

    if ($error || $hash !== $package->Hash) {
        $error = true;
    }

    switch ($file) {
        case 'sql':
            $fileName = "{$package->NameHash}_database.sql";
            break;
        case 'archive':
            $format   = strtolower($package->Archive->Format);
            $fileName = "{$package->NameHash}_archive.{$format}";
            break;
        case 'installer':
            $fileName = $package->NameHash.'_installer.php';
            break;
        default:
            $error    = true;
    }

    $filepath = DUPLICATOR_SSDIR_PATH.'/'.$fileName;
    ...
}

Key changes:

1. The file parameter is no longer a path — it is a selector restricted to sql, archive, or installer. Any other value sets $error and the request is rejected.
2. The actual filename is derived server-side from the package's NameHash, so no attacker-controlled string reaches the filesystem path.
3. The request must reference a real package (id) and present the matching package hash, which is a secret value not exposed to unauthenticated users.
4. On failure the handler now sleep(2)s before wp_die('Invalid request') to slow brute-force attempts, and the error message no longer leaks the internal filename.

The corresponding view (views/packages/details/detail.php) was updated to build download links with id, hash, and the new file selector instead of a raw filename.

Detection is version-based plus a benign behavioural probe.

1. Version check: fetch /wp-content/plugins/duplicator/readme.txt and read the Stable tag. Any value <= 1.3.26 is vulnerable.

2. Behavioural probe (benign): request the download handler with a traversal that points at a harmless, known plugin file, e.g. GET /?action=duplicator_download&file=../wp-content/plugins/duplicator/readme.txt On a vulnerable build the response body contains the raw file contents (the plugin readme). On a patched build the handler rejects the request (missing id/hash) and the normal WordPress page is returned instead.

3. Log signatures: look for action=duplicator_download combined with file= values containing ../, %2e%2e, or absolute paths, on both / and /wp-admin/admin-ajax.php.

The detection spec shipped with this report performs the version check and the benign readme probe and reports vulnerable when the plugin version is <= 1.3.26 or when the benign probe returns the plugin readme content.