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 …
The auth filter has the deactivated/banned user check commented out.
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.
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.
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.
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.
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.
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 preg_replace(). 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).
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.
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.
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.
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 …
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
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). User-controlled profile fields (specifically the username / full name) are rendered unsafely across …
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 …
The application fails to properly sanitize user-controlled input within System Settings – Company Information. Several administrative configuration fields accept attacker-controlled input that is stored server-side and later rendered without proper output encoding. Affected fields include, but are not limited to: Company Name Slogan Company Phone Company Mobile Company Email Google Maps iframe link Company Logo and other media-related fields Unlike the public-facing landing page injection vulnerability, this issue executes directly …
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.
The application fails to properly sanitize user-controlled input within group and role management functionality. Multiple input fields (three distinct group-related fields) can be injected with malicious JavaScript payloads, which are then stored server-side. These stored payloads are later rendered unsafely within privileged administrative views without proper output encoding, leading to stored cross-site scripting (XSS) within the role and permission management context.
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).
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 …
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).
The application fails to properly sanitize user-controlled input when adding Pages to navigation menus through the Menu Management functionality. Page-related data selected via the Pages section is stored server-side and rendered without proper output encoding. This stored payload is later rendered unsafely within administrative interfaces and public-facing navigation menus, leading to stored DOM-based cross-site scripting (XSS).
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 …
The application fails to properly sanitize user-controlled input when creating or editing blog tags. An attacker can inject a malicious JavaScript payload into the tag name field, which is then stored server-side. This stored payload is later rendered unsafely across public tag pages and administrative interfaces without proper output encoding, leading to stored cross-site scripting (XSS).
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).
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).
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).
The application fails to properly sanitize user-controlled input when handling backup uploads and processing backup metadata. An attacker can inject a malicious JavaScript payload into the backup filename via the uploaded xss.sql, which uses SQL functionality to insert the XSS payload server-side. This stored payload is later rendered unsafely in multiple backup management views without proper output encoding, leading to stored blind cross-site scripting (Blind XSS).
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 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 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 …
Summary The authentication implementation in CI4MS is vulnerable to email enumeration. An unauthenticated attacker can determine whether an email address is registered in the system by analyzing the application's response during the password reset process. Vulnerability Details The password reset flow returns different responses based on whether the provided email address exists in the database or not. If the email is registered, the system typically returns a success message (e.g., …
Summary The authentication implementation in CI4MS is vulnerable to email enumeration. An unauthenticated attacker can determine whether an email address is registered in the system by analyzing the application's response during the password reset process. Vulnerability Details The password reset flow returns different responses based on whether the provided email address exists in the database or not. If the email is registered, the system typically returns a success message (e.g., …
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 …
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 …