Craft CMS Before 5.10.12: How a String-Typed Field Layout Reached Object Instantiation

A low-privilege control-panel account as an execution path

Craft CMS gives editors a control panel where they arrange fields, tabs and layouts. That interface is not usually treated as an execution boundary. The September 2026 advisory for CVE-2026-86730 shows why it has to be treated as one, because the affected input type is a layout element and the outcome is code execution.

Technical context: cleansing validates shape, not type

Craft validates field layout data before it stores and later instantiates the configured objects. The advisory describes the gap precisely: string-typed field-layout elements were not cleansed properly. The control panel can post a field-layout tab element as a JSON string rather than as the structured object the validator expects.

The cleansing step then validates a shape it recognises and passes the string through. When Craft later builds the layout, the string is deserialized into an object, and that object can carry Yii2 behaviour attachments and event handlers.

Explanation: from behaviour attachment to execution

The Yii2 framework allows a class to attach behaviours, which are objects bound to events. When an attacker can influence the configuration that is used to build an object, they can attach a behaviour whose event handler points at code they control. Craft::createObject() then instantiates that configuration, and the attached handler runs.

This is an application-level deserialization shape rather than a memory-corruption bug. The trust boundary that failed is the type boundary between "a string" and "a configuration object", and the consequence is arbitrary object instantiation followed by code execution on the web server.

Affected versions and severity

The affected range is Craft CMS before 5.10.12, with VulnCheck describing the window from 5.0.0-RC1 through 5.10.12. NVD records a CVSS 3.1 base score of 8.8. The required access level is an authenticated control-panel user, which is why the score sits below the critical band and why some teams will deprioritise it. That reasoning is worth resisting: editor accounts are frequently provisioned for contractors, agencies and content teams, and a CMS install is often one credential away from a database and a file system.

Defensive implications

Update to Craft CMS 5.10.12 or later. This is a point release, so the migration risk is low compared with a major version change.

Then audit who holds control-panel access and whether every account still needs it. Because the prerequisite is a legitimate account, the accounts themselves are the control. Review the user list, remove stale editor accounts and confirm that integrations and sites do not share a single human login.

Separate content editing from plugin and configuration authority if the CMS supports it, and keep the administration panel off the public internet where an internal path or an authenticated tunnel would do.

Finally, watch for the post-auth shape rather than the payload. A request that posts a field-layout element as a JSON string where the client normally sends an object is unusual enough to alert on, and it is more durable as a detection than a signature for one particular behaviour attachment.

References

• Craft CMS security advisory GHSA-qj4v-m29p-fj4m.
• VulnCheck advisory: Craft CMS 5.0.0-RC1 before 5.10.12 behaviour injection RCE.
• NVD record for CVE-2026-86730.