CVE-2026-88418 in CMSimple
Summary
by MITRE • 09/22/2026
CMSimple 5.24 ships with CSRF protection disabled by default, which turns csrfProtection() into a no-op on every state-changing admin request, and it does not send the csrf_token hidden field in admin forms. Because administrator authentication is cookie-only and no CSRF token is enforced, an unauthenticated attacker can induce a logged-in administrator's browser to issue a forged content-save request with a text payload containing a scripting marker. The marker is stored verbatim into content/content.php; on every subsequent page view evaluate_cmsimple_scripting() (functions.php) executes the marker body with PHP eval() — for all visitors, including unauthenticated ones. This yields persistent remote code execution on the web server.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/22/2026
CMSimple version 5.24 contains a critical security flaw rooted in the default configuration of its Cross-Site Request Forgery protection mechanisms and subsequent improper handling of user-supplied input within administrative interfaces. The vulnerability arises because the cmsProtection function, which is responsible for validating CSRF tokens on state-changing requests, defaults to a no-op operation when csrfProtection is disabled. This setting leaves all administrative actions that modify content unprotected against forged requests from malicious websites or scripts. Furthermore, the application fails to include the necessary csrf_token hidden field in its admin forms, ensuring that even if an administrator were logged in via cookie-based authentication, there is no mechanism to verify the legitimacy of the request origin.
The exploitation path begins with an unauthenticated attacker inducing a logged-in administrator's browser to submit a forged content-save request. Because the application relies solely on cookies for session management and does not enforce token validation due to the disabled protection state, the server accepts this malicious payload as valid administrative action. The attacker crafts a specific text payload containing a scripting marker designed to trigger code execution when processed by the CMS engine. This payload is stored verbatim into the content/content.php file without any sanitization or encoding checks at the point of storage.
The severity of this vulnerability escalates significantly due to how the application processes stored data during page rendering. When a visitor accesses a page containing the compromised content, the evaluate_cmsimple_scripting function located in functions.php is invoked. This function executes the scripting marker body using PHP's eval() construct. Since the malicious payload was injected via an administrative action that appeared legitimate due to the CSRF bypass, and since it contains executable code rather than plain text, this results in persistent remote code execution on the web server. The impact extends beyond just the administrator account; every visitor who views the affected page triggers the arbitrary PHP code execution, allowing attackers to achieve full control over the underlying system for all users accessing that content.
This vulnerability aligns with CWE-352 Cross-Site Request Forgery due to the lack of anti-CSRF tokens and CWE-94 Improper Control of Generation of Code or Script Injection because user input is executed as code without proper validation. In terms of MITRE ATT&CK, this scenario maps to T1059 Command and Scripting Interpreter where attackers use PHP eval() for execution, and T1136 Create Account if the attacker creates new admin users, though here it primarily facilitates immediate RCE through stored XSS-like mechanisms that escalate to code injection. The combination of disabled security controls by default and unsafe evaluation of stored content creates a high-severity risk profile requiring immediate remediation.
Mitigation strategies must address both the configuration defaults and the input handling logic. Administrators should immediately enable csrfProtection in their CMSimple settings to ensure all state-changing requests are validated against unique tokens generated per session. Additionally, developers need to refactor the evaluate_cmsimple_scripting function to avoid using eval() on user-supplied data entirely. If dynamic scripting is a required feature, it must be implemented through safe abstraction layers that parse and execute only predefined, whitelisted commands rather than arbitrary code strings. Input validation should also be enforced at multiple stages, ensuring that content saved by administrators undergoes strict sanitization to strip or encode any potentially executable markers before they are persisted to disk files like content.php.