CVE-2026-15488: shiroiAdmin File Upload RCE Vulnerability

CVE-2026-15488 Overview

CVE-2026-15488 is an unrestricted file upload vulnerability in hcr707305003 shiroiAdmin versions 1.1 and 1.3. The flaw resides in the FileController::upload function within app/common/controller/FileController.php. Attackers can manipulate the File argument to upload arbitrary files without proper restriction. The vulnerability is remotely exploitable over the network without authentication or user interaction. Public disclosure of the exploit has occurred, and the vendor did not respond to disclosure attempts. The issue is tracked under [CWE-284: Improper Access Control] and is fixed in version 1.4 via commit 3ecde28ea8a20a3840dbfefd6d6863ee79a83e70.

Critical Impact

Remote unauthenticated attackers can upload arbitrary files to the server, potentially enabling webshell deployment and further compromise of the hosting environment.

Affected Products

• shiroiAdmin version 1.1
• shiroiAdmin version 1.3
• Component: app/common/controller/FileController.php

Discovery Timeline

• 2026-07-12 - CVE-2026-15488 published to NVD
• 2026-07-13 - Last updated in NVD database
• Patch commit - 3ecde28ea8a20a3840dbfefd6d6863ee79a83e70 merged into version 1.4

Technical Details for CVE-2026-15488

Vulnerability Analysis

The vulnerability resides in the public upload method of FileController, which handles multipart file uploads. The pre-patch implementation accepts a file field and destination directory directly from user-supplied request parameters. It derives the file type from get_file_type($file->getOriginalName()) without enforcing an allowlist of permitted MIME types or extensions. This design allows an attacker to submit executable server-side content, such as PHP scripts, through the standard upload endpoint. Because the endpoint operates under the /common/file/upload route accepting POST requests, exploitation requires only a crafted HTTP request. Successful uploads land in the uploads directory, which is typically web-accessible.

Root Cause

The root cause is missing validation of both file extension and content type before persisting user-supplied files. The controller trusted client-provided parameters for the destination path and field name. It relied on filename-derived type detection instead of enforcing a strict allowlist. This maps to [CWE-284] Improper Access Control over resource creation.

Attack Vector

A remote unauthenticated attacker sends a POST request to the upload endpoint with a malicious file payload. The attacker controls the file_field and file_dir parameters and the uploaded content. Once written, the attacker requests the file over HTTP to trigger server-side execution.

// Pre-patch vulnerable logic in FileController::upload
class FileController extends CommonBaseController
{
    public function upload(Request $request)
    {
        if ($request->isPost()) {
            $files = $request->file();
            if(empty($files)) {
                return common_error('文件未上传');
            }
            $param = $request->param();
            $field = $param['file_field'] ?? 'file';
            $dir   = $param['file_dir'] ?? 'uploads';
            /** @var UploadedFile $file */
            $file  = $files[$field];
            // File type inferred from attacker-controlled filename
            $file_type = $param['file_type'] ?? get_file_type($file->getOriginalName());
            // Uploaded without extension/MIME allowlist enforcement
        }
    }
}

Source: GitHub Commit 3ecde28

Detection Methods for CVE-2026-15488

Indicators of Compromise

• New files with executable extensions such as .php, .phtml, or .phar appearing in the uploads directory or any directory referenced by the file_dir parameter.
• POST requests to /common/file/upload originating from unauthenticated sessions or unusual source addresses.
• Web server access log entries showing subsequent GET requests to newly uploaded files in upload directories.

Detection Strategies

• Inspect HTTP request bodies to the upload endpoint for non-image MIME types and script-language filename patterns.
• Compare the uploads directory contents against a known-good baseline and alert on files with server-executable extensions.
• Correlate upload events with subsequent execution requests to the same file path within a short time window.

Monitoring Recommendations

• Enable web server logging with full URI and request body size for the /common/file/upload route.
• Monitor the web root and upload directories with file integrity monitoring for new PHP or script files.
• Alert on outbound network connections initiated by the PHP-FPM or web server process to unexpected destinations after upload events.

How to Mitigate CVE-2026-15488

Immediate Actions Required

• Upgrade shiroiAdmin to version 1.4, which includes commit 3ecde28ea8a20a3840dbfefd6d6863ee79a83e70.
• Audit the uploads directory and any custom file_dir locations for unauthorized script files and remove them.
• Restrict access to the /common/file/upload endpoint using authentication middleware if the application exposes it publicly.

Patch Information

The vendor released the fix in version 1.4. Review the GitHub Release v1.4 and the patch commit for exact code changes. Additional context is available in the VulDB CVE Report.

Workarounds

• Configure the web server to deny script execution within upload directories using directives such as php_flag engine off or equivalent Nginx location rules.
• Place a Web Application Firewall (WAF) rule that blocks uploads whose filename ends in server-executable extensions.
• Apply strict server-side allowlists for file extensions and validate MIME types independently of the client-supplied filename.

# Nginx configuration example to disable PHP execution in upload paths
location ^~ /uploads/ {
    location ~* \.(php|phtml|phar|php5|php7)$ {
        deny all;
        return 403;
    }
}