CVE-2026-85040 in CRMEB
Summary
by MITRE • 09/03/2026
A weakness has been identified in ZhongBangKeJi CRMEB up to 6.0.0. Affected by this vulnerability is the function eval of the file /adminapi/system/crontab/save of the component Custom Scheduled Task Feature. This manipulation of the argument customCode causes os command injection. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks. Vendor documents this as deliberate debug-only behavior. But isSafePhpCode blacklist offers no real RCE containment.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in ZhongBangKeJi CRMEB versions up to 6.0.0 represents a critical security flaw within the Custom Scheduled Task Feature, specifically located in the eval function of the /adminapi/system/crontab/save endpoint. This component is designed to handle the configuration and execution of scheduled tasks, allowing administrators to define custom code snippets that run at specified intervals. The core technical failure lies in how the application processes the customCode argument passed by the user. Instead of sanitizing or validating this input against a robust allowlist or using safe execution methods like serialization with strict type checking, the system directly passes the unsanitized input into an eval function. This architectural decision creates a direct pathway for operating system command injection, as the evaluated PHP code can be crafted to execute arbitrary shell commands on the underlying server infrastructure.
The operational impact of this vulnerability is severe due to its remote exploitable nature and the availability of public exploits. An attacker with access to the administrative interface or potentially through other vectors that allow interaction with this API endpoint can inject malicious payloads into the customCode parameter. Because the vendor has documented this behavior as deliberate debug-only functionality, there may be a misconception among administrators regarding the risk level; however, the presence of an isSafePhpCode blacklist mechanism provides no real containment against Remote Code Execution (RCE). Blacklist-based filtering is inherently fragile and easily bypassed using encoding techniques, alternative syntaxes, or by exploiting edge cases in PHP's parsing engine. Consequently, a successful exploitation allows for complete compromise of the server hosting the CRMEB instance, leading to data theft, defacement, or use as a pivot point for further network attacks.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) and specifically CWE-78 OS Command Injection when the injected code results in shell command execution. In terms of adversary behavior mapping to MITRE ATT&CK, this flaw facilitates techniques such as T1059 Command and Scripting Interpreter for initial access or lateral movement, and potentially T1620 Reflective Code Loading if the injection is used to load malicious modules into memory without writing to disk. The availability of public exploits significantly lowers the barrier to entry for attackers, increasing the likelihood of automated scanning and exploitation campaigns targeting instances that have not been patched or properly configured.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. First, it is imperative to disable or restrict access to the /adminapi/system/crontab/save endpoint if the custom scheduled task feature with arbitrary code execution is not strictly required for business operations. If the feature must remain active, administrators should implement strict input validation that employs allowlisting rather than blacklisting, ensuring only predefined, safe functions and variables are permitted in the customCode field. Additionally, deploying a Web Application Firewall (WAF) with rules specifically tuned to detect eval-based injection patterns can provide an additional layer of defense. Upgrading to a version where this vulnerability is patched by replacing eval with safer execution methods or removing the capability entirely is the most effective long-term solution. Regular security audits and penetration testing should be conducted to identify similar insecure coding practices across other components of the application.