CVE-2026-81889

elFinder is an open-source file manager for web, written in JavaScript using jQuery UI. Prior to 2.1.70, elFinder URL uploads in php/elFinder.class.php can bypass server-side request forgery protections when PHP cURL is unavailable because validate_address() validates $info['ip'], but get_remote_contents() selects fsock_get_contents(), which connects to $arr['host'] and performs a second DNS resolution. An attacker able to submit a URL upload can use DNS rebinding to have the first resolution return a public address and the connection resolution return a loopback or private address, causing the internal HTTP response body to be stored as an uploaded file and made readable through elFinder. After a successful fetch, get_headers($url, true) separately requests the original hostname without reusing the validated and pinned connection, creating an additional blind server-side request forgery path even when curl_get_contents() is selected. This issue is fixed in version 2.1.70.

elFinder is an open-source file manager for web, written in JavaScript using jQuery UI. Prior to 2.1.70, elFinder URL uploads in php/elFinder.class.php can bypass server-side request forgery protections when PHP cURL is unavailable because validate_address() validates $info['ip'], but get_remote_contents() selects fsock_get_contents(), which connects to $arr['host'] and performs a second DNS resolution. An attacker able to submit a URL upload can use DNS rebinding to have the first resolution return a public address and the connection resolution return a loopback or private address, causing the internal HTTP response body to be stored as an uploaded file and made readable through elFinder. After a successful fetch, get_headers($url, true) separately requests the original hostname without reusing the validated and pinned connection, creating an additional blind server-side request forgery path even when curl_get_contents() is selected. This issue is fixed in version 2.1.70.

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

elFinder is an open-source file manager for web, written in JavaScript using jQuery UI. Prior to 2.1.70, elFinder URL uploads in php/elFinder.class.php can bypass server-side request forgery protections when PHP cURL is unavailable because validate_address() validates $info['ip'], but get_remote_contents() selects fsock_get_contents(), which connects to $arr['host'] and performs a second DNS resolution. An attacker able to submit a URL upload can use DNS rebinding to have the first resolution return a public address and the connection resolution return a loopback or private address, causing the internal HTTP response body to be stored as an uploaded file and made readable through elFinder. After a successful fetch, get_headers($url, true) separately requests the original hostname without reusing the validated and pinned connection, creating an additional blind server-side request forgery path even when curl_get_contents() is selected. This issue is fixed in version 2.1.70.

elFinder is an open-source file manager for web, written in JavaScript using jQuery UI. Prior to 2.1.70, elFinder URL uploads in php/elFinder.class.php can bypass server-side request forgery protections when PHP cURL is unavailable because validate_address() validates $info['ip'], but get_remote_contents() selects fsock_get_contents(), which connects to $arr['host'] and performs a second DNS resolution. An attacker able to submit a URL upload can use DNS rebinding to have the first resolution return a public address and the connection resolution return a loopback or private address, causing the internal HTTP response body to be stored as an uploaded file and made readable through elFinder. After a successful fetch, get_headers($url, true) separately requests the original hostname without reusing the validated and pinned connection, creating an additional blind server-side request forgery path even when curl_get_contents() is selected. This issue is fixed in version 2.1.70.

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