Summary
Craft CMS contains a high-severity code injection vulnerability in its Twig sandbox handling, where authenticated Control Panel users may provide object-related properties that are processed without sufficient filtering.
Under affected configurations, an attacker could escape intended template restrictions and execute code with the privileges of the web application user.
Craft CMS contains a high-severity code injection vulnerability in its Twig sandbox handling, where authenticated Control Panel users may provide object-related properties that are processed without sufficient filtering.
Under affected configurations, an attacker could escape intended template restrictions and execute code with the privileges of the web application user.
Affected context
The vulnerability occurs in Craft CMS versions from 5.0.0 before 5.11.0 when an authenticated Control Panel user can influence Asset MIME-type transform processing. Risk increases where supplied object properties reach internal object creation and event or behavior registration without strict allowlisting.
The vulnerability occurs in Craft CMS versions from 5.0.0 before 5.11.0 when an authenticated Control Panel user can influence Asset MIME-type transform processing. Risk increases where supplied object properties reach internal object creation and event or behavior registration without strict allowlisting.
Exploit preconditions
- Attack surface: Craft CMS Control Panel and Asset MIME-type transform handling
- Required access: Authenticated Control Panel user access with the ability to submit or influence relevant asset-processing inputs
- Trigger point: Processing of Asset::getMimeType transforms
- Why exploitation is possible: User-controlled object-related keys are passed into internal object creation without adequate filtering, allowing unintended behaviors or event handlers to be attached
- Attack surface: Craft CMS Control Panel and Asset MIME-type transform handling
- Required access: Authenticated Control Panel user access with the ability to submit or influence relevant asset-processing inputs
- Trigger point: Processing of Asset::getMimeType transforms
- Why exploitation is possible: User-controlled object-related keys are passed into internal object creation without adequate filtering, allowing unintended behaviors or event handlers to be attached
Why this happens
The underlying issue is insufficient validation of user-controlled properties before they reach dynamic object construction and event or behavior registration.
When framework APIs treat input fields as trusted configuration, an attacker may influence application objects or execution hooks beyond the intended Twig sandbox boundary. This behavior maps to CWE-94: Improper Control of Generation of Code, because attacker-controlled data can affect executable application behavior.
The underlying issue is insufficient validation of user-controlled properties before they reach dynamic object construction and event or behavior registration.
When framework APIs treat input fields as trusted configuration, an attacker may influence application objects or execution hooks beyond the intended Twig sandbox boundary. This behavior maps to CWE-94: Improper Control of Generation of Code, because attacker-controlled data can affect executable application behavior.
Potential impact
- An attacker may execute arbitrary code as the web application user
- The application and its stored content could be compromised
- Sensitive configuration, credentials, or uploaded data could be exposed
- The attacker could modify site content or establish persistence
- Compromise could support lateral movement if the application has excessive privileges
- An attacker may execute arbitrary code as the web application user
- The application and its stored content could be compromised
- Sensitive configuration, credentials, or uploaded data could be exposed
- The attacker could modify site content or establish persistence
- Compromise could support lateral movement if the application has excessive privileges
General mitigation guidance
Mitigation generally focuses on preventing untrusted input from controlling object construction, behaviors, or event registration.
Common defensive patterns include:
- Applying strict allowlists for accepted transform and object properties
- Separating user-controlled data from executable configuration
- Enforcing server-side schema validation before framework object creation
- Preserving sandbox boundaries across all template and asset-processing paths
- Running the web application with least-privilege filesystem, database, and operating-system permissions
- Restricting administrative access with strong authentication, network controls, and narrowly scoped roles
Mitigation generally focuses on preventing untrusted input from controlling object construction, behaviors, or event registration.
Common defensive patterns include:
- Applying strict allowlists for accepted transform and object properties
- Separating user-controlled data from executable configuration
- Enforcing server-side schema validation before framework object creation
- Preserving sandbox boundaries across all template and asset-processing paths
- Running the web application with least-privilege filesystem, database, and operating-system permissions
- Restricting administrative access with strong authentication, network controls, and narrowly scoped roles
How teams detect issues like this
Detection approaches may include:
- Static analysis for user-controlled values passed to dynamic object factories or event-registration APIs
- Code review checks for unfiltered behavior, event, or class configuration fields
- Tests confirming that template and asset-processing inputs cannot create unintended objects or callbacks
- Monitoring Control Panel activity, asset-transform errors, unexpected process execution, and changes to application files
- Policy enforcement that requires allowlisted schemas for dynamic framework configuration
Automated code review and application-security testing tools can help identify unsafe data flows into object construction and execution-related APIs.
Detection approaches may include:
- Static analysis for user-controlled values passed to dynamic object factories or event-registration APIs
- Code review checks for unfiltered behavior, event, or class configuration fields
- Tests confirming that template and asset-processing inputs cannot create unintended objects or callbacks
- Monitoring Control Panel activity, asset-transform errors, unexpected process execution, and changes to application files
- Policy enforcement that requires allowlisted schemas for dynamic framework configuration
Automated code review and application-security testing tools can help identify unsafe data flows into object construction and execution-related APIs.
