CVE-2026-81889 in elFinder
Summary
by MITRE • 08/31/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in elFinder prior to version 2.1.70 represents a critical failure in input validation and network connection handling within the PHP backend component responsible for processing URL-based file uploads. ElFinder, being an open-source web file manager built on JavaScript and jQuery UI, relies heavily on server-side operations when users request files from remote URLs. The core of this vulnerability lies in the disconnect between address validation logic and actual network execution paths. Specifically, the validate_address function performs a preliminary check by resolving the provided hostname to an IP address and verifying that it does not fall within reserved or private ranges. However, subsequent functions such as get_remote_contents do not reuse this validated connection state. Instead, when PHP cURL is unavailable in the server environment, the system falls back to using fsock_get_contents, which initiates a fresh network connection based on the hostname provided by the user rather than the previously resolved and validated IP address. This architectural flaw creates an opportunity for DNS rebinding attacks, where an attacker controls the Domain Name System records associated with their submitted URL.
In a typical exploitation scenario involving DNS rebinding, the attacker configures their domain to return different IP addresses depending on the timing of the query or specific request characteristics. The initial validation step resolves the hostname and receives a public-facing IP address that appears safe according to server-side protections. Consequently, the validate_address function passes this input as legitimate. However, when get_remote_contents executes its connection attempt via fsock_get_contents, it performs a second DNS resolution for the same hostname. If the attacker has manipulated their DNS records to return a loopback address such as 127.0.0.1 or a private internal IP range during this second lookup, the server will establish a connection with an internal resource that was not subject to the initial validation checks. This effectively bypasses Server-Side Request Forgery protections designed to prevent servers from accessing internal network resources. The result is that elFinder fetches the HTTP response body from these internal services and stores it as an uploaded file, which can then be accessed or downloaded by any user with access to the elFinder interface, leading to unauthorized data exposure of sensitive internal systems.
Beyond the DNS rebinding vector associated with fsock_get_contents, there exists a secondary vulnerability path even when curl_get_contents is selected due to improper handling of HTTP headers. After successfully fetching the remote content using cURL, the application calls get_headers to retrieve metadata about the response. This function initiates a separate HTTP request to the original hostname without reusing the connection established during the initial fetch operation. Because this second request does not leverage any previously validated or pinned IP address information, it is susceptible to DNS rebinding attacks similar to those affecting fsock_get_contents. An attacker can again manipulate DNS responses so that while the first cURL request targets a public resource, the subsequent get_headers request resolves to an internal service. This creates a blind Server-Side Request Forgery vector where the server makes requests to internal endpoints without proper authorization checks or IP validation during these secondary operations. The lack of connection pinning and consistent address verification across all network interactions within the upload process allows attackers to probe internal networks, potentially discovering sensitive services, exfiltrating data from intranet applications, or interacting with management interfaces that should remain inaccessible from external contexts.
This vulnerability aligns closely with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where the server makes requests based on user-supplied input without adequate validation of the destination address. Furthermore, it relates to CWE-20, Improper Input Validation, as the system fails to ensure that all network connections adhere to security policies regarding allowed IP ranges and hostnames. From an offensive perspective, this behavior maps to MITRE ATT&CK technique T1571, which covers Non-Standard Ports or Protocols often used in SSRF contexts, although here the primary mechanism is DNS manipulation rather than port evasion. The impact of such vulnerabilities can be severe, enabling attackers to perform network reconnaissance against internal infrastructure, access cloud metadata services if deployed on cloud platforms, read local files through file:// protocols if supported by the underlying HTTP client library, or interact with backend APIs that lack authentication mechanisms when accessed from localhost.
To mitigate this vulnerability, organizations must upgrade elFinder to version 2.1.70 or later where these logic flaws have been addressed. In environments where upgrading is not immediately feasible, administrators should ensure that PHP cURL extension is enabled and prioritized over fsock_get_contents if possible, although reliance on a single transport mechanism does not fully resolve the underlying design flaw regarding DNS resolution consistency. More robust mitigation strategies include implementing strict allowlists for IP addresses at the network perimeter or using reverse proxies to filter outbound requests from web applications. Additionally, developers should enforce connection pinning by resolving hostnames once and strictly reusing that specific IP address for all subsequent connections within a single transaction, thereby preventing DNS rebinding attacks. It is also advisable to disable unnecessary HTTP methods and restrict user-controlled URLs in file upload features to known trusted domains whenever possible, reducing the attack surface available for SSRF exploitation.