Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
36 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The Pages backend module registers the htmlpurify validation rule on language-keyed page content but persists the raw, un-purified POST value into the database. The public renderer for pages (Home::index() → app/Views/templates/default/pages.php) emits $pageInfo-content without esc(), yielding stored XSS that fires for every public visitor of the affected page — including administrators. Because pages may be promoted to the site home page, the payload can be served at / and reach every visitor of the site. Details This is a sibling-module variant of the same root cause as the Blog stored-XSS issue. The htmlpurify custom rule (modules/Backend/Validation/CustomRules.php:54) mutates its first argument by reference: CodeIgniter 4's Validation::processRules() (vendor/codeigniter4/framework/system/Validation/Validation.php:344) invokes the rule as $set-{$rule}($value, $error) where $value is a local copy populated from request data. Even though the rule signature accepts $str by…
Recommended action: Upgrade to 0.31.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Fileeditor module enforces an extension allowlist (['css','js','html','txt','json','sql','md']) on content-write operations (saveFile, createFile), but two destructive endpoints — deleteFileOrFolder and renameFile — never validate the extension of the source path. A backend user with file-editor permissions can therefore unlink or rename any file inside the project root that is not explicitly listed in the small $hiddenItems blocklist. Critical framework files such as app/Config/Routes.php, app/Config/App.php, app/Config/Database.php, app/Config/Filters.php, public/index.php, and public/.htaccess all live outside that blocklist and can be destroyed, producing a persistent denial of service that requires filesystem-level redeployment to recover. Details Root cause: inconsistent application of the extension allowlist across Fileeditor operations in modules/Fileeditor/Controllers/Fileeditor.php. The class declares an allowlist used by content-write operations: saveFile (line…
Recommended action: Upgrade to 0.31.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The custom htmlpurify validation rule used to sanitize blog post bodies relies on by-reference mutation (?string &$str), but CodeIgniter 4's validator passes a local copy of the value, so the sanitized text is silently discarded. The Blog controller writes $lanData['content'] directly into bloglangs.content, and the public template echoes it without escaping — yielding stored XSS executable in any visitor's browser, including the superadmin when previewing or editing posts. Details Root cause: by-reference mutation never propagates Modules\Backend\Validation\CustomRules::htmlpurify declares its first argument by reference: CI4's validator invokes the rule via a local variable $value it created from a copy of $this-data: The reference mutation modifies that local $value only; $this-data, $POST, and getValidated() keep the raw payload. The optional getClean($original) cache lookup in CustomRules.php:85-93 also fails because the cache was keyed on md5(clean) rather than…
Recommended action: Upgrade to 0.31.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The auth filter has the deactivated/banned user check commented out. Details CodeIgniter Shield's loggedIn() re-checks the status field (catching status='banned'), but does not re-check the active field for existing sessions. When an admin deactivates a user (active=0) after they have already logged in: - Their session cookie remains valid - auth()-loggedIn() still returns true - The commented-out code is the only mechanism that would have checked !$user-active Evidence <img width="981" height="654" alt="image" src="https://github.com/user-attachments/assets/6f75d144-5bcf-4a3f-bc35-bb0715c3ed05" / Impact - User deactivation does NOT immediately revoke backend access - Deactivated user retains full access until session expires (default: 7200s) Additional note The commented-out block appears to be a deferred placeholder — it was written but disabled from the very first commit that introduced the filter, and has never been active. The later addition of SessionTracker (v0.31.4.0)…
Recommended action: Upgrade to 0.31.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The deleteProcess() action accepts a POST parameter tables[] containing arbitrary table names. These are passed directly to $forge-dropTable() without validating that the tables belong to the theme being deleted. The deleteConfirm view correctly populates tables[] from the theme's own migration files, but the server-side deleteProcess does not verify the received values against those files. An authenticated admin can craft a POST request with arbitrary table names and drop any table in the database. This is a real bug even within the admin trust model: the action should be scoped to the theme's own tables. The permission grants delete this theme's data", not "drop any table". Details Location modules/Theme/Controllers/Theme.php :: deleteProcess() ~line 147 Vulnerable Code PoC 1. Authenticate to the backend (any user with theme.delete permission) 2. POST to /backend/themes/delete-process/<anynonactivethemeslug 3. Include tables[]=<anytable in POST body 4. The named tables are…
Recommended action: Upgrade to 0.31.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A theme upload feature allows any authenticated backend user with theme-upload permission to achieve remote code execution (RCE) by uploading a crafted ZIP file. PHP files inside the ZIP are installed into the web-accessible public/ directory with no extension or content filtering, making them directly executable via HTTP. Details File: modules/Theme/Controllers/Theme.php After a ZIP is uploaded and extracted to a temporary directory, installthemefromtmp() is called unconditionally: Theme.php:51-52 File: modules/Theme/Helpers/themeshelper.php The helper copies every file matching . from public/templates/<name/ inside the ZIP directly into public/templates/<name/ on disk using rename(), with no file-extension allowlist, no MIME check, and no content inspection: themeshelper.php:60-68 Because the web root is public/, any .php file placed there is directly reachable over HTTP. PHP files are also installed — without filtering — into app/Controllers/templates/<name/,…
Recommended action: Upgrade to 0.31.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ci4ms Theme::upload extracts user uploaded ZIP archives without validating entry names, allowing an authenticated backend user with the theme 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/Theme/Controllers/Theme.php:13-56 implements the theme upload action. ZipArchive::extractTo() is called directly with no iteration over entry names to verify they resolve inside the destination: A ZIP containing entries like ../../public/shell.php is extracted outside writable/tmp/ 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/Theme/Config/Routes.php binds POST backend/themes/themesUpload to Theme::upload with role=create. Although ThemeConfig itself does not list the route in csrfExcept, the upload handler is…
Recommended action: Upgrade to 0.31.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 0.31.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker can achieve Full Account Takeover and Privilege Escalation via Stored DOM XSS in the backup module's filename field, which is manipulated through an SQL file that tampers with the filename field to contain a hidden XSS payload.
Recommended action: Upgrade to 0.31.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Install::index() controller reads the host POST parameter without any validation and passes it directly into updateEnvSettings(), which writes it into the .env file via pregreplace(). Because newline characters in the value are not stripped, an attacker can inject arbitrary configuration directives into the .env file. The install routes have CSRF protection explicitly disabled, and the InstallFilter can be bypassed when cache('settings') is empty (cache expiry or fresh deployment). Details In modules/Install/Controllers/Install.php, the $valData array (lines 13-27) defines validation rules for all POST parameters except host. The host value is read at line 35: This value is passed to updateEnvSettings() (lines 89-101), which uses pregreplace with the raw value as the replacement string: Since the env template has all lines commented out (e.g., database.default.hostname = localhost), the pattern does not match, and the value is appended verbatim — including any embedded…
Recommended action: Upgrade to 0.31.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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: 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…
Recommended action: Upgrade to 0.31.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Pages module does not apply the htmlpurify 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 The Pages module omits this rule in both create and update methods: modules/Pages/Controllers/Pages.php:82 (create) modules/Pages/Controllers/Pages.php:130 (update) Content is stored directly without sanitization: modules/Pages/Controllers/Pages.php:111 (create path) modules/Pages/Controllers/Pages.php:157 (update path) On the public frontend, the content is rendered as raw HTML without escaping:…
Recommended action: Upgrade to 0.31.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The blacklist (ban) note parameter in UserController::ajaxblackListpost() 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 ajaxblackListpost() method (line 344-362) accepts a note POST parameter with only a required validation rule: Shield's Bannable::ban() trait stores the message as-is: In the users() method (line 13-91), when building the DataTables response, the statusmessage is concatenated directly into HTML without escaping: 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: Expected response:…
Recommended action: Upgrade to 0.31.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Google Maps iframe setting (cMap field) in compInfosPost() sanitizes input using striptags() 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): 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): The output applies striptags with the same <iframe allowlist but performs no attribute filtering or HTML encoding. The stored payload is rendered verbatim. Why HTML entities bypass striptags: A payload like <iframe…
Recommended action: Upgrade to 0.31.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 0.31.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 0.31.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability 1: Stored DOM XSS via Profile Name Update (Persistent Payload Injection) - Stored Cross-Site Scripting via Unsanitized User Name in Profile Management Description The application fails to properly sanitize user-controlled input when users update their profile name (e.g., full name / username). An attacker can inject a malicious JavaScript payload into their profile name, 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 - Profile name / full name update functionality (both the 2 user inputs) - User profile storage and retrieval logic Attack Scenario - An attacker updates their profile name to include a malicious XSS payload. - The application stores this value without sanitization or encoding. - The payload persists and executes whenever the name is rendered in affected views. Impact - Persistent Stored…
Recommended action: Upgrade to 31.0.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.31.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A critical Stored Cross-Site Scripting (Stored XSS) vulnerability exists in the backend user management functionality. The application fails to properly sanitize user-controlled input before rendering it in the administrative interface, allowing attackers to inject persistent JavaScript code. This results in automatic execution whenever backend users access the affected page, enabling session hijacking, privilege escalation, and full administrative account compromise. --- Details The vulnerability resides in the backend user creation feature accessible via: User-supplied input in the name and surname fields is stored without proper validation or sanitization. When this data is later rendered in the backend users listing page, it is injected directly into the HTML without output encoding. Because of this, attackers can embed malicious JavaScript payloads that execute in the context of authenticated backend users. This indicates missing contextual output escaping (e.g., HTML…
Recommended action: Upgrade to 0.31.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability: Improper Session Invalidation on Account Deletion (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 deleted. 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 deleted. 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 deleted accounts to retain indefinite access until the user manually logs out. This behavior breaks the intended access control policy…
Recommended action: Upgrade to 0.31.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.31.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.31.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.31.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability: Stored DOM XSS via Page Management Fields (Persistent Payload Injection) - Stored Cross-Site Scripting via Unsanitized Page Creation and Editing Inputs Description The application fails to properly sanitize user-controlled input within the Page Management functionality when creating or editing pages. Multiple input fields accept attacker-controlled JavaScript payloads that are stored server-side. These stored values are later rendered without proper output encoding across administrative page lists and public-facing page views, leading to stored DOM-based cross-site scripting (XSS). Affected Functionality - Page creation functionality - Page editing functionality - Page list and management views - Public-facing page rendering - Storage and retrieval of page-related data Affected Fields - Title - URL - Content - Cover Image - Image URL - Image Width - Image Height - SEO Description - SEO Keywords Attack Scenario - An attacker creates or edits a page and injects a…
Recommended action: Upgrade to 0.31.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability: Stored DOM XSS via Posts Added to Menu (Persistent Payload Injection) - Stored Cross-Site Scripting via Unsafe Rendering of Post Entries in Menu Management Description The application fails to properly sanitize user-controlled input when adding Posts to navigation menus through the Menu Management functionality. Post-related data selected via the Posts section is stored server-side and rendered without proper output encoding. These stored values are later rendered unsafely within administrative dashboards and public-facing navigation menus, resulting in stored DOM-based cross-site scripting (XSS). Affected Functionality - Menu Management – Posts section - Adding posts to navigation menus - Menu storage and rendering logic Attack Scenario - An attacker creates or controls a post containing a malicious JavaScript payload. - The attacker adds the post to the menu using the Posts functionality in Menu Manager. - The application stores the menu entry without…
Recommended action: Upgrade to 0.31.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.