## CVE-2026-2942 WordPress ProSolution WP Client Plugin <= 1.9.9 is vulnerable to a high priority Arbitrary File Upload


## Overview

- **Published:** 2026-04-08
-** CVE-ID:** CVE-2026-2942
- **CVSS:** 9.8 Critical
- **Affected Plugin:** ProSolution WP Client Plugin
- **Affected Versions:** <= 1.9.9
- **CWE:** CWE-434 Unrestricted Upload of File with Dangerous Type

## Description

The ProSolution WP Client plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the 'proSol_fileUploadProcess' function in all versions up to, and including, 1.9.9. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible.

## Patch And Commit Analysis


### Comparison of Versions 1.9.9 and 2.0.0**

- **Version 1.9.9 (Vulnerable)**:

This release lacked proper security validation on the side dish page’s file upload functionality. As a result, it was susceptible to an Arbitrary File Upload vulnerability, allowing attackers to upload malicious files and potentially execute arbitrary code on the server.

- **Version 2.0.0 (Patched):**

The changelog highlights a critical fix:
“SECURITY UPDATE: add security validation to prevent arbitrary files upload on side dish page.”
In this version, developers introduced robust security checks to validate uploaded files, effectively mitigating the Arbitrary File Upload risk.

### Patch Diff

**Input handling (FILES) :**

- **1.9.9 :**


- **2.0.0 :**


At the input handling stage, the vulnerable version does not check whether a file exists. This allows attackers to directly call the endpoint without providing a file, leading to undefined behavior.

In the patched version, a validation check is added to ensure the file input exists, preventing direct abuse of the AJAX endpoint.

**File name & tmp validation :**

- **1.9.9 :**


- **2.0.0 :**


In the vulnerable version, there is no validation for the filename, temporary file path, or upload legitimacy. This allows attackers to upload malicious files without restriction.

In contrast, the patched version introduces sanitize_file_name() to prevent malicious filenames and path traversal, and is_uploaded_file() to ensure the file was uploaded via HTTP POST. These changes help prevent file spoofing and LFI-related attacks.

**Extension validation logic :**

- **1.9.9 :**


- **2.0.0 :**


In the vulnerable version, the file extension is derived from the MIME type provided by the client. Since the MIME type is user-controlled, an attacker can bypass validation by setting the Content-Type to a trusted value such as image/jpeg while uploading a malicious file (e.g., a PHP shell).

In the patched version, the extension is extracted from the filename on the server side and validated against a strict whitelist. If the extension does not match the whitelist, the upload process is terminated.

**MIME validation :**

- **1.9.9 :**


- **2.0.0 :**


In the vulnerable version, MIME type validation relies on client-supplied data, which is not trustworthy and can be easily manipulated by an attacker.

In the patched version, the application uses FILEINFO_MIME_TYPE to detect the actual MIME type based on the file’s content (magic bytes). This ensures that the file type is validated on the server side and cannot be spoofed via HTTP headers.

**WordPress MIME validation :**

- **2.0.0 :**


In the patched version, an additional MIME validation layer is introduced using WordPress core functionality. This provides a defense-in-depth mechanism to further verify the file type.

**EXT ↔ MIME consistency check :**

- **2.0.0 :**


The patched version introduces a whitelist-based validation that ensures the file extension matches the actual MIME type. After determining the real MIME type using magic bytes, the application compares it against a predefined mapping.

This prevents bypass techniques such as polyglot files or malicious files disguised with safe extensions (e.g., renaming a PHP shell to .jpg).

**Image content validation :**

- **2.0.0 :**


The patch also adds image content validation by checking the image structure using functions such as getimagesize(). This helps detect invalid or malformed image files, preventing attacks that rely on fake image headers.

**Response validation :**

- **1.9.9 :**


- **2.0.0 :**


In the vulnerable version, the response validation logic is weak (!= '').

In the patched version, this is improved by using !empty(), which is a safer and more reliable way to validate the response object.

**Final extension re-check :**

- **1.9.9 :**


- **2.0.0 :**


The vulnerable version does not perform any validation after the upload process is completed. It directly uses the file extension, which can be unsafe when combined with weak validation logic.

In the patched version, the extension is re-validated after upload using the whitelist. This additional check helps prevent bypass techniques such as handler-based manipulation or race condition attacks.

**Dangerous function removed + Error handling :**


In the patched version, the developers removed the insecure proSol_mimeExt function and introduced proper error handling. This improves both security and code reliability by eliminating unsafe logic and ensuring consistent error responses.

## Root Cause Analysis

The core issue lies in how the proSol_fileUploadProcess function handled file uploads — trusting user-supplied data at every validation step instead of performing server-side verification.

There are three fundamental failures that make this vulnerability trivially exploitable:

- **Client-controlled MIME type validation**
The vulnerable version derived the file extension from the Content-Type header supplied by the client. Since this header is fully attacker-controlled, setting it to image/jpeg while uploading a PHP file is enough to bypass the check entirely.
- **No server-side extension whitelist**
There was no validation against an allowed extension list after the file was received. The application accepted whatever extension the attacker provided in the filename, with no cross-check against actual file content.
- **No authentication on the AJAX endpoint**
The proSol_fileUploadProcess handler was registered without any capability or nonce check, meaning any unauthenticated user could call it directly — no WordPress account required.

The combination of these three weaknesses means an attacker can upload a PHP webshell by simply spoofing the Content-Type header, with no prior access or credentials needed.

## Attack Flow


## POC Proof Of Concept

**Exploitation Steps :**

The vulnerable AJAX handler accepts file uploads without any authentication or file type validation. We craft a multipart POST request, setting the Content-Type to image/jpeg to pass the weak client-side MIME check, while the actual payload is a PHP webshell.


The server processes the file without validating the actual extension or MIME type, and responds with the uploaded file's location:

{
  "newfilename": "66c87e2bbe.php",
  "url": "http://localhost/wp-content/uploads/prosolwpclient/66c87e2bbe.php"
}

With the webshell now living on the server, we simply call it with our desired command via the cmd parameter :

GET /wp-content/uploads/prosolwpclient/66c87e2bbe.php?cmd=ls

The server executes the command and returns the output directly in the response body, confirming full RCE under the web server's user context.


This confirms full RCE is achievable with zero prior access, requiring no WordPress account or special privileges.