CVE-2026-18117 in Concrete CMS
Summary
by MITRE • 09/15/2026
Concrete CMS 9.0.0 through 9.5.3 is vulnerable to stored XSS via the custom page alias name (customAliasName) because the Edit Alias dialog applied only trim() to the submitted value and performed no input neutralization. An authenticated user holding canWrite (editor) permission on a page could store a malicious alias name that was later rendered unescaped in the administrative Sitemap panel, where it executed automatically in any administrator or editor session that opened the panel, allowing an editor to escalate to administrator through the victim's active session. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N. Thanks Nguyen Manh Thuan for reporting.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/15/2026
Concrete CMS versions 9.0.0 through 9.5.3 contain a critical stored cross-site scripting vulnerability located within the custom page alias management functionality, specifically affecting the customAliasName parameter. This flaw arises from insufficient input validation and sanitization during the processing of user-supplied data in the Edit Alias dialog. The application logic applies only a basic trim() function to remove leading and trailing whitespace but fails to implement any meaningful neutralization or encoding of special characters that could be interpreted as executable code by web browsers. Consequently, an attacker can inject malicious script payloads directly into the database via this field without triggering server-side rejection or escaping mechanisms designed to prevent execution in subsequent contexts.
The operational impact of this vulnerability is significant due to its stored nature and the specific context in which the injected content is rendered. When a page with a compromised alias name is accessed, the malicious payload is not merely displayed as static text but is executed automatically within the administrative Sitemap panel interface. This execution occurs without requiring further user interaction beyond opening the panel, classifying it as an auto-executing stored XSS attack rather than a reflected variant that would require clicking on a specific link or element. The persistence of this code in the database ensures that every subsequent administrator or editor who views the affected page will trigger the malicious script within their own browser session environment.
The security implications are severe because they facilitate privilege escalation through session hijacking and manipulation techniques. An authenticated user holding canWrite permissions, typically classified as an editor role with limited administrative capabilities, can exploit this vulnerability to execute arbitrary JavaScript in the context of higher-privileged accounts such as administrators or other editors. By leveraging standard cross-site scripting payloads, the attacker can steal authentication cookies, perform actions on behalf of the victim, or redirect users to phishing sites. This effectively allows a lower-privilege user to bypass access controls and achieve administrative-level influence over the CMS environment by exploiting the trust relationship between the application interface and the browser session of privileged users who view the compromised content.
From an industry standards perspective, this vulnerability aligns with CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The specific attack vector corresponds to ATT&CK technique T1059 Command and Scripting Interpreter via JavaScript, which describes how attackers use scripting languages to execute commands or perform actions within a victim's browser session. Additionally, the requirement for an authenticated user with write permissions places this under privilege escalation scenarios where lateral movement is achieved through social engineering or automated script execution rather than direct exploitation of authentication flaws. The CVSS v4.0 score of 7.3 reflects high confidentiality and integrity impacts due to the ability to steal sensitive data and modify application behavior, while availability impact remains low as the core service continues to function despite the malicious activity.
Mitigation strategies for this vulnerability involve immediate patching to version 9.5.4 or later where input validation has been strengthened. Administrators should ensure that all special characters in user-supplied fields are properly encoded using context-aware output encoding techniques before rendering them in HTML, JavaScript, or CSS contexts. Implementing a Content Security Policy can also help mitigate the impact by restricting the sources from which scripts can be loaded and executed. Furthermore, enforcing strict role-based access controls and auditing editor activities for unusual patterns of page alias modifications can aid in early detection of exploitation attempts. Regular security assessments focusing on input validation logic across all administrative interfaces are recommended to prevent similar vulnerabilities arising from insufficient sanitization practices.