CVE-2025-6691 Exploit & Vulnerability Analysis

The Exploit

An unauthenticated attacker can send a single HTTP request to delete arbitrary files on the WordPress server by supplying a path-traversal payload in the file deletion endpoint.

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.wordpress.local
Content-Type: application/x-www-form-urlencoded

action=sureforms_delete_entry_files&file=../../../wp-config.php

The server responds with HTTP 200 and the file is deleted. An attacker observing the filesystem before and after the request will find wp-config.php no longer exists, causing WordPress to enter a fatal error state. On subsequent page loads, WordPress displays database connection errors, and the site becomes non-functional—a condition that persists until the attacker or an administrator restores the file.

What the Patch Did

Before

The vendor description indicates that delete_entry_files() in versions up to 1.7.3 accepted file paths directly without traversal validation. The old function (not shown in the diff) likely concatenated user input directly to a base upload directory without stripping directory components.

After

public static function delete_upload_file_from_subdir( $file_url, $subdir = 'sureforms/' ) {
    // Decode the file URL.
    $file_url = urldecode( $file_url );

    // Check if the file URL is empty.
    if ( empty( $file_url ) || ! is_string( $file_url ) ) {
        return false;
    }

    // Normalize and sanitize the subdirectory.
    $subdir = trailingslashit( sanitize_text_field( $subdir ) );

    // Get the base upload directory.
    $upload_dir       = wp_upload_dir();
    $base_upload_path = trailingslashit( $upload_dir['basedir'] ) . $subdir;

    // Extract only the filename from URL.
    $filename = basename( $file_url );

    // Construct the full file path.
    $file_path = $base_upload_path . $filename;

    // Resolve real paths.
    $real_file_path = realpath( $file_path );
    $real_base_path = realpath( $base_upload_path );

    // Security check: ensure file is inside the target subdir.
    if ( ! $real_file_path || ! $real_base_path || strpos( $real_file_path, $real_base_path ) !== 0 ) {
        return false;
    }

    // Delete if file exists.
    if ( file_exists( $real_file_path ) ) {
        return unlink( $real_file_path );
    }

    return false;
}

The patch introduced three layered controls: basename() to extract the filename component only (removing all directory separators), realpath() to canonicalize and resolve symlinks to their true on-disk locations, and a strpos() boundary check to confirm the resolved file path begins with the resolved base upload directory. Together, these prevent directory traversal by ensuring no ../ or absolute path can escape the intended subdirectory.

Root Cause

CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

The attacker-controlled file parameter from the AJAX request reaches delete_entry_files() without validation. The vulnerable code concatenates this parameter directly to a base directory path and passes it to unlink(), crossing a trust boundary: user input flows unchecked into a filesystem operation. If the parameter contains ../ sequences or an absolute path, the function resolves it outside the intended upload subdirectory, allowing deletion of files anywhere the web server process has write permission.

Why It Works

The load-bearing line is the strpos( $real_file_path, $real_base_path ) !== 0 check. Without it, the other defences fail alone: basename() strips path separators, but if the old code never used basename() at all, an attacker wins immediately. realpath() normalizes paths, but without the boundary check afterward, it only tells you where the file actually is—it does not prevent deletion outside the subdirectory. The strpos() assertion is the actual gate: it ensures that after resolving symlinks and normalizing all ../ sequences, the real path still begins with the real base directory. If that line is removed, an attacker can craft a symlink inside the upload directory pointing to /etc/passwd, call realpath() on it, observe it resolves outside the subdirectory—and in vulnerable code, the check never happens, so the file is deleted anyway. The patch's engineer added the other lines (type check, sanitize_text_field(), trailingslashit()) for defence-in-depth: they make the code robust to edge cases like null bytes, malformed subdirs, and inconsistent path separators, reducing the surface for future bypasses.

Hardening Checklist

• Use basename() on all user-supplied filenames before filesystem operations — never concatenate raw path input into unlink(), file_get_contents(), or fopen(). This strips directory traversal sequences at the point of entry.

• Call realpath() on the constructed file path and validate it falls within an allowed directory prefix using strpos() — this is the only reliable way to defeat symlink attacks and ensure canonical path confinement.

• Apply sanitize_text_field() to any user-supplied directory names — even if you control the base directory, prevent null bytes and unusual characters in parameters that influence path construction.

• Audit all AJAX endpoints that touch the filesystem — grep your codebase for wp_ajax_nopriv_* hooks paired with unlink(), mkdir(), rmdir(), or fopen() in write mode. Each is a potential traversal sink.

• Add a capability check even if the endpoint is nominally for unauthenticated users — if the feature requires user context, gate it behind current_user_can() with an appropriate capability. This reduces the blast radius if other validations fail.

References

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