CVE-2018-10118 in Monstra
Summary
by MITRE
Monstra CMS 3.0.4 has Stored XSS via the Name field on the Create New Page screen under the admin/index.php?id=pages URI, related to plugins/box/pages/pages.admin.php.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/24/2025
The vulnerability CVE-2018-10118 represents a critical stored cross-site scripting flaw in Monstra CMS version 3.0.4 that specifically targets the administrative interface. This vulnerability exists within the page creation functionality where user input submitted through the Name field is not properly sanitized or validated before being stored in the database and subsequently rendered back to users. The attack vector is particularly concerning as it occurs in the admin/index.php?id=pages URI context, making it accessible to authenticated administrators who have privileges to create new pages within the CMS. The vulnerability is located within the plugins/box/pages/pages.admin.php file, indicating that the issue stems from how the system handles page name inputs during the creation process.
The technical exploitation of this vulnerability follows a classic stored XSS pattern where malicious input is first submitted by an attacker with administrative privileges and then persisted in the system's database. When other users or administrators view the page listing or related interfaces, the malicious script stored in the Name field executes in their browsers, potentially allowing for session hijacking, credential theft, or redirection to malicious sites. The flaw represents a CWE-79 weakness in HTML generation, specifically involving the improper handling of untrusted data in web applications. This vulnerability directly maps to ATT&CK technique T1059.007 for command and scripting interpreter and T1566 for credential access, as the stored payload could be crafted to harvest user credentials or execute malicious commands.
The operational impact of this vulnerability is significant for organizations using Monstra CMS 3.0.4, as it provides a persistent attack vector that remains active until the vulnerability is patched. An attacker who gains administrative access or exploits this vulnerability can maintain long-term presence within the system, potentially accessing sensitive content, modifying pages, or using the compromised system as a launchpad for further attacks. The stored nature of the XSS means that the attack persists across multiple user sessions and browser visits, unlike reflected XSS which requires specific user interaction with malicious links. Organizations may experience data breaches, unauthorized content modification, and potential compromise of the entire CMS infrastructure. The vulnerability affects the integrity and confidentiality of the system, making it particularly dangerous for websites that handle sensitive user information or business-critical content management operations.
Mitigation strategies for CVE-2018-10118 should focus on immediate patching of the Monstra CMS to version 3.0.5 or later, which contains the necessary fixes for the XSS vulnerability. Administrators should implement proper input validation and output encoding mechanisms to sanitize all user inputs before storage and rendering. The system should employ Content Security Policy headers to limit script execution and prevent unauthorized code from running within the browser context. Regular security audits of CMS plugins and core files should be conducted to identify similar vulnerabilities in other components. Additionally, implementing role-based access controls and monitoring user activities can help detect suspicious behavior that might indicate exploitation attempts. Organizations should also consider implementing web application firewalls to provide additional protection against XSS attacks and maintain up-to-date backups to quickly restore systems if compromise occurs. The vulnerability highlights the importance of input sanitization and output encoding practices as recommended by OWASP and other security frameworks, emphasizing that all user-supplied data must be treated as potentially malicious until properly validated and escaped.