Summary
WuzhiCMS 5.0.0 contains an unrestricted file-upload vulnerability in its thumbnail-upload endpoint. An authenticated low-privileged member may upload a server-executable file, which could allow arbitrary PHP code execution when the file is later requested from the web-accessible upload directory.
Affected context
The issue occurs in deployments that expose the member thumbnail-upload functionality and store uploaded files in a web-accessible directory. Risk is increased when the application accepts client-supplied extensions without an allowlist or content validation and the web server is configured to execute script files from the upload location.
Exploit preconditions
- Attack surface: The member thumbnail-upload endpoint - Required access: An authenticated account with permission to use the
upload function
- Trigger point: Processing and storage of a crafted file upload, followed
by access to the stored file
- Why exploitation is possible: The application trusts the filename extension,
does not adequately validate file content, and places the result in a
web-accessible directory where the server may execute PHP
Why this happens
The vulnerability results from treating a client-controlled filename and uploaded file as trusted content. The application preserves the supplied extension without applying a narrowly defined allowlist or verifying that the content matches an approved image type, then stores the file in a directory capable of serving executable scripts. This behavior maps to CWE-434, Unrestricted Upload of File with Dangerous Type.
Potential impact
An attacker may execute arbitrary PHP code with the web server's privileges.; The application could be compromised or altered.; Sensitive data may be accessed or modified.; The compromised server could be used for further internal access or malware hosting.
General mitigation guidance
Mitigation generally focuses on reducing trust in uploaded filenames and content, and on separating uploaded data from executable application code. Common defensive patterns include enforcing a strict server-side allowlist of permitted file types, validating file signatures and image structure, and generating storage names rather than preserving client-supplied extensions. Uploaded content is commonly stored outside the web root or served through a non-executing handler, with execution disabled for upload directories. Access controls can limit who may upload, while least-privilege service accounts and restrictive filesystem permissions reduce the consequences of a successful upload.
How teams detect issues like this
Detection approaches can include static analysis for upload handlers that concatenate or preserve user-controlled filenames, missing extension allowlists, absent content-signature checks, and writes to web-accessible paths. Code review should examine whether upload directories permit script execution and whether authorization is enforced independently of file validation. Runtime monitoring can alert on executable extensions, unexpected MIME and content mismatches, and requests for newly created files in upload locations. CI policy checks and automated review tools may help enforce approved upload and storage patterns.
