ANALYSIS · 3caea330· FINISHED 2026-06-13 · PATCHDIFF

mw-wp-form5.1.1 → 5.1.2✓ COMPLETED

Files4

Vulnerable3

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

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 4 CVE 2 Vuln 3

SORT

2 files · page 1/1

classes/controllers/class.main.php

AI: 1 vulnerabilities

CWE-20: Improper Input ValidationCWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') CVE-2026-5436

#%!d(float64=001)

classes/models/class.directory.php

AI: 2 vulnerabilities

CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')CWE-20: Improper Input Validation CVE-2026-5436

#%!d(float64=003)

1–2 of 2

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2026-5436

Security writeup for CVE-2026-5436

✓ 2 FILES

## The Exploit

An unauthenticated attacker can move arbitrary files on the server if the form contains a file upload field and "Saving inquiry data in database" is enabled.

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

action=mwf_form_submit&form_key=<valid_form_key>&mwf_upload_files[../../wp-config.php]=wp-config.php
```

The server accepts the request and moves `wp-config.php` into the uploads directory. If the attacker replaces `wp-config.php` with a malicious version before the move occurs, or if the file's new location is web-accessible, code execution follows. The response contains no obvious error — the form processes normally while the file operation executes in the background during `regenerate_upload_file_keys()` iteration.

---

## What the Patch Did

**Before**
```php
$form_id  = MWF_Functions::get_form_id_from_form_key( $this->Data->get_form_key() );
$filepath = MW_WP_Form_Directory::generate_user_filepath( $form_id, $key, $upload_filename );
if ( ! file_exists( $filepath ) ) {
    continue;
}
```

**After**
```php
$form_id = MWF_Functions::get_form_id_from_form_key( $this->Data->get_form_key() );

try {
    $filepath = MW_WP_Form_Directory::generate_user_filepath( $form_id, $key, $upload_filename );
} catch ( \Exception $e ) {
    error_log( $e->getMessage() );
    continue;
}

if ( ! $filepath || ! file_exists( $filepath ) ) {
    continue;
}
```

The patch added exception handling and explicit null-checking of the `$filepath` output before use. However, the real load-bearing fix lives in `class.directory.php`: two new validation methods, `_is_valid_path_segment()` and `_is_within_expected_dir_candidate()`, now reject path traversal sequences (`..`, `.`), absolute paths, and any filepath that escapes the intended user directory tree. The `$key` parameter is now validated by `_is_valid_path_segment()` before `path_join()` receives it, preventing the root cause: the WordPress `path_join()` function returns absolute paths unchanged, and the old code trusted that the supplied `$key` was safe to join.

---

## Root Cause

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

The attacker-controlled `mwf_upload_files[]` POST parameter array keys flow into the plugin's Data model via `_set_request_valiables()`, where they are stored as field keys without validation. During form processing, `regenerate_upload_file_keys()` iterates over these keys and passes them as the `$name` argument to `generate_user_filepath()`. The vulnerable code in `class.directory.php` checks only that `wp_basename($filename) === $filename` — ensuring the filename itself contains no slashes — but does not validate the `$name` parameter. When `$name` is set to `../../wp-config.php`, the function calls `path_join($user_file_dir, '../../wp-config.php')`. Because `path_join()` returns absolute paths unchanged and `../../wp-config.php` resolves to an absolute path, the function returns the absolute path to `wp-config.php` rather than a path confined to the upload directory. The `file_exists()` check then passes because `wp-config.php` genuinely exists at the root level, and `move_temp_file_to_upload_dir()` proceeds to `rename()` the file into the uploads folder.

---

## Why It Works

The load-bearing fix is the new `_is_valid_path_segment()` method, which rejects inputs where `path_is_absolute()` returns true or where the value equals `.` or `..`. Remove this check, and an attacker can still craft relative traversal sequences such as `../../../wp-config.php`, or supply an absolute path like `/var/www/wp-config.php`, both of which `path_join()` will honor. The `_is_within_expected_dir_candidate()` method serves as defence-in-depth: even if a creative input bypasses the first check, the second method canonicalizes both the resolved filepath and the expected user directory, then confirms via `strpos()` that the filepath is either equal to or a child of the expected directory. The try-catch block and null-check in `class.main.php` are hygiene: they prevent a crash if path generation fails, but without the two new validation methods in `class.directory.php`, attackers would still succeed because `generate_user_filepath()` would not throw an exception — it would return the attacker's target path unmolested.

---

## Hardening Checklist

- **Whitelist path segment components:** Use `_is_valid_path_segment()` logic (or equivalent) to reject path traversal sequences (`.`, `..`), null bytes, absolute paths, and directory separators before passing user input to `path_join()` or any filesystem operation. WordPress provides `path_is_absolute()` and `wp_basename()` as primitives.

- **Post-resolution confinement check:** After calling `path_join()` and normalizing with `wp_normalize_path()`, always verify the final resolved path lies within the intended parent directory using `strpos()` or equivalent prefix matching on the canonical (realpath'd) directory boundary.

- **Reject empty / invalid path segments:** Check that path inputs are non-empty strings and normalize them before validation. Use `wp_normalize_path()` on user input before testing against path-safety rules.

- **Wrap path generation in exception handling:** Call filesystem operations inside try-catch blocks and log exceptions without exposing details in user-facing responses. This prevents both crashes and information leakage if path validation fails.

- **Test path traversal inputs in your test suite:** Add unit tests covering `.`, `..`, absolute paths, and null bytes as inputs to any function that constructs file paths from user data. Run these tests on every form field that touches the filesystem.

---

## References

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

CVE CVE-2026-5436

PRODUCT mw-wp-form

AFFECTED ≤ 5.1.1

FIXED IN 5.1.2

STATUS Generated

Security writeup · CVE-2026-5436

Source files · 2

classes/controllers/class.main.php Linked

classes/models/class.directory.php Linked

↗ NVD