CVE-2021-47753: Unauthenticated File Upload Leads to Full Server Takeover in phpKF CMS

CVE: CVE-2021-47753
Product: phpKF CMS 3.00 Beta y6
Severity: Critical
CVSS (v3.1): 9.8 (Critical)
Exploitability:

Can be triggered remotely over the network
No user credentials needed
Attack complexity is low
Results in full remote code execution

Official patch / upgrade:
🔗 Download the fixed or latest version of phpKF CMS from the official phpKF download page: https://www.phpkf.com/indirme.php

What the vulnerability actually is

This vulnerability exists because the phpKF CMS version 3.00 Beta y6 does not properly check file uploads. In normal secure systems, when someone uploads an image, the server checks the file contents to make sure it really is an image and not a script. In this case, the application only looks at the file name or the reported file type and trusts it — which is dangerous.

Because of that, an attacker can take a file that contains PHP code (a script that runs on the server), name it something innocent-looking like avatar.php.png, and submit it through the upload feature. The system blindly accepts it and places it where uploads go.

Once the file is on the server, an attacker can rename it if needed and then browse to it in the web browser. Because the server interprets .php as code, the attacker now controls a script on the server that can take commands and run them — this is remote code execution.

In simple terms: any stranger on the internet could upload a tiny script that acts like a backdoor, and then use that to run commands on the server without ever needing a login.

How an attacker exploits it

Find a vulnerable site running phpKF CMS 3.00 Beta y6 exposed to the web.
Craft a malicious file — typically a small PHP backdoor script or web shell.
Upload that file through the CMS upload feature, disguising it as an image.
The CMS accepts it because it doesn’t validate correctly.
The attacker either:
- Uses built-in rename/move functions to set it to something like shell.php, or
- Uploads it directly with a .php extension that gets placed where web files run.
Invoke the uploaded script by visiting it in a web browser, passing commands.
Example: http://target/uploads/shell.php?cmd=whoami
The system executes the command and returns the result — full remote access.

This means the attacker can do anything the webserver account is allowed to do: create files, read sensitive data, escalate, pivot, and more.

Detecting exploitation and PoC behavior

To catch or investigate if someone is abusing this vulnerability, you need the right logs and monitoring.

Log sources to look at

Web server access logs

Apache (/var/log/apache2/access.log)
Nginx (/var/log/nginx/access.log)
Other web stacks log similar files

These logs show every HTTP request. Look for:

POST requests to upload endpoints with unusual large bodies
Requests that include double extensions (e.g., avatar.php.png)
Access to newly uploaded .php files in non-standard places

Web server error logs

Look for errors from executing odd scripts, permission errors for unexpected files

Application logs

If phpKF logs upload actions or file operations, correlate newly created files with suspicious log entries

File system monitoring
Tools like AIDE, tripwire, or OSSEC can tell you when a new .php file appears in an uploads/ directory where normally only images should be.

Signs of compromise

Be suspicious if you see:

POST requests to upload endpoints where the request body contains <?php or unusual binary data
Uploads of file names with multiple dots or odd extensions
Requests like GET /uploads/shell.php?cmd=*
New files created at times that don’t match known updates or admin activity
Web server processes spawning unusual children (php invoking shells, unexpected commands)

Detection rules you can use

Below are example Suricata rules and patterns defenders have used to flag potential exploitation attempts. These focus on suspicious upload content and web shell access patterns.

Suricata rule — detect PHP code in upload body

alert http any any -> any any (msg:"WEB-ATTACK PHP code in upload body detected"; \
flow:established,to_server; http_client_body; content:"<?php"; nocase; \
file_data; sid:9000001; rev:1;)

This watches for <?php in the upload stream — a classic sign of a script being sent instead of an image.

Suricata rule — suspicious access to web shell files

alert http any any -> any any (msg:"WEB-ATTACK Suspicious access to .php in upload area"; \
http.uri; pcre:"/\/uploads\/.*\.php(\?.*)?$/"; \
classtype:web-application-attack; sid:9000002; rev:1;)

This triggers when someone reaches a .php file inside an upload directory — very unusual for a legitimate upload use case.

Additional detection logic for SIEM

You can automate detection with SIEM or log analysis. Examples:

Search for upload content with PHP

index=web_logs (method=POST AND request_uri="/uploads" AND body:"<?php")

Detect double extensions

index=web_logs request_uri matches "\.[A-Za-z0-9_-]+\.php(\?.*)?"

Correlate file creation

Monitor file audit trails or FIM logs for creation of .php files in upload directories, then match those timestamps to web server logs.

How defenders think about this

Attackers aim to bypass checks and get a script that the server will run. Defenders focus on:

Preventing dangerous content from ever being accepted
Blocking execution of user-supplied files
Watching for anomalies in upload behavior
Generating alerts when things don’t match expected patterns

Mitigation and hardening steps

Even after you upgrade using the official link above, it’s smart to:

Make upload directories non-executable (no PHP processing)
Validate file contents on the server side — don’t trust extensions
Restrict allowed file types to actual image formats
Implement size and content scanning rules
Use a web application firewall to block odd upload attempts

Final Takeaway

This vulnerability lets a stranger upload a little program onto your website and run it without a password. That alone can let them take over the site, steal data, or use the server for much worse things. Because there’s a reliable proof-of-concept that shows exactly how to do this, the risk is high — especially if the site is public on the internet.