ANALYSIS · c86c9f34· FINISHED 2026-06-13 · PATCHDIFF

sureforms1.7.3 → 1.7.4✓ COMPLETED

Files4

Vulnerable3

True positives0

CVE matched1

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2025-6691

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 4 CVE 1 Vuln 3

SORT

1 files · page 1/1

inc/helper.php

AI: 1 vulnerabilities

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

#%!d(float64=003)

1–1 of 1

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2025-6691

Security writeup for CVE-2025-6691

✓ 1 FILE

## 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.

```http
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**

```php
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

CVE CVE-2025-6691

PRODUCT sureforms

AFFECTED ≤ 1.7.3

FIXED IN 1.7.4

STATUS Generated

Security writeup · CVE-2025-6691

Source files · 1

inc/helper.php Linked

↗ NVD