Listen to this Post
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
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.
Technical details:
`validate_address()` resolves the supplied hostname with gethostbyname(), rejects loopback and private ranges, and stores the accepted address in $info['ip']. `get_remote_contents()` then selects cURL when available, otherwise fsock_get_contents(). The cURL implementation correctly pins the validated IP using CURLOPT_RESOLVE. However, the socket fallback ignores `$info[‘ip’]` and connects using $arr['host']:
$fp = fsockopen( $ssl . $arr['host'], $arr['port'], $errno, $errstr, $connect_timeout );
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. 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, select "Upload" and paste the URLhttp://rebind.test:9001/secret.txt`. The PoC DNS server responds as follows:
– first A resolution -> 203.0.113.10
– subsequent A resolutions -> 127.0.0.1
The observed content is INTERNAL_SECRET_MANUAL. `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.
DailyCVE Form:
Platform: elFinder 2.1.69
Version: 2.1.69 (commit 8f2c3ff)
Vulnerability: SSRF protection bypass
Severity: High (8.6 CVSS)
Date: 24/07/2026
Prediction: Patch expected Q3 2026
What Undercode Say:
Analytics show the vulnerability stems from a TOCTOU (Time-of-Check to Time-of-Use) issue in DNS resolution. The `validate_address()` function performs an initial check using gethostbyname(), but the subsequent `fsockopen()` call performs a second DNS lookup on the original hostname rather than using the validated IP. This creates a race condition window where an attacker can manipulate DNS responses between the validation and connection phases.
The cURL code path is secure because it pins the IP using CURLOPT_RESOLVE. However, when cURL is unavailable, the fallback path remains vulnerable. The issue also persists across HTTP redirects, as each redirect triggers a fresh validation followed by a new connection using the hostname.
Exploit: (Educational Purposes!)
To reproduce the attack:
- Set up a DNS server with low TTL (e.g., 0 or 1 second) for a domain like `rebind.test`
2. Configure the DNS server to return a public IP (e.g.,203.0.113.10) on the first query - Configure the DNS server to return a loopback or private IP (e.g.,
127.0.0.1) on subsequent queries - Submit the URL
http://rebind.test:9001/secret.txt` to elFinder's URL upload203.0.113.10`
<h2 style="color: blue;">5. The validation passes because it sees - The socket connection performs a second DNS lookup and connects to `127.0.0.1:9001`
7. The internal response is saved and accessible via elFinder
Alternative redirect-based exploitation:
http://rebind.test:9001/redirect-secret
Protection:
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.
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.
Additional observation:
After a successful URL fetch, the upload path 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.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
