CVE-2026-114624: baserCMS: PHP object injection via unguarded unserialize() in the widget-area entity
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 allowedclasses 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 procopen() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
baserCMSto a version that resolves this vulnerability.Fixed in 5.3.2 - Upgrade
Upgrade
baserCMSto a version that resolves this vulnerability.Fixed in 5.4.2
Event History
Frequently Asked Questions
Which deployments are affected?
Affected versions are baserCMS 5.0.0 before 5.3.2 and 5.4.0 before 5.4.2. The demonstrated command-execution gadget chains are present in the default dependency set.
Does an attacker need to be authenticated to exploit this?
An attacker must first be able to write widget data, such as by being an administrator or by obtaining widget-write capability through another vulnerability. Once a malicious value has been stored, an unauthenticated page request can trigger deserialization and execution.
What is the impact after a malicious widget value is stored?
Demonstrated gadget chains can reach proc_open() and execute commands as the web-server user. The payload may execute during front-end rendering or API responses and can run repeatedly until the affected database row is repaired.
What should be done if a malicious payload may already have been stored?
Repair the affected widget-area database row to remove the stored payload. This is necessary because requests that read the entity can continue to deserialize and trigger the payload.