Summary
Camaleon CMS contains an authenticated remote code execution flaw where attacker-controlled Ruby expressions in custom field options are evaluated on post edit pages.
Users with the ability to manage custom_fields can inject malicious Ruby code into the select_eval field type, leading to arbitrary server-side code execution under web server privileges.
Camaleon CMS contains an authenticated remote code execution flaw where attacker-controlled Ruby expressions in custom field options are evaluated on post edit pages.
Users with the ability to manage custom_fields can inject malicious Ruby code into the select_eval field type, leading to arbitrary server-side code execution under web server privileges.
Affected context
This vulnerability appears in Camaleon CMS deployments that:
- Enable and use the custom_fields feature
- Grant users the "custom_fields manage" permission or similar elevated content configuration rights
- Use the
select_evalcustom field type, which relies on dynamic Ruby evaluation in ERB views
The issue is triggered when a post edit page is rendered and the system processes the attacker-supplied expression from the field options.
This vulnerability appears in Camaleon CMS deployments that:
- Enable and use the custom_fields feature
- Grant users the "custom_fields manage" permission or similar elevated content configuration rights
- Use the
select_evalcustom field type, which relies on dynamic Ruby evaluation in ERB views
The issue is triggered when a post edit page is rendered and the system processes the attacker-supplied expression from the field options.
Exploit preconditions
- Attack surface: Administrative or privileged web interface for managing custom fields and editing posts
- Required access: Authenticated CMS account with permission to manage custom_fields (or compromise of such an account)
- Trigger point: Rendering of a post edit page that includes a
select_evalcustom field whose options contain the malicious expression - Why exploitation is possible: The CMS passes untrusted field option data directly into
instance_evalwithin an ERB view, allowing arbitrary Ruby code execution without validation or sandboxing
- Attack surface: Administrative or privileged web interface for managing custom fields and editing posts
- Required access: Authenticated CMS account with permission to manage custom_fields (or compromise of such an account)
- Trigger point: Rendering of a post edit page that includes a
select_evalcustom field whose options contain the malicious expression - Why exploitation is possible: The CMS passes untrusted field option data directly into
instance_evalwithin an ERB view, allowing arbitrary Ruby code execution without validation or sandboxing
Why this happens
The underlying bug stems from treating configuration-like data as executable code.
In this case, the select_eval custom field type stores Ruby expressions in its options and later evaluates them using instance_eval during view rendering.
This aligns with CWE-94: Improper Control of Generation of Code, where untrusted input is allowed to influence dynamically generated code that the application subsequently executes.
The insecure pattern is the direct use of dynamic evaluation APIs (instance_eval) on data that can be modified by users with elevated but not necessarily fully trusted roles, without strict whitelisting or static expression constraints.
The underlying bug stems from treating configuration-like data as executable code.
In this case, the select_eval custom field type stores Ruby expressions in its options and later evaluates them using instance_eval during view rendering.
This aligns with CWE-94: Improper Control of Generation of Code, where untrusted input is allowed to influence dynamically generated code that the application subsequently executes.
The insecure pattern is the direct use of dynamic evaluation APIs (instance_eval) on data that can be modified by users with elevated but not necessarily fully trusted roles, without strict whitelisting or static expression constraints.
Potential impact
- Attackers may execute arbitrary Ruby code on the server within the web application process.
- They could access or modify application data, including posts, users, and configuration settings.
- They can potentially read sensitive files or environment variables accessible to the web server.
- They may pivot to broader system compromise depending on server configuration and available libraries.
- They could deploy backdoors or create persistent malicious logic within the CMS environment.
- Attackers may execute arbitrary Ruby code on the server within the web application process.
- They could access or modify application data, including posts, users, and configuration settings.
- They can potentially read sensitive files or environment variables accessible to the web server.
- They may pivot to broader system compromise depending on server configuration and available libraries.
- They could deploy backdoors or create persistent malicious logic within the CMS environment.
General mitigation guidance
Effective mitigation focuses on eliminating unsafe dynamic code evaluation paths and tightening trust boundaries for configuration fields.
Common defensive patterns include:
- Removing or redesigning features that rely on evaluating user-supplied code (e.g., avoid
instance_evalon field options). - Constraining dynamic behavior to a small, well-defined set of declarative options rather than arbitrary Ruby expressions.
- Applying strict validation, whitelisting, or expression parsing that cannot produce executable code.
- Separating high-risk configuration capabilities (like advanced dynamic fields) from general administrative roles and limiting them to highly trusted operators.
- Running the application with least-privilege OS accounts and minimizing accessible system resources to reduce blast radius if evaluation does occur.
Effective mitigation focuses on eliminating unsafe dynamic code evaluation paths and tightening trust boundaries for configuration fields.
Common defensive patterns include:
- Removing or redesigning features that rely on evaluating user-supplied code (e.g., avoid
instance_evalon field options). - Constraining dynamic behavior to a small, well-defined set of declarative options rather than arbitrary Ruby expressions.
- Applying strict validation, whitelisting, or expression parsing that cannot produce executable code.
- Separating high-risk configuration capabilities (like advanced dynamic fields) from general administrative roles and limiting them to highly trusted operators.
- Running the application with least-privilege OS accounts and minimizing accessible system resources to reduce blast radius if evaluation does occur.
How teams detect issues like this
Organizations can detect similar issues by:
- Using static analysis rules to flag direct use of
eval,instance_eval, or similar dynamic execution APIs, especially in paths influenced by user or admin input. - Reviewing code for features that store executable code snippets in database fields or configuration options and are later evaluated at runtime.
- Implementing secure coding guidelines that disallow arbitrary code evaluation in templating and field configuration logic, enforced via code review checklists.
- Applying runtime application security monitoring to detect anomalous execution patterns or unexpected method calls triggered during view rendering.
Organizations can detect similar issues by:
- Using static analysis rules to flag direct use of
eval,instance_eval, or similar dynamic execution APIs, especially in paths influenced by user or admin input. - Reviewing code for features that store executable code snippets in database fields or configuration options and are later evaluated at runtime.
- Implementing secure coding guidelines that disallow arbitrary code evaluation in templating and field configuration logic, enforced via code review checklists.
- Applying runtime application security monitoring to detect anomalous execution patterns or unexpected method calls triggered during view rendering.
