Summary
elFinder: ZIP extraction bypasses uploadDeny MIME filter allowing PHP file upload (RCE)
elFinder provides uploadDeny and uploadAllow options in its connector configuration to restrict which MIME types may be uploaded. When uploadDeny includes text/x-php, direct upload of .php, .phtml, and .phar files is correctly blocked. However, the extract command (ZIP decompression) internally calls checkExtractItems(), which invokes mimetypeInternalDetect() directly without passing the result through mimeTypeNormalize(). Because phtml, phar, and similar PHP-executable extensions are absent from mime.types, they are not resolved to text/x-php at the detection stage, causing the MIME filter to be silently bypassed. An attacker who is permitted to upload ZIP archives can therefore extract PHP-executable files into the web-accessible files/ directory. If the server is configured to execute the affected extension (e.g., .phtml, .phar) as PHP, which is the case in common Apache and Nginx deployments, this results in Remote Code Execution.
Details
elFinder's MIME validation pipeline for direct uploads (upload command) is:
mimetype()
└─ mimetypeInternalDetect() // stage 1: extension → MIME via mime.types
└─ mimeTypeNormalize() // stage 2: apply staticMimeMap
phtml:* → text/x-php
phar:* → text/x-php
php5:* → text/x-php
└─ allowPutMime() // blocked: text/x-php ∈ uploadDeny
The extract command (checkExtractItems() in elFinderVolumeDriver.class.php, line 7110) uses a shortened pipeline:
// line 7110, stage 2 (mimeTypeNormalize) is never called
if ($chkMime
&& ($mimeByName = elFinderVolumeDriver::mimetypeInternalDetect($name))
&& !$this->allowPutMime($mimeByName)) {
Because phtml and phar are not present in mime.types, mimetypeInternalDetect() returns a generic type (e.g., application/octet-stream) for these extensions. Without mimeTypeNormalize(), the staticMimeMap entries that would map phtml:* → text/x-php are never applied, so allowPutMime() sees a non-blocked MIME and permits extraction.
Affected extensions confirmed: .phtml, .phar, .php5, .php3
Not bypassed: .php (present in mime.types, detected as text/x-php in stage 1)
PoC
Requirements:
- elFinder 2.1.69 deployed under Apache/Nginx (PHP-FPM or mod_php)
- Connector configured with
uploadDeny = ['text/x-php']anduploadAllowincludingapplication/zip files/directory served under a public web path
Step 1, Confirm direct upload is blocked
Open elFinder in a browser and click the Upload button.
Select hello.phtml (content: <?php phpinfo(); ?>).
→ Upload is rejected with: "Upload file hello.phtml: File type not allowed (text/x-php)"
Step 2, Upload a ZIP containing the payload
Create bypass.zip containing hello.phtml.
Upload bypass.zip via the Upload button.
→ ZIP is accepted (MIME: application/zip ∈ uploadAllow).
Step 3, Extract the ZIP
Right-click bypass.zip in the file list → Extract files.
→ hello.phtml appears in the file list without any error.
→ File is now present at {files_dir}/hello.phtml on the server.
Step 4, Execute the extracted PHP file
Navigate to:
http://<target>/elFinder/files/hello.phtml
→ Apache processes the file as PHP and renders the full phpinfo() output, confirming Remote Code Execution.
Payload used in PoC: <?php phpinfo(); ?> (benign, demonstrates execution only)
Impact
Any user with ZIP upload permission can bypass the uploadDeny MIME restriction, place PHP-executable files in a web-accessible directory, and achieve Remote Code Execution on the server.
Concrete impact:
- Arbitrary PHP code execution on the web server
- Full server environment disclosure via
phpinfo()(paths, PHP version, loaded modules, environment variables) - Potential access to server filesystem, database credentials, and internal network services
- Complete compromise of the web application if an attacker substitutes
phpinfo()with a web shell (e.g.,<?php system($_GET['cmd']); ?>)
Extensions confirmed executable on Apache (default config):
phtml, phar, php5, php3
Recommended fix:
Apply mimeTypeNormalize() inside checkExtractItems() so that the full MIME pipeline is used consistently:
// elFinderVolumeDriver.class.php, line 7110
// Before (vulnerable):
$mimeByName = elFinderVolumeDriver::mimetypeInternalDetect($name)
// After (fixed):
$mimeByName = $this->mimeTypeNormalize(
elFinderVolumeDriver::mimetypeInternalDetect($name),
$name,
pathinfo($name, PATHINFO_EXTENSION)
)
The application accepts file uploads without adequately restricting the file type or content. Typical impact: remote code execution if the uploaded file can be served and executed on the server.
CVE-2026-81891 has a CVSS score of 8.1 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.1.70); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-81891? CVE-2026-81891 is a high-severity unrestricted upload of dangerous file types vulnerability in Studio-42/elFinder (composer), affecting versions < 2.1.70. It is fixed in 2.1.70. The application accepts file uploads without adequately restricting the file type or content.
- How severe is CVE-2026-81891? CVE-2026-81891 has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of Studio-42/elFinder are affected by CVE-2026-81891? Studio-42/elFinder (composer) versions < 2.1.70 is affected.
- Is there a fix for CVE-2026-81891? Yes. CVE-2026-81891 is fixed in 2.1.70. Upgrade to this version or later.
- Is CVE-2026-81891 exploitable, and should I be worried? Whether CVE-2026-81891 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-81891 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-81891? Upgrade
Studio-42/elFinderto 2.1.70 or later.