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

everest-forms3.4.4 → 3.4.5✓ COMPLETED

Files19

Vulnerable13

True positives0

CVE matched2

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

CVE-2026-5478

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 19 CVE 2 Vuln 13

SORT

2 files · page 1/1

includes/abstracts/class-evf-form-fields-upload.php

AI: 4 vulnerabilities

CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')CWE-20: Improper Input ValidationCWE-200: Exposure of Sensitive Information to an Unauthorized Actor CVE-2026-5478

#%!d(float64=003)

includes/class-evf-form-task.php

AI: 1 vulnerabilities

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

#%!d(float64=009)

1–2 of 2

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2026-5478

Security writeup for CVE-2026-5478

✓ 2 FILES

## The Exploit

An unauthenticated attacker can read arbitrary files from the server by submitting a form with a file-upload field, injecting path-traversal sequences into the `old_files` POST parameter, and observing the file contents in the notification email. No prior access or authentication is required; the form merely needs to have a file-upload or image-upload field with entry storage disabled.

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

action=evf_submit_form&form_id=1&everest_forms_1_1=&everest_forms_1_1_old_1=["{\\"value\\":\\"http://target.wordpress.local/wp-content/..\\\\..\\\\..\\\\wp-config.php\\"}"]&everest_forms_1_delete_1=
```

The attacker's path-traversal payload (`..\\..\\..\\wp-config.php`) is decoded by the vulnerable regex replacement, which strips everything before `wp-content` and then concatenates `ABSPATH + wp-content/` + the attacker's path. Because no canonicalization occurs, directory boundaries are not enforced. The resolved file path escapes the uploads directory and points to `wp-config.php`. The plugin attaches this file to the notification email, leaking database credentials and security salts to the attacker's inbox.

Alternatively, if the form processes the request before email delivery, the post-email cleanup routine will call `unlink()` on the same unvalidated path, deleting the target file and causing denial of service.

## What the Patch Did

**Before**

```php
$uploaded_file = ABSPATH . preg_replace( '/.*wp-content/', 'wp-content', wp_parse_url( $file, PHP_URL_PATH ) );
if ( ! in_array( $uploaded_file, $entry_files ) && file_exists( $uploaded_file ) ) {
    $entry_files [] = $uploaded_file;
}
```

**After**

```php
$resolved = $this->resolve_uploads_file_from_url( $file );

if ( false !== $resolved && ! in_array( $resolved, $entry_files, true ) ) {
    $entry_files[] = $resolved;
}
```

The patch replaced a naive string-concatenation strategy with a dedicated validation function, `resolve_uploads_file_from_url()`, which performs canonicalization using `realpath()`, verifies the resolved path stays within the WordPress uploads directory using `strpos()` boundary checks, and confirms the file exists before returning it. The control is **directory confinement** — the fix ensures that any attacker-supplied URL, regardless of path-traversal encoding, is resolved to its true filesystem location and then validated against the uploads basedir boundary.

## Root Cause

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

The vulnerability flows from two trust boundaries crossed without validation:

1. **Untrusted old_files parameter**: The `$_POST[ 'everest_forms_' . $form_id . '_old_' . $field_id ]` POST parameter accepts JSON-encoded file objects with a `value` field containing URLs. The plugin assumes these URLs are legitimate server-side upload state, but an attacker can inject arbitrary URLs pointing to any file on the filesystem.

2. **Unsafe path resolution**: The code converts the attacker-supplied URL into a filesystem path using only a regex replacement (`preg_replace( '/.*wp-content/', 'wp-content', ... )`). This regex strips everything up to and including the first occurrence of `wp-content`, then the string is prepended with `ABSPATH`. An attacker can encode path-traversal sequences (e.g., `../../../wp-config.php`) in the URL; the regex does not canonicalize them, so they remain in the final path and allow directory escape.

The second vulnerability in the patch diff — improper input validation — compounds this by removing type checks on `$file_data['value']`. The fixed version adds `is_string()` assertions before attempting path resolution.

## Why It Works

The load-bearing line is `$resolved = $this->resolve_uploads_file_from_url( $file )`, which replaces the entire old path-resolution logic. If you removed it and kept the original regex approach, the bug is still exploitable: an attacker's `../../wp-config.php` payload would still reach `unlink()`.

The function itself performs three defenses:

1. **`realpath()` canonicalization**: Resolves all `..` and symbolic-link sequences to an absolute path, collapsing the attacker's encoding tricks into a single true path.
2. **Basedir boundary check**: Uses `strpos()` to confirm the canonical path starts with the uploads basedir; if it does not, the function returns `false`, blocking the attachment and deletion.
3. **File existence check**: Only returns the path if the file actually exists, preventing attackers from discovering non-existent files through error messages.

The engineer added the others — `is_string()` type checks, parameter validation, `esc_url_raw()` sanitization — to prevent subtle bypasses: an attacker who passes a malformed `value` field (null, array, object) could cause type confusion or fatal errors that skip the path check. Together, they form a defense-in-depth against both direct traversal and input-smuggling variants.

## Hardening Checklist

- **Use `wp_normalize_path()` and `realpath()` for all user-controlled file paths**: Before any filesystem operation (stat, read, unlink), resolve the path to its canonical form and verify it stays within an expected directory using `strpos()` prefix matching.
- **Sanitize URL inputs with `esc_url_raw()` before parsing**: Even if you do not execute a URL as a link, parsing untrusted URLs with `wp_parse_url()` can fail silently or return misleading components; always sanitize first.
- **Validate file locations against a whitelist of allowed directories**: Maintain an allow-list of directories (e.g., `wp_get_upload_dir()['basedir']`) and reject any resolved path that does not fall within one of them.
- **Add type assertions (`is_string()`, `is_array()`) on all unserialized and POST-sourced data**: JSON decoding can return unexpected types; check the type before accessing fields or passing to functions expecting a specific type.
- **Prefer a dedicated upload/file-retrieval API over manual path construction**: If your plugin re-implements file handling, audit it against `wp_safe_remote_get()` and `wp_get_upload_dir()` behavior to catch trust-boundary violations.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2026-5478

CVE CVE-2026-5478

PRODUCT everest-forms

AFFECTED ≤ 3.4.4

FIXED IN 3.4.5

STATUS Generated

Security writeup · CVE-2026-5478

Source files · 2

includes/abstracts/class-evf-form-fields-upload.php Linked

includes/class-evf-form-task.php Linked

↗ NVD