CVE-2026-81890 in elFinder
Summary
by MITRE • 09/01/2026
elFinder is an open-source file manager for web, written in JavaScript using jQuery UI. Prior to 2.1.70, the netmount command is omitted from elFinderConnector::$csrfProtectedCmds in php/elFinderConnector.class.php, so validateCsrfToken() is not called for this state-changing operation. In the shipped php/connector.minimal.php-dist configuration, FTP network mounts are enabled by default, and attacker-controlled protocol, host, path, port, user, pass, alias, and options arguments flow through elFinder::netmount() in php/elFinder.class.php to php/elFinderVolumeFTP.class.php. A cross-site request can therefore persist an attacker-chosen FTP mount in the victim's session, cause the PHP server to connect to an attacker-chosen FTP host and port, and send supplied credentials without an X-elFinder-CSRF token. This issue is fixed in version 2.1.70.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in elFinder prior to version 2.1.70 represents a critical failure in access control mechanisms, specifically manifesting as a Cross-Site Request Forgery (CSRF) flaw within the application's network mount functionality. ElFinder is widely deployed open-source file manager for web environments that relies on JavaScript and jQuery UI to provide users with intuitive file management capabilities. The core of this vulnerability lies in the PHP backend component elFinderConnector.class.php, where the netmount command was inadvertently omitted from the csrfProtectedCmds array. This configuration error means that the validateCsrfToken() function is not invoked when processing requests intended to establish new network mounts. Consequently, any state-changing operation related to mounting external storage systems bypasses the standard CSRF token validation process, leaving the application susceptible to unauthorized actions initiated by malicious actors through cross-site request forgery attacks.
The operational impact of this flaw is significantly amplified by the default configuration settings shipped with elFinder. In the provided php/connector.minimal.php-dist file, FTP network mounts are enabled by default without requiring explicit administrator intervention to activate them. This default state allows an attacker to exploit the missing CSRF protection directly against typical deployments. By crafting a malicious web page or email link that triggers a request to the vulnerable netmount endpoint, an attacker can force a victim's browser to send authenticated requests to elFinder on behalf of the logged-in user. The attack vector involves supplying attacker-controlled parameters including protocol, host, path, port, username, and password through the elFinder::netmount() method in php/elFinder.class.php, which subsequently passes these values to php/elFinderVolumeFTP.class.php. This results in two distinct security compromises: first, a persistent FTP mount is added to the victim's session under the attacker's control; second, the PHP server itself initiates an outbound connection to the maliciously specified FTP host and port, transmitting the supplied credentials without any CSRF token verification.
From a technical classification perspective, this vulnerability aligns with CWE-352, which describes Cross-Site Request Forgery (CSRF). The absence of anti-CSRF tokens for state-changing operations allows attackers to perform actions that authenticated users would otherwise have permission to execute but did not intend to initiate. Furthermore, the ability to force the server to connect to arbitrary external hosts and transmit credentials introduces elements associated with CWE-209, which involves the generation of error messages containing sensitive information, although in this case, the primary risk is unauthorized access rather than data leakage via errors. In terms of adversary tactics, this exploit maps directly to MITRE ATT&CK technique T1566.002, specifically Spearphishing Link, where an attacker sends a malicious link that triggers actions on behalf of the victim in a trusted application. The persistence aspect of adding a mount point also relates to lateral movement or data exfiltration preparation if the mounted FTP server is under attacker control.
The consequences of this vulnerability extend beyond simple unauthorized configuration changes. By persisting an attacker-chosen FTP mount, the adversary gains persistent access to files stored on external servers through the victim's authenticated session. This can lead to unauthorized data retrieval, modification, or deletion depending on the permissions associated with the mounted volume. Additionally, the server-side connection initiated by PHP poses a risk of Server-Side Request Forgery (SSRF) characteristics if the internal network is accessible via the specified FTP host and port, potentially allowing further reconnaissance or exploitation of internal services that are not directly exposed to the internet. The transmission of credentials in plaintext over FTP also exposes sensitive authentication data to potential interception if the connection is not secured with TLS, although the primary vulnerability remains the lack of CSRF protection rather than encryption weaknesses.
Mitigation strategies for this issue involve immediate upgrading to elFinder version 2.1.70 or later, where the netmount command has been correctly added to the csrfProtectedCmds list and validateCsrfToken() is enforced for all state-changing operations. For organizations unable to upgrade immediately due to compatibility constraints, a temporary workaround involves manually modifying the php/elFinderConnector.class.php file to include netmount in the protected commands array or disabling FTP network mounts entirely if they are not required by business processes. Administrators should also review their connector configuration files to ensure that unnecessary features like remote mounting are disabled unless explicitly needed, thereby reducing the attack surface. Implementing strict Content Security Policy headers and ensuring that session cookies have appropriate flags can provide additional layers of defense against CSRF attacks in broader application contexts. Regular security audits and code reviews focusing on state-changing API endpoints are essential to prevent similar omissions in future development cycles.