elFinder: SSRF protection bypass via DNS rebinding in the `fsock_get_contents()` fallback

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 - [email protected]