CVE-2026-114624 in BaserCMS
Summary
by MITRE • 10/23/2026
baserCMS is a website development framework. In versions 5.0.0 before 5.3.2 and 5.4.0 before 5.4.2, the widget-area entity serializes widgets only when the submitted value is an array, allowing a string submitted through the admin JSON API to be stored unchanged. Entity reads, including front-end rendering and API responses, deserialize the stored value with unserialize() without an allowed_classes restriction, accepting both raw and base64-encoded serialized data. An administrator, or an attacker who obtains widget-write capability through a separate vulnerability such as chained XSS, can plant an object graph that subsequently triggers on unauthenticated page requests. Two demonstrated gadget chains in the default dependency set use composer/composer ProcessExecutor::startJob() with Process::fromShellCommandline(), or logiscape/mcp-sdk-php StdioTransport::connect() with StdioServerParameters, to reach proc_open() and execute commands as the web-server user. Deserialization bypasses constructor-based readonly safeguards, and the stored payload can execute repeatedly until the database row is repaired. Unauthenticated page access is a trigger after privileged payload storage, not an unauthenticated means of initially planting the payload. This issue has been patched in versions 5.3.2 and 5.4.2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
baserCMS version 5.0.0 through 5.3.1 and version 5.4.0 through 5.4.2 contains a critical insecure deserialization vulnerability within the widget-area entity handling logic. The root cause lies in how the framework processes submitted values for widgets. Specifically, the serialization mechanism only applies when the input is an array type. If a string value is submitted via the admin JSON API, it bypasses this conditional check and is stored directly into the database without any transformation or validation. This design flaw creates a direct path for attackers to inject arbitrary data structures that are later processed by the application's deserialization routines during entity reads, which include front-end rendering processes and API responses.
The vulnerability manifests when the system attempts to read these stored values using PHP’s unserialize function. Crucially, this unserialization process is performed without an allowed_classes restriction or any other safety mechanism to limit which classes can be instantiated from the serialized data. This lack of restrictions allows the deserialization engine to accept both raw serialized objects and base64-encoded serialized payloads. Consequently, if a malicious actor can inject such a payload into the database, it will be automatically executed whenever an administrator views the affected page or when specific API endpoints are accessed that trigger this entity read operation.
The operational impact of this vulnerability is severe, as it leads to remote code execution with the privileges of the web server user. Attackers who possess administrative credentials or those who can exploit a separate vulnerability such as cross-site scripting to gain widget-write capabilities can plant an object graph designed to execute system commands upon deserialization. Demonstrated gadget chains in the default dependency set leverage composer/composer’s ProcessExecutor::startJob method combined with Process::fromShellCommandline, or logiscape/mcp-sdk-php’s StdioTransport::connect method paired with StdioServerParameters. These chains ultimately invoke proc_open to execute arbitrary commands on the underlying operating system. This represents a classic case of insecure deserialization leading to remote code execution, aligning with CWE-502 and often associated with ATT&CK technique T1059 Command and Scripting Interpreter via process creation.
A significant aspect of this vulnerability is its persistence and ease of exploitation regarding defensive measures. The serialized payload bypasses constructor-based readonly safeguards that might otherwise prevent certain object states from being established during normal instantiation. Once the malicious payload is stored in the database, it remains there until manually repaired or deleted. This means that every subsequent unauthenticated page request to a view containing the compromised widget area can trigger the execution of the payload. It is important to clarify that while the initial planting of the payload requires privileged access such as admin rights or a chained XSS attack, the actual code execution triggered by deserialization occurs during routine user interactions with the site, effectively turning public-facing pages into vectors for exploitation after the initial compromise.
To mitigate this vulnerability, organizations must immediately upgrade baserCMS to version 5.3.2 or later, where these issues have been patched. The patch likely involves enforcing strict type checking on widget submissions and implementing safe deserialization practices such as using allowed_classes restrictions in unserialize calls. Additionally, administrators should audit existing database entries for any signs of malicious serialized data if they were running vulnerable versions prior to the update. Implementing a Content Security Policy and ensuring that administrative interfaces are protected by strong authentication mechanisms can further reduce the risk of initial compromise through chained attacks like XSS. Regular security assessments focusing on input validation and output encoding are essential to prevent similar insecure deserialization flaws in web applications relying on PHP frameworks.