GHSA-9rxp-f27p-wv3h CI4MS has a Hidden Items Authorization Bypass in Fileeditor Allows Reading Secrets and Writing Protected Files
SummaryThe Fileeditor controller defines a `hiddenItems` array containing security-sensitive paths (`.env`, `composer.json`, `vendor/`, `.git/`) but only enforces this protection in the `listFiles()` method. The `readFile()`, `saveFile()`, `deleteFileOrFolder()`, `renameFile()`, `createFile()`, and `createFolder()` endpoints perform no hidden items validation, allowing direct API access to files that are intended to be protected. A backend user with only `fileeditor.read` permission can exfiltrate application secrets from `.env`, and a user with `fileeditor.update` permission can overwrite `composer.json` to achieve remote code execution.DetailsThe `hiddenItems` array is defined at `modules/Fileeditor/Controllers/Fileeditor.php:10-26`:This array is checked **only** in `listFiles()` at lines 45-48 and 64:However, `readFile()` (line 76) performs **neither** a `hiddenItems` check **nor** an `allowedFileTypes()` check:This means any file within ROOTPATH — regardless of extension (`.php`, `.env`, etc.) — can be read by any user with the `fileeditor.read` permission.Similarly, `saveFile()` (line 92) checks `allowedFileTypes()` but not `hiddenItems`. Since `json` is in `$allowedExtensions`, `composer.json` (which is explicitly in `hiddenItems`) can be overwritten:`deleteFileOrFolder()` (line 194) checks neither `hiddenItems` nor `allowedFileTypes()`.**Compounding factor:** CSRF protection is disabled for all fileeditor routes in `modules/Fileeditor/Config/FileeditorConfig.php:7-10`:This means the write and delete operations are additionally vulnerable to cross-site request forgery if an authenticated user visits a malicious page.PoCRequires an authenticated backend session with `fileeditor.read` permission granted.**Step 1: Read .env file to extract secrets**Expected response: JSON containing `.env` file contents including database credentials, encryption keys, and other secrets.**Step 2: Read PHP configuration files**Expected response: Full database configuration PHP source with credentials (note: `readFile()` has no `allowedFileTypes` check, so `.php` files are readable).**Step 3: Overwrite composer.json for RCE (requires `fileeditor.update` permission)**The next `composer install` or `composer update` executes the attacker's script.**Step 4: Delete .env (requires `fileeditor.delete` permission)**Impact**Credential disclosure:** Any backend user with `fileeditor.read` permission can read `.env` (database passwords, encryption keys, API secrets, mail credentials) and any PHP configuration file regardless of extension restrictions.**Remote code execution:** A user with `fileeditor.update` permission can overwrite `composer.json` with malicious composer scripts that execute on the next `composer install/update`.**Denial of service:** A user with `fileeditor.delete` permission can delete `.env` or other critical configuration files, causing application failure.**False security boundary:** Administrators who configure `fileeditor.read` as a limited permission for content editors are unknowingly granting access to all application secrets, since the `hiddenItems` protection only affects the UI file tree, not the API.Recommended FixApply `hiddenItems` validation to all endpoints that accept a `path` parameter. Extract the check into a reusable method and also add `allowedFileTypes` to `readFile()`:Also re-enable CSRF protection by removing the CSRF exemption in `FileeditorConfig.php` (lines 7-10) and ensuring the frontend sends CSRF tokens with requests.
CVSS v3.1 score: 6.7