{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.69"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "studio-42/elfinder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.70"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-81889"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-31T20:28:06Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "[poc.zip](https://github.com/user-attachments/files/30352020/poc.zip)\n## Summary\n\nelFinder 2.1.69 is vulnerable to a Server-Side Request Forgery (SSRF) protection bypass when PHP cURL is unavailable and URL uploads use the `fsock_get_contents()` fallback.\n\nAn attacker who can submit a URL for server-side upload can use an attacker-controlled DNS hostname that initially resolves to an allowed public IP address and subsequently resolves to a loopback or private IP address.\n\nThe URL validation checks the first resolved IP, but `fsock_get_contents()` opens the actual connection using the original hostname. This causes a second DNS resolution and allows the connection to reach an address different from the one that was validated.\n\nThe response from the internal service is saved as an uploaded file and can be read through elFinder. This makes the demonstrated issue a non-blind SSRF.\n\nThe most accurate classification is:\n\n* Vulnerability: SSRF protection bypass \n* Exploitation technique: DNS rebinding\n* Root cause: TOCTOU/double DNS resolution without IP pinning\n\n## Affected versions\n\nConfirmed affected:\n\n* elFinder 2.1.69, commit `8f2c3ffafcdd52cf4515f1eec172f4eee44552ad`\n* the current `master` branch inspected on 24 July 2026\n\nThe earliest affected version has not been determined.\n\n## Preconditions\n\nThe demonstrated readback path requires:\n\n* PHP without the cURL extension (`curl_exec()` unavailable);\n* access to the URL upload functionality;\n* permission to upload a MIME type returned by the target service;\n* network connectivity from the PHP process to the internal target;\n* DNS resolution behavior compatible with low or zero TTL responses.\n\nAuthentication requirements depend on the application integrating the elFinder connector. The attached reproduction connector is intentionally minimal and unauthenticated.\n\n## Technical details\n\n`validate_address()` resolves the supplied hostname with `gethostbyname()`, rejects loopback and private ranges, and stores the accepted address in `$info[\u0027ip\u0027]`:\n\nhttps://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2587-L2655\n\n`get_remote_contents()` then selects cURL when available, otherwise `fsock_get_contents()`:\n\nhttps://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2673-L2689\n\nThe cURL implementation correctly pins the validated IP using `CURLOPT_RESOLVE`:\n\nhttps://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2709-L2736\n\nHowever, the socket fallback ignores `$info[\u0027ip\u0027]` and connects using `$arr[\u0027host\u0027]`:\n\n```php\n$fp = fsockopen(\n    $ssl . $arr[\u0027host\u0027],\n    $arr[\u0027port\u0027],\n    $errno,\n    $errstr,\n    $connect_timeout\n);\n```\n\nRelevant code:\n\nhttps://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L2762-L2866\n\nConsequently, the address checked by `validate_address()` is not necessarily the address used by the socket connection.\n\nThe same problem is present after redirects: the redirect URL is validated, but the recursive socket request again connects using the hostname rather than the validated IP.\n\n## Proof of concept\n\nA Docker-based reproduction is attached as `poc.zip`.\n\nThe laboratory:\n\n* downloads the official elFinder 2.1.69 release during the build;\n* verifies that the package version is 2.1.69;\n* verifies that `curl_exec()` is unavailable;\n* does not modify the elFinder core;\n* runs a deterministic DNS server and an HTTP service bound only to loopback.\n\nBuild and run:\n\n```sh\ndocker build -t elfinder-ssrf-repro poc\ndocker run --rm -p 127.0.0.1:8081:8081 elfinder-ssrf-repro\n```\n\nOpen:\n\n```text\nhttp://127.0.0.1:8081/poc/index.html\n```\n\nIn the elFinder interface:\n\n1. Select \"Upload\".\n2. Paste the following URL:\n\n```text\nhttp://rebind.test:9001/secret.txt\n```\n\n3. Wait for the upload to complete.\n4. Open the resulting `secret.txt` file.\n\nObserved content:\n\n```text\nINTERNAL_SECRET_MANUAL\n```\n\nThe PoC DNS server responds as follows:\n\n```text\nfirst A resolution       -\u003e 203.0.113.10\nsubsequent A resolutions -\u003e 127.0.0.1\n```\n\nExpected logs include:\n\n```text\nDNS rebind.test type=1 answer=203.0.113.10 count=1\nDNS rebind.test type=1 answer=127.0.0.1 count=2\nGET /secret.txt\n```\n\n`203.0.113.10` is used only as a deterministic laboratory address that passes the current private-address checks. The actual connection reaches `127.0.0.1:9001`.\n\nA redirect variant is also included:\n\n```text\nhttp://rebind.test:9001/redirect-secret\n```\n\nIt produces the same readable internal content.\n\n## Security impact\n\nAn attacker may cause the elFinder server to issue HTTP GET requests to services reachable from the PHP process, including:\n\n* loopback services;\n* private network services;\n* link-local services where reachable;\n* internal administrative or application endpoints.\n\nBecause the response body is saved and exposed through elFinder, sensitive internal information may be disclosed.\n\nThe demonstrated primitive is limited to HTTP GET requests and does not provide arbitrary request methods, bodies, or headers. Integrity and availability impact would depend on the behavior of reachable internal endpoints and are not claimed by this PoC.\n\n## Suggested CVSS\n\nFor an exposed connector matching the attached PoC:\n\n```text\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N\n```\n\nBase score: 8.6 High.\n\nThis assumes:\n\n* no authentication is required by the connector;\n* the internal service represents a separate security scope;\n* disclosure may include highly sensitive internal data.\n\nIf authenticated user access is considered an inherent prerequisite, `PR:L` would result in a score of 7.7 High.\n\n## Suggested remediation\n\nThe socket connection should use the IP address returned by `validate_address()` rather than resolving the hostname again.\n\nFor HTTPS, the original hostname should still be used for:\n\n* the HTTP `Host` header;\n* TLS SNI;\n* certificate hostname validation.\n\nThis may require replacing `fsockopen()` with a connection mechanism that supports connecting to the validated IP while explicitly configuring the TLS peer name.\n\nEvery redirect destination should be independently validated and its validated IP pinned to that specific connection.\n\nRevalidating the hostname immediately before connecting is not sufficient because it would still leave a validation-to-connection DNS resolution gap.\n\nAs a temporary mitigation, URL uploads could be rejected when cURL is unavailable, or deployments could configure `urlUploadFilter` to reject URL uploads.\n\n## Additional observation\n\nAfter a successful URL fetch, the upload path calls:\n\n```php\nget_headers($url, true)\n```\n\nRelevant code:\n\nhttps://github.com/Studio-42/elFinder/blob/2.1.69/php/elFinder.class.php#L3356-L3374\n\nThis performs another request using the original hostname without reusing the validated and pinned connection. It may therefore introduce an additional blind SSRF request, potentially even when the cURL download path is selected.\n\nThis additional request is not required for the attached non-blind `fsock_get_contents()` PoC. It should nevertheless be reviewed during remediation. Ideally, filename and response-header information should be collected from the already validated HTTP response instead of issuing a separate request.\n\n## Disclosure\n\nInitial private report date: `24/07/2026`\n\nReporter contact: `Marco Lunardi - marcolunardi90@gmail.com`",
  "id": "GHSA-8x3q-jpjh-qh5c",
  "modified": "2026-08-31T20:28:06Z",
  "published": "2026-08-31T20:28:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Studio-42/elFinder/security/advisories/GHSA-8x3q-jpjh-qh5c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Studio-42/elFinder/commit/191372c1bbebbd36fb55af79a84b9984861390ff"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Studio-42/elFinder/commit/6d997386cd0f1abab4706c220b46b0aea0ecff51"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Studio-42/elFinder"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Studio-42/elFinder/releases/tag/2.1.70"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "elFinder: SSRF protection bypass via DNS rebinding in the `fsock_get_contents()` fallback"
}