elFinder EUVD-2026-68768

The primary exploitation path requires PHP without the cURL extension installed, forcing get_remote_contents() into the fsock_get_contents() fallback; on any PHP installation where cURL is enabled, this path is blocked. The attacker must additionally have access to elFinder's URL upload functionality - whether that endpoint requires authentication depends entirely on how the integrating application configures the elFinder connector (the GHSA notes that connectors can be deployed without authentication). The attacker must control a DNS server capable of returning low or zero TTL responses to facilitate the dual-resolution race, and the PHP process must have network-level connectivity to the targeted internal host. The MIME type returned by the internal service must match a type permitted by elFinder's upload configuration, limiting which internal endpoints are exploitable. A secondary blind SSRF via get_headers() applies to all deployments regardless of cURL availability, requiring only URL upload access without the no-cURL precondition.

The CVSS 8.6 vector (S:C/C:H) accurately reflects that SSRF can cross security boundaries and expose full internal HTTP response bodies - the non-blind nature amplifies the severity. However, the AC:L metric likely overstates exploitability: DNS rebinding requires the attacker to operate a DNS server with zero-TTL records and successfully exploit a timing race between two independent DNS lookups, which in practice introduces meaningful real-world complexity. The primary exploitation path also requires PHP without the cURL extension, which is non-default in well-maintained PHP deployments; organizations running PHP with cURL installed are only exposed to the secondary get_headers() blind SSRF path. No EPSS data was provided. KEV status is absent, indicating no confirmed mass exploitation. A public proof-of-concept is confirmed available (poc.zip attached to GHSA-8x3q-jpjh-qh5c), meaning a motivated attacker with DNS infrastructure can reproduce the attack. Realistic priority: high for elFinder deployments on cURL-less PHP with publicly or lightly authenticated URL upload endpoints; moderate for cURL-enabled deployments pending the 2.1.70 patch.

An attacker registers a domain backed by a controlled DNS server configured to serve near-zero TTL A records, initially returning a public IP that passes elFinder's validate_address() blocklist check, then rapidly re-resolving to 127.0.0.1 or an internal address before fsock_get_contents() opens the TCP connection. The internal service response - such as AWS instance metadata from 169.254.169.254 or an unauthenticated internal API - is saved as an uploaded file in elFinder, which the attacker then retrieves via the file manager's standard read interface. A proof-of-concept demonstrating this full non-blind read-back path is publicly available in the GHSA advisory.