CVE-2025-12399: WordPress Alex Reservations RCE Vulnerability

CVE-2025-12399 Overview

CVE-2025-12399 is an arbitrary file upload vulnerability in the Alex Reservations: Smart Restaurant Booking plugin for WordPress. The flaw exists in the /wp-json/srr/v1/app/upload/file REST endpoint, which fails to validate the type of files submitted by authenticated users. All plugin versions up to and including 2.2.3 are affected. Authenticated attackers with Administrator-level access or above can upload arbitrary files, including PHP payloads, to the server. Successful exploitation can lead to remote code execution on the underlying WordPress host. The vulnerability is classified under CWE-434 (Unrestricted Upload of File with Dangerous Type).

Critical Impact
Authenticated administrators can upload executable PHP files through an unvalidated REST endpoint, enabling remote code execution and full site compromise.

Affected Products

Alex Reservations: Smart Restaurant Booking plugin for WordPress, versions up to and including 2.2.3
WordPress sites exposing the /wp-json/srr/v1/app/upload/file REST route
Hosting environments where the WordPress uploads directory permits PHP execution

Discovery Timeline

2025-11-08 - CVE-2025-12399 published to NVD
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-12399

Vulnerability Analysis

The Alex Reservations plugin registers a custom REST API endpoint at /wp-json/srr/v1/app/upload/file to handle file uploads associated with reservation management. The UploadFileController responsible for processing inbound files does not enforce an allowlist of MIME types or file extensions before writing the payload to disk. As a result, any file the requester submits is stored within the WordPress uploads directory.

Because the endpoint requires authentication at the Administrator level, exploitation depends on either a legitimate administrator acting maliciously or an attacker who has already obtained administrator credentials through phishing, credential stuffing, or a separate compromise. Once code is dropped to a web-accessible path, the attacker can request the file directly to trigger execution under the web server user. This results in a pivot from administrative WordPress access to full server-side code execution, which exceeds the privileges normally granted through the WordPress admin UI.

Root Cause

The root cause is missing server-side file type validation in the upload handler. The controller writes attacker-supplied content to the filesystem without checking the extension, MIME type, or magic bytes against an allowlist. See the WordPress Plugin Code Review for the affected handler.

Attack Vector

The attack vector is network-based and requires high privileges. An authenticated administrator sends a crafted POST request to the /wp-json/srr/v1/app/upload/file endpoint containing a PHP file. The plugin stores the file inside the WordPress uploads tree. The attacker then issues an HTTP GET request to the resulting URL to execute the payload. Public proof-of-concept material is available in the GitHub PoC Repository and the Ryan Kozak CVE Analysis.

Detection Methods for CVE-2025-12399

Indicators of Compromise

POST requests to /wp-json/srr/v1/app/upload/file carrying file payloads with executable extensions such as .php, .phtml, or .phar
New files in wp-content/uploads/ with PHP-related extensions or unexpected MIME types created shortly after a REST upload request
Subsequent GET requests directly to newly created files in the uploads directory, especially returning HTTP 200 with non-image content
Outbound network connections initiated by the PHP-FPM or web server process to unfamiliar hosts following an upload event

Detection Strategies

Inspect web server access logs for any client interaction with /wp-json/srr/v1/app/upload/file and correlate against the user account used
Hash and inventory files in wp-content/uploads/ to flag files whose contents do not match their declared extension
Alert on creation of .php, .phtml, .phar, or .htaccess files anywhere under wp-content/uploads/
Cross-reference administrator logins with upload activity to identify abuse of compromised privileged accounts

Monitoring Recommendations

Forward WordPress, PHP, and web server logs to a centralized logging or SIEM platform for retention and correlation
Enable file integrity monitoring on the wp-content/uploads/ directory and the plugin source under wp-content/plugins/alex-reservations/
Monitor for unexpected child processes spawned by the web server user (www-data, apache, nginx) that may indicate post-upload code execution

How to Mitigate CVE-2025-12399

Immediate Actions Required

Update the Alex Reservations: Smart Restaurant Booking plugin to the patched release published after version 2.2.3
Audit all administrator accounts, rotate passwords, and enforce multi-factor authentication on privileged WordPress roles
Review the wp-content/uploads/ directory for unauthorized files and remove any unexpected PHP, .phtml, or .phar artifacts
Inspect the web server for unknown scheduled tasks, cron jobs, or modified WordPress core files indicative of post-exploitation persistence

Patch Information

The vendor addressed the missing file type validation in the plugin source. The fix is recorded in WordPress Changeset 3390614. Additional vulnerability metadata is published by Wordfence Vulnerability Intelligence. Administrators should upgrade to the latest available version through the WordPress plugin manager.

Workarounds

Deactivate the Alex Reservations plugin until the patched version can be installed
Restrict access to the /wp-json/srr/v1/app/upload/file endpoint at the web server or WAF layer to trusted source IP addresses
Configure the web server to deny PHP execution within wp-content/uploads/ using directory-level rules
Reduce the number of accounts granted Administrator privileges and audit role assignments regularly

bash

# Example Apache configuration to block PHP execution in the uploads directory
<Directory "/var/www/html/wp-content/uploads">
    <FilesMatch "\.(php|phtml|phar|php[0-9]+)$">
        Require all denied
    </FilesMatch>
</Directory>

# Example Nginx equivalent
location ~* /wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
    return 403;
}