CVE-2025-0520: Unauthenticated Remote Code Execution via Unrestricted File Upload in ShowDoc

ShowDoc versions prior to 2.8.7 contain a critical unrestricted file upload vulnerability identified as CVE-2025-0520. The flaw exists in the image upload endpoint accessible via the URI path /index.php?s=/home/page/uploadImg. This endpoint fails to validate file extensions correctly before saving user-supplied files to the server filesystem.

The validation failure stems from a misconfiguration in the implementation of the underlying ThinkPHP framework. The framework defaults to a permissive state, allowing all file extensions when the validation property is incorrectly specified or omitted entirely. The developer's incorrect property assignment overrides the intended security controls.

Unauthenticated attackers exploit this vulnerability to upload arbitrary PHP scripts to the target server. The application stores these uploaded scripts in a publicly accessible directory without stripping execution privileges. Successful exploitation results in arbitrary remote code execution within the context of the web server process.

This vulnerability affects all default installations of ShowDoc prior to the patched version. The flaw exposes affected systems to complete compromise, allowing attackers to establish persistent access, manipulate internal databases, and pivot into adjacent network segments.

The vulnerability originates in the uploadImg method of the PageController class. The development team attempted to enforce a whitelist of safe image extensions for user uploads. To implement this restriction, the code instantiated the Think\Upload class from the ThinkPHP 3.x framework.

The developer assigned the array of permitted extensions (jpg, gif, png, jpeg) to a property named allowExts. The ThinkPHP 3.x framework expects the extension whitelist to be defined using the property exts. Because allowExts is an unrecognized property, the framework silently ignored the configuration assignment.

Consequently, the upload class operated with an empty extension restriction list. The framework logic permits all file types by default when no explicit restrictions are configured. This architectural behavior is designed to allow developers to build generic upload handlers, but it introduces severe risks when intended restrictions fail to apply.

The application logic relies entirely on the ThinkPHP class for file validation before moving the temporary upload to its final destination. Since the framework validation passes successfully for all extensions, the application proceeds to write the file, enabling the upload of executable PHP scripts directly to the web root.

The vulnerable implementation resides in server/Application/Home/Controller/PageController.class.php. The instantiation of the upload handler explicitly demonstrates the property name error. The code defines a maximum file size and attempts to define the allowed extensions before invoking the upload() method.

public function uploadImg(){
    // ...
    $upload = new \Think\Upload();
    $upload->maxSize  = 3145728 ;
    $upload->allowExts  = array('jpg', 'gif', 'png', 'jpeg'); // INCORRECT PROPERTY
    $upload->rootPath = './Public/Uploads/';
    $upload->savePath = '';
    $info = $upload->upload();
    // ...
}

The framework documentation confirms exts is the correct property for array-based extension validation in ThinkPHP 3.x. The incorrect property assignment left the upload process entirely unrestricted. The patch resolves this by correcting the property name to exts.

--- a/server/Application/Home/Controller/PageController.class.php
+++ b/server/Application/Home/Controller/PageController.class.php
@@ -147,7 +147,7 @@ public function uploadImg(){
         }else{
             $upload = new \Think\Upload();
             $upload->maxSize  = 3145728 ;
-            $upload->allowExts  = array('jpg', 'gif', 'png', 'jpeg');
+            $upload->exts  = array('jpg', 'gif', 'png', 'jpeg');
             $upload->rootPath = './Public/Uploads/';
             $upload->savePath = '';
             $info = $upload->upload() ;

This simple syntactic correction restores the core validation mechanism. Attackers attempting to upload .php files after this patch will face a validation rejection from the framework before the file is written to disk. The upload method will return a failure state, preventing the malicious file creation.

Exploitation requires network access to the vulnerable ShowDoc instance. The attacker does not need prior authentication or specific privileges, making this a zero-click remote vector for unauthenticated users. The /index.php?s=/home/page/uploadImg endpoint handles the payload delivery.

The attack sequence begins with crafting a standard multipart/form-data POST request. The request targets the upload endpoint and includes a PHP web shell as the payload within the editormd-image-file parameter. The filename is explicitly set with a .php extension.

POST /index.php?s=/home/page/uploadImg HTTP/1.1
Host: <target-ip>:8080
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryExploit
Connection: close
 
------WebKitFormBoundaryExploit
Content-Disposition: form-data; name="editormd-image-file"; filename="shell.php"
Content-Type: text/plain
 
<?php phpinfo(); ?>
------WebKitFormBoundaryExploit--

The server processes the request and writes the payload to the Public/Uploads/ directory. The application then returns a JSON response containing the exact path to the newly created file, typically structured as {"success":1, "url":"/Public/Uploads/[date]/[hash].php"}.

The attacker issues a subsequent GET request to the URL provided in the JSON response to execute the web shell. This execution grants the attacker command execution capabilities on the underlying operating system.

The vulnerability allows an unauthenticated attacker to achieve arbitrary code execution. This represents a complete compromise of the application's confidentiality, integrity, and availability. The executed code runs with the privileges of the web server process (e.g., www-data or apache).

An attacker can leverage this access to read sensitive configuration files, including database credentials. The access also permits the modification or deletion of existing documentation stored within ShowDoc, directly impacting organizational knowledge bases.

The CVSS v4.0 base score is 9.4, reflecting the critical severity of unauthenticated remote code execution. The high score is driven by the minimal attack complexity, the lack of authentication requirements, and the severe downstream impact on the host system.

The EPSS score of 0.01614 places this vulnerability in the 81.78th percentile for expected exploitation. The availability of public proof-of-concept exploits and documented active exploitation significantly elevates the immediate risk profile for internet-facing installations.

The primary remediation strategy is upgrading ShowDoc to version 2.8.7 or later. This version contains the corrected property assignment and properly restricts file uploads to the intended image formats. Organizations should apply this update immediately to all accessible instances.

Administrators who cannot immediately apply the upgrade must manually modify the codebase. The fix requires opening the server/Application/Home/Controller/PageController.class.php file and changing the $upload->allowExts variable assignment to $upload->exts.

Network-level mitigations provide an additional layer of defense while patching is underway. Organizations should deploy Web Application Firewall (WAF) rules to intercept POST requests targeting the upload endpoint that contain executable file extensions in the filename field.

Security teams must review the Public/Uploads/ directory for existing .php, .php5, or .phtml files. Any executable files found in this directory indicate prior exploitation and require immediate incident response procedures, including server isolation and forensic analysis.