CVE-2026-81889: Server-Side Request Forgery via DNS Rebinding in elFinder

elFinder is a popular open-source, web-based file manager implemented using a JavaScript front-end and a PHP back-end. The application exposes multiple API endpoints to facilitate file administration, including a feature that allows users to upload files directly from a remote URL. This capability exposes a significant network-facing attack surface, as the server must initiate outbound HTTP requests to user-supplied destinations.

CVE-2026-81889 is a critical Server-Side Request Forgery (SSRF) vulnerability residing in this remote upload mechanism. The flaw belongs to the Time-of-Check to Time-of-Use (TOCTOU) security bug class and permits unauthenticated remote attackers to bypass address validation controls. Successful exploitation allows the server to connect to arbitrary internal network resources, local loopback services, or cloud metadata endpoints.

The primary vulnerability vector is triggered via a DNS rebinding technique. When the host environment lacks the PHP cURL extension, elFinder falls back to native socket functions that do not pin the resolved IP address between validation and connection. This allows an attacker to route requests to restricted internal environments, effectively using the vulnerable host as a proxy to retrieve sensitive internal system data.

The vulnerability resides in the remote file fetching sequence defined in php/elFinder.class.php. When a client requests a remote file upload by submitting a URL, the application calls validate_address($url) to prevent SSRF attempts. This validation function resolves the host domain name, extracts its IP address, and verifies that the destination does not reside within reserved, local, or private IP spaces such as 127.0.0.0/8, 10.0.0.0/8, or 192.168.0.0/16.

The core structural flaw manifests when the PHP cURL extension is either missing or disabled on the server hosting the application. In this scenario, elFinder falls back to a legacy network fetching method named fsock_get_contents(). This function relies on PHP's native socket connection wrapper fsockopen() to establish a raw TCP connection and fetch the target HTTP resource.

The TOCTOU vulnerability is introduced because validate_address() and fsock_get_contents() operate independently and perform separate DNS resolutions. While validate_address() correctly resolves and inspects the IP address, it does not pass the validated IP address downstream to the socket function. Instead, fsock_get_contents() receives the original, unpinned hostname string and passes it to fsockopen(), which forces a second, out-of-band DNS resolution.

By leveraging a DNS rebinding server with a Time-To-Live (TTL) value of zero, an attacker can manipulate these two separate DNS resolution events. The first query resolves to a benign public IP to satisfy the checks in validate_address(). The second query, executed fractions of a second later by fsockopen(), resolves to a target internal IP address, bypassing the validation logic entirely.

To understand the vulnerability mechanics, we must analyze the interaction between validation and socket connection in the vulnerable version of php/elFinder.class.php. The legacy connection method fsock_get_contents() initiates the outbound connection using the original hostname string $arr['host'] instead of the pre-validated IP address. This decoupling of the validation step from the connection step exposes the application to DNS rebinding.

// Legacy vulnerable path in php/elFinder.class.php
protected function get_remote_contents(&$url, $timeout = 30, $redirect_max = 5, $ua = 'Mozilla/5.0', $fp = null)
{
    if (preg_match('~^(?:ht|f)tps?://~i', $url)) {
        $info = $this->validate_address($url);
        if ($info === false) {
            return false;
        }
        // Insecure fallback if cURL functions do not exist
        $method = (function_exists('curl_exec')) ? 'curl_get_contents' : 'fsock_get_contents';
        return $this->$method($url, $timeout, $redirect_max, $ua, $fp, $info);
    }
    return false;
}

Additionally, the legacy code executed a secondary blind SSRF vector via the PHP native function get_headers($url, true). This function was used to inspect the Content-Disposition header to determine the file name after a successful fetch. Because get_headers() initiates a new HTTP request without reusing the previously validated socket or connection state, it created a separate, unpinned network request that was also susceptible to DNS rebinding exploitation.

The patch implemented in commit 6d997386cd0f1abab4706c220b46b0aea0ecff51 resolves these flaws by removing the fallback socket connection mechanism entirely. The fsock_get_contents() function is deprecated and marked as inactive, making the PHP cURL extension a strict requirement for remote URL uploads. Under the updated architecture, if curl_init or curl_exec are unavailable, the application immediately aborts the transaction and returns ERROR_UPLOAD_URL_NO_CURL.

// Patched path in php/elFinder.class.php
protected function get_remote_contents(&$url, $timeout = 30, $redirect_max = 5, $ua = 'Mozilla/5.0', $fp = null)
{
    $this->remoteContentHeaders = array();
    $this->remoteContentError = '';
    if (preg_match('~^(?:ht|f)tps?://~i', $url)) {
        if (!function_exists('curl_init') || !function_exists('curl_exec')) {
            $this->remoteContentError = self::ERROR_UPLOAD_URL_NO_CURL;
            return false;
        }
        $info = $this->validate_address($url);
        if ($info === false) {
            return false;
        }
        return $this->curl_get_contents($url, $timeout, $redirect_max, $ua, $fp, $info);
    }
    return false;
}

The patch also eliminates the out-of-band get_headers() request. Instead of performing a separate HTTP query to read headers, the application registers a header callback function named curlHeader using CURLOPT_HEADERFUNCTION. This callback parses and stores the response headers in-memory during the single, secure, pinned cURL transaction, allowing the safe extraction of Content-Disposition values via getRemoteContentDispositionFileName().

An attack targeting CVE-2026-81889 begins with the configuration of a malicious DNS server. The attacker registers a domain, such as rebind.evil.com, and configures the authoritative nameserver to respond with a TTL of 0 seconds. The nameserver is programmed to alternate its responses: the first query returns a safe public IP (e.g., 93.184.216.34), and the subsequent query returns a local or loopback address (e.g., 127.0.0.1 or 169.254.169.254).

The attacker then submits an HTTP request to the elFinder connector endpoint, specifying the target URL as http://rebind.evil.com/metadata/v1/user-data. The target server, lacking the PHP cURL extension, falls back to the native socket handler. The first DNS lookup occurs when validate_address() is executed, receiving the public IP address 93.184.216.34 and validating it as a safe destination.

Immediately after validation, fsock_get_contents() initiates a connection via fsockopen(). Because the DNS record has a TTL of 0, the local resolver bypasses its cache and issues a second DNS query to the authoritative nameserver. The malicious nameserver responds with 169.254.169.254 (the AWS Instance Metadata Service IP), and the application establishes a TCP connection to this internal cloud endpoint.

Once the connection is established, the application retrieves the cloud metadata response and stores the payload in a temporary file. Because elFinder is a web-based file manager, the newly uploaded "file" is saved within the target volume and exposed to the user interface. The attacker then downloads or views this file directly through the client, successfully exfiltrating cloud credentials or internal configuration files.

The security impact of CVE-2026-81889 is classified as High, represented by a CVSS v3.1 base score of 8.6. The vulnerability receives an AV:N (Network) vector because it is exploitable remotely without network positioning constraints. The AC:L (Low) rating indicates that the exploitation process is highly reliable once the fallback condition is met and does not require complex environmental configurations.

The Scope parameter is set to Changed (S:C), which is the critical driver of the severity. This indicates that the vulnerability allows an attacker to cross security boundaries, shifting the impact from the localized web application container to the wider internal network. Through this vector, the web server is leveraged as an internal proxy, exposing private network infrastructures that are typically shielded from public internet access.

Confidentiality impact is rated as High (C:H) because the vulnerability enables full read access to local services. This includes local loopback services (such as administrative panels, Redis databases, or databases running on localhost) and cloud metadata services. Compromising cloud metadata endpoints can expose temporary IAM credentials, potentially resulting in full compromise of the hosting cloud account.

The primary remediation for this vulnerability is upgrading the elFinder installation to version 2.1.70 or later. This release enforces cURL-only transactions, completely removing the insecure socket fallback path fsock_get_contents(). Additionally, organizations must verify that the PHP cURL extension is active on the hosting system by checking the output of phpinfo() or ensuring extension=curl is enabled in the active php.ini file.

For environments where an immediate application upgrade is not feasible, security administrators should implement network-level containment controls. Restricting outbound egress traffic from the web server is highly effective. Firewalls or routing tables should be configured to drop any outbound connections initiated by the web server service pointing to RFC 1918 private subnets (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud link-local metadata addresses (169.254.169.254).

Furthermore, local application firewalls or web application firewalls (WAF) can be configured to inspect incoming requests to the elFinder connector. Implementing input validation rules that block requests containing target parameters with domains resolved to loopback spaces or anomalous DNS structures can help mitigate exploitation attempts. Developers must also learn from this flaw by ensuring that validation and connection states are pinned to the same resolved IP address to prevent TOCTOU vulnerabilities.