CVE-2026-81889
elFinder URL-upload SSRF filter bypass, archive-extraction MIME bypass and netmount left out of the CSRF-protected command list
- Severity
- high
- Affected product
- elFinder
- Affected versions
- elFinder < 2.1.70
- Fixed in
- elFinder 2.1.70
- Added to NewScan
- 2026-09-01
- Detected by
- NewScan — free, self-hosted
How NewScan reports it
COMPONENT VERSION RANGE
NewScan fingerprints elFinder from its response and reports this CVE when the detected version falls inside the affected range below.
Added 2026-09-01 (/daily-cve). ONE row for three same-day ids because 2.1.70 fixes all three (commits 191372c1 and 31284fac) - three rows would be three findings saying 'upgrade to 2.1.70'. CVE-2026-81889 (8.6) is php/elFinder.class.php URL uploads bypassing the server-side request filter, so the file manager fetches internal URLs on the attacker's behalf; CVE-2026-81891 (8.1) is checkExtractItems() trusting the archive's declared MIME so an extract writes a file type the upload policy forbids; CVE-2026-81890 (5.4) is `netmount` missing from elFinderConnector::$csrfProtectedCmds, so a cross-site request can mount a remote volume. VERSION-MATCH ONLY, and the reason is the product: every one of these vectors is a write through the file manager's own connector - an upload, an extract, a mount - into whatever directory the operator exposed, so there is no probe that proves them without changing the target's filesystem. The SSRF arm is additionally OOB-shaped and is where the Pro collaborator would confirm it. The version arrives from the tech_signatures "elFinder" row added the same day (the /js/elfinder.min.js banner comment), MEASURED against vulhub/elfinder:2.1.58 - captured 2.1.58, this row fires; the patched-sibling arm is pinned as a case in tests/integration/tech_version_from_checks.py because upstream publishes no 2.1.70+ image to boot.
References
Scan for this yourself — local, in-band scanning is free.
Get NewScan (FREE) →