CVE-2026-81889: elFinder SSRF Vulnerability

CVE-2026-81889 Overview

CVE-2026-81889 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in elFinder, an open-source file manager for web applications written in JavaScript with a PHP backend. The flaw affects versions prior to 2.1.70 and allows attackers to bypass SSRF protections in URL upload functionality. When PHP cURL is unavailable, elFinder falls back to fsock_get_contents(), which performs a second DNS resolution that attackers can exploit via DNS rebinding. Successful exploitation causes internal HTTP response bodies to be stored as uploaded files readable through elFinder.

Critical Impact
Unauthenticated network attackers can read internal services and cloud metadata endpoints by tricking elFinder into fetching loopback or private addresses, exposing sensitive infrastructure data.

Affected Products

elFinder versions prior to 2.1.70
Applications using elFinder php/elFinder.class.php URL upload feature
Deployments where the PHP cURL extension is unavailable or where get_headers() is invoked

Discovery Timeline

2026-08-31 - CVE-2026-81889 published to NVD
2026-08-31 - Last updated in NVD database

Technical Details for CVE-2026-81889

Vulnerability Analysis

The vulnerability stems from a Time-of-Check Time-of-Use (TOCTOU) flaw in elFinder's URL upload validation logic in php/elFinder.class.php. The validate_address() function validates the resolved IP address stored in $info['ip'] to prevent SSRF against internal targets. However, when PHP cURL is not installed, elFinder selects fsock_get_contents() as the fetch backend. This function connects using $arr['host'] and performs a second, independent DNS resolution.

An attacker controlling the DNS response can return a public address for the validation lookup and a loopback or private address for the subsequent connection lookup. This DNS rebinding attack causes elFinder to fetch content from internal hosts and store the response body as an uploaded file, which the attacker can then download.

A secondary blind SSRF exists even when curl_get_contents() is selected. After the fetch completes, elFinder calls get_headers($url, true) to retrieve headers using the original hostname without reusing the validated and pinned connection. This creates a separate request that bypasses the initial address validation.

Root Cause

The root cause is inconsistent host resolution between the validation and connection phases. The validation logic pins an IP address, but the transport layer performs a fresh DNS lookup, allowing rebinding attacks to change the destination between checks.

Attack Vector

An attacker submits a URL upload request pointing to a hostname under their control with a low DNS TTL. The authoritative DNS server alternates responses between a public IP address that passes validate_address() and an internal address such as 127.0.0.1 or 169.254.169.254 for cloud metadata services. The response body from the internal service is stored as a file and returned to the attacker through the elFinder interface.

The patch adds an errUploadUrlNoCurl error, requiring the PHP cURL extension for URL uploads and eliminating the vulnerable fsock_get_contents() fallback path.

javascript

// Patch adds new error string requiring cURL for URL uploads
'errUploadFileSize'    : 'File exceeds maximum allowed size.',
'errUploadMime'        : 'File type not allowed.',
'errUploadTransfer'    : '"$1" transfer error.',
'errUploadUrlNoCurl'   : 'URL upload requires the PHP cURL extension.',
'errUploadTemp'        : 'Unable to make temporary file for upload.',

Source: GitHub Commit 6d99738

Detection Methods for CVE-2026-81889

Indicators of Compromise

Unexpected files in elFinder upload directories containing HTML or JSON response bodies from internal services
Uploaded files with content matching cloud metadata service responses such as AWS Instance Metadata Service (IMDS) at 169.254.169.254
Outbound HTTP requests from web application servers to loopback, link-local, or RFC1918 addresses following URL upload commands

Detection Strategies

Monitor web application logs for elFinder upload commands with the upload[] parameter containing external URLs, particularly those resolving to short-TTL DNS records
Inspect uploaded file content for signatures of internal service responses, including metadata JSON structures and internal application banners
Correlate DNS query logs to identify hostnames returning both public and private IP addresses within short intervals

Monitoring Recommendations

Enable egress filtering logs on web servers hosting elFinder and alert on connections to internal address ranges
Deploy web application firewall (WAF) rules that inspect URL upload parameters for hostnames with suspicious DNS resolution patterns
Log and review all get_headers() and fsockopen() calls made from PHP request handlers

How to Mitigate CVE-2026-81889

Immediate Actions Required

Upgrade elFinder to version 2.1.70 or later, which fixes both the DNS rebinding path and the blind SSRF via get_headers()
Disable URL upload functionality in elFinder configuration if the feature is not required
Ensure the PHP cURL extension is installed on all servers running elFinder to avoid the vulnerable fsock_get_contents() fallback

Patch Information

The fix is released in elFinder 2.1.70. Review the GitHub Security Advisory GHSA-8x3q-jpjh-qh5c and the v2.1.70 release notes for details. The patch commits are available at commit 191372c and commit 6d99738.

Workarounds

Configure the elFinder connector to disable URL uploads by removing or restricting the upload command handler for remote URLs
Deploy network-level egress filtering that blocks outbound traffic from the web application to loopback, link-local (169.254.0.0/16), and RFC1918 ranges
Enforce IMDSv2 on AWS instances to require session tokens, preventing SSRF-based credential theft from 169.254.169.254

bash

# Example iptables egress filter to block SSRF targets from web server user
iptables -A OUTPUT -m owner --uid-owner www-data -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 169.254.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 192.168.0.0/16 -j REJECT