Craft CMS CVE-2026-78416: search-condition JSON could lead to RCE

CVE-2026-78416 was published on 24 August and affects element-search condition handling in the Craft CMS control panel. An authenticated user could submit a prepared JSON structure through condition.config. A cleansing bypass allowed Yii to interpret special keys as behavior or event configuration after decoding, leading to command execution in the PHP/web process context.

Affected releases are 4.0.0-RC1 through versions before 4.18.2 and 5.0.0-RC1 through versions before 5.10.6. The CVE carries CVSS 4.0: 8.7 (High) with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. It requires an account and access to the relevant control-panel function, but no action by another user.

From JSON data to executable object configuration

JSON normally appears to be a passive data format. Its safety, however, depends on where decoded values go. Craft CMS uses Yii, where a configuration array can describe not only ordinary properties but also how an object is created and which behaviors or event handlers are attached. In that context, the boundary between “data” and a “construction instruction” is a real execution boundary.

The flaw involved cleansing condition configuration. If a filter removes dangerous keys only at one depth, before final decoding or in a representation different from the one passed to the object factory, a special structure may survive. When the framework later interprets the result as configuration, an attacker need not inject raw PHP. They use legitimate container and event-system semantics to build an unsafe object graph.

This differs from straightforward command injection where a text fragment enters a shell. The underlying problem is overly expressive configuration deserialisation. Validation of business values—an operator, field or date range—is insufficient if meta-keys understood by the framework can travel alongside them.

Conditions required for attack

The record rates required privileges as low, but that does not mean anonymous Internet access. An attacker must authenticate to the control panel and reach the affected element-search path. In practice, inventory roles that can use search, saved conditions or screens producing condition.config, rather than looking only at full administrators.

Access may come from a compromised editor, shared agency account, former contractor user or stolen session token. MFA and limiting the panel to VPN reduce the chance of entry, but they do not remove the flaw after a session is obtained. The PR:L vector should prompt review of the least-privileged accounts that still retain control-panel access.

A successful command runs as the web/PHP process user, not automatically as root. Impact therefore depends on operating-system permissions, environment-variable contents, database access, ability to write the webroot and network connectivity. In a typical CMS, however, this context is enough to read application configuration, alter content, code or accounts, and reach internal services.

Fixed releases and delayed disclosure

The first fixed releases are Craft CMS 4.18.2 and 5.10.6. Both were published on 16 June, and their release information identified fixes for high-severity RCE vulnerabilities. The public record containing technical scope appeared later, in line with the project’s policy of delaying details after delivery of a fix.

This model is intended to give operators time to update before full details. It also creates a trap for teams that ignore security releases until a CVE is assigned. If an organisation updates a CMS solely from an NVD feed, it can remain for weeks on a version the vendor has already identified as requiring a security fix.

Move to the latest supported patch in the 4.x or 5.x line, not merely the minimum 4.18.2/5.10.6. Before rollout, check PHP, plugin and migration requirements. Afterwards, confirm the version from the process handling traffic, exercise the control panel, element search, queues and tasks, and remove old images from active deployment slots.

Detection: linking a request to a child process

The strongest investigation combines three layers. In HTTP and application logs, search for unusual control-panel search requests, condition-decoding errors, object-construction exceptions and structures far more complex than a normal filter. In identity audit data, determine who logged into the panel, from which address, when roles changed and whether a session operated outside its normal schedule.

On the host, look for child processes of PHP-FPM or the web server, system-utility execution, project-file modifications, new files in webroot and uploads, configuration changes and unusual outbound traffic. A single command may be short-lived and fileless, which makes EDR and process telemetry more useful than a checksum comparison alone.

Do not publish or run a test payload against someone else’s site. Package inventory and a controlled regression test in an isolated environment owned by the organisation are enough to confirm version status. A production RCE attempt may change data, trigger hooks or create artifacts, becoming an incident itself.

Responding to suspected code execution

Isolate the node from traffic while preserving memory, logs, a disk image or snapshot as capabilities allow. Establish the parent process, time and control-panel account associated with the request. Examine webroot, configuration directories, plugins, modules, queue jobs, cron, SSH keys and Craft accounts. Review the history of content, template and project-configuration changes.

Map secrets exposed to the web process: database, storage, email, CDN and API credentials, plus environment keys. Rotate them after persistence is removed, beginning with values that grant continued access. If code execution is confirmed, rebuild from a clean artifact and a verified database; updating the package closes the vector but does not remove changes made beforehand.

In a multi-node environment, inspect shared storage, cache, queues and every replica. An attacker may have used one process to alter a resource loaded by all the others. A fresh container does not help when a malicious change remains in a volume, database or template stored outside the image.

Designing condition configuration safely

The strongest control is a positive schema. A parser should accept only defined condition types, fields and operators, reject unknown keys at every depth, and construct objects through explicit mapping. Client data should not flow directly into a general-purpose framework factory.

Cleansing must operate after final decoding and recursively, but a denylist of meta-keys remains fragile. The framework may add another syntax, alias or construction point. An allowlist of the business contract is more stable: a price filter may contain a field, operator and number, but not a class name, behavior, event handler or callable.

Add tests for nested objects, arrays, repeated encoding, unknown fields and different JSON types. Tests should also prove invalid configuration is rejected before object creation and cannot invoke setters, events or autoloading. Monitoring can measure condition JSON complexity and size, but limits do not replace a semantic schema.

Source facts and Breachroad conclusions

Affected versions, the authenticated path, condition.config cleansing bypass, behavior/event configuration interpretation and CVSS score come from the CVE record and researcher disclosure. Fix dates and versions 4.18.2/5.10.6 come from official Craft CMS releases. The sources used in this article do not report active exploitation.

The detection model, secret-scope analysis, allowlist recommendation and object-graph tests are Breachroad conclusions. AppSec and secure-coding training helps teams distinguish data from executable configuration, while application penetration testing can assess control-panel security, deserialisation and process containment.

Sources

• Craft CMS — release 5.10.6
• Craft CMS — release 4.18.2
• Craft CMS — security and disclosure policy
• HCKRT — technical disclosure for CVE-2026-78416
• NVD — CVE-2026-78416