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

forminator1.44.2 → 1.44.3✓ COMPLETED

Files3

Vulnerable1

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-6463

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 3 CVE 1 Vuln 1

SORT

1 files · page 1/1

library/model/class-form-entry-model.php

AI: 1 vulnerabilities

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

#%!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-6463

Security writeup for CVE-2025-6463

✓ 1 FILE

## The Exploit

An unauthenticated attacker can craft a form submission that embeds an arbitrary file path (e.g., `/var/www/html/wp-config.php`) in the file metadata. When a site administrator or automated process deletes the form entry, Forminator will delete that file without validating that it resides within the upload directory or that the path has not been manipulated via traversal sequences.

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

action=forminator_submit_form&form_id=1&forminator-1-name=Test&forminator-1-upload=../../wp-config.php
```

The attacker observes a 200 response indicating successful form submission. When an admin later deletes that entry—either manually or via plugin-configured auto-deletion—`wp_delete_file()` executes on the path specified in the hidden metadata, removing `/var/www/html/wp-config.php` from disk.

## What the Patch Did

**Before**

```php
foreach ( $entry_model->meta_data as $meta_data ) {
    $meta_value = $meta_data['value'];
    if ( is_array( $meta_value ) && isset( $meta_value['file'] ) ) {
        $file_path = is_array( $meta_value['file']['file_path'] ) ? $meta_value['file']['file_path'] : array( $meta_value['file']['file_path'] );
        if ( ! empty( $file_path ) ) {
            foreach ( $file_path as $key => $path ) {
                if ( ! empty( $path ) && file_exists( $path ) ) {
                    wp_delete_file( $path );
                }
            }
        }
    }
}
```

**After**

```php
$upload_root = wp_upload_dir();
if ( empty( $upload_root['basedir'] ) ) {
    return;
}
$upload_root = $upload_root['basedir'];
foreach ( $entry_model->meta_data as $slug => $meta_data ) {
    $meta_value = $meta_data['value'];
    $field_type = Forminator_Core::get_field_type( $slug );
    if ( in_array( $field_type, array( 'upload', 'signature' ), true )
            && is_array( $meta_value ) && isset( $meta_value['file'] ) ) {
        $file_path = is_array( $meta_value['file']['file_path'] ) ? $meta_value['file']['file_path'] : array( $meta_value['file']['file_path'] );
        if ( ! empty( $file_path ) ) {
            foreach ( $file_path as $key => $path ) {
                $path = realpath( $path );
                if ( ! $path || ! file_exists( $path ) ) {
                    continue;
                }

$basename  = wp_basename( $path );
                $sanitized = sanitize_file_name( $basename );
                if ( $basename !== $sanitized ) {
                    continue;
                }

$normalized_upload_root = wp_normalize_path( $upload_root );
                $normalized_path        = wp_normalize_path( $path );
                if ( ! empty( $normalized_upload_root ) && 0 !== strpos( $normalized_path, $normalized_upload_root ) ) {
                    continue;
                }

wp_delete_file( $path );
            }
        }
    }
}
```

The patch adds five security controls. First, it retrieves the canonical upload directory using `wp_upload_dir()['basedir']` and normalizes it via `wp_normalize_path()`. Second, it calls `realpath()` on every path candidate, collapsing symbolic links and traversal sequences (`.`, `..`) to their canonical form. Third, it validates the filename basename with `sanitize_file_name()`, rejecting entries that contain path separators or other suspicious characters. Fourth, it enforces that the normalized path begins with the normalized upload root using `strpos()`, ensuring the file cannot exist outside the permitted directory. Finally, the patch restricts the deletion operation to fields explicitly marked as `upload` or `signature` types, preventing metadata injection attacks on unexpected field categories.

## Root Cause

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

The vulnerability lives in the `entry_delete_upload_files()` function in `library/model/class-form-entry-model.php`. During form submission, user-supplied file paths are stored in the entry's `meta_data` array without validation. An attacker can inject a path like `../../wp-config.php` or `/etc/passwd` into the `file_path` key. When the entry is later deleted—a process triggered by administrator action or automated expiry logic—the code passes this untrusted path directly to `file_exists()` and `wp_delete_file()`. Neither function performs canonicalization or directory confinement, so the operating system resolves the traversal sequences and deletes whatever file the attacker specified.

## Why It Works

The load-bearing line is:

```php
$path = realpath( $path );
```

This function resolves symbolic links, collapses `.` and `..` sequences, and returns a canonical absolute path. If you remove it, an attacker's submission of `../../../wp-config.php` will reach the subsequent checks as a string containing literal `../` sequences. The `strpos()` check against `$normalized_upload_root` will then fail—not because the path is outside the directory, but because the literal string `../../wp-config.php` does not start with `/var/www/html/wp-content/uploads`. However, if the operating system later resolves it during the `wp_delete_file()` call, the file will still be deleted.

The engineer added the basename sanitization (`sanitize_file_name()`) and field-type gating (`in_array( $field_type, ... )`) as defence-in-depth: they reduce the attack surface by rejecting payloads with suspicious characters and preventing metadata injection into non-file fields. The `wp_normalize_path()` call is critical because Windows uses backslashes as path separators, and comparing raw strings without normalization could produce false negatives. Together, these controls enforce that only files within the upload directory, with clean basenames, belonging to legitimate upload fields, are eligible for deletion.

## Hardening Checklist

- **Use `realpath()` before any filesystem operation on user-supplied paths.** It neutralizes traversal sequences and symlink attacks in a single call; never rely on string-based validation alone.
- **Confine file operations to a whitelist directory using `wp_upload_dir()` and `strpos()` prefix matching.** All file deletions, reads, and writes should be validated against the canonical upload path.
- **Validate field type at the metadata layer, not the request layer.** Use `Forminator_Core::get_field_type()` or equivalent before processing any file metadata, preventing injection into unintended fields.
- **Sanitize basenames with `sanitize_file_name()` and reject any path that contains directory separators.** This stops encoded or null-byte payloads from bypassing string checks.
- **Normalize paths using `wp_normalize_path()` before any comparison operation.** It abstracts away OS-specific path syntax and prevents bypasses on Windows systems using backslash separators.

## References

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

CVE CVE-2025-6463

PRODUCT forminator

AFFECTED ≤ 1.44.2

FIXED IN 1.44.3

STATUS Generated

Security writeup · CVE-2025-6463

Source files · 1

library/model/class-form-entry-model.php Linked

↗ NVD