Summary
e107 prior to version 2.3.8 contains an unsafe PHP deserialization flaw in the e_array handler that leads directly to code execution via eval().
An attacker who can write crafted data into the user_prefs database column can trigger arbitrary PHP execution when user preferences are loaded, potentially compromising the entire application.
e107 prior to version 2.3.8 contains an unsafe PHP deserialization flaw in the e_array handler that leads directly to code execution via eval().
An attacker who can write crafted data into the user_prefs database column can trigger arbitrary PHP execution when user preferences are loaded, potentially compromising the entire application.
Affected context
This vulnerability occurs in e107 installations that store user preferences in a database column and rely on the e_array::unserialize() handler to reconstruct these preferences at runtime.
It is relevant where out-of-band mechanisms (plugins, integrations, auxiliary services, or indirect database access paths) can write to the user_prefs column without robust validation.
The risk materializes when e_user_pref::load() is invoked for an affected user, causing the stored payload to be processed by eval() inside core_functions.php.
This vulnerability occurs in e107 installations that store user preferences in a database column and rely on the e_array::unserialize() handler to reconstruct these preferences at runtime.
It is relevant where out-of-band mechanisms (plugins, integrations, auxiliary services, or indirect database access paths) can write to the user_prefs column without robust validation.
The risk materializes when e_user_pref::load() is invoked for an affected user, causing the stored payload to be processed by eval() inside core_functions.php.
Exploit preconditions
- Attack surface: Application runtime when loading user preferences via e_user_pref::load()
- Required access: Ability to perform out-of-band writes or indirect modifications to the user_prefs database column
- Trigger point: Deserialization of the stored preference string by e_array::unserialize(), followed by eval() execution
- Why exploitation is possible: The handler performs only a simple prefix check for the string "array" and then passes the entire value to eval(), treating attacker-controlled data as PHP code
- Attack surface: Application runtime when loading user preferences via e_user_pref::load()
- Required access: Ability to perform out-of-band writes or indirect modifications to the user_prefs database column
- Trigger point: Deserialization of the stored preference string by e_array::unserialize(), followed by eval() execution
- Why exploitation is possible: The handler performs only a simple prefix check for the string "array" and then passes the entire value to eval(), treating attacker-controlled data as PHP code
Why this happens
The underlying bug is an unsafe deserialization pattern where serialized data is trusted and executed as code.
In e107, e_array::unserialize() assumes that any string starting with "array" represents a benign serialized structure and forwards it directly to eval().
This maps to CWE-502 (Unsafe Deserialization) because untrusted or indirectly controlled data is deserialized using an execution primitive, allowing arbitrary PHP to run whenever stored preferences are materialized.
The underlying bug is an unsafe deserialization pattern where serialized data is trusted and executed as code.
In e107, e_array::unserialize() assumes that any string starting with "array" represents a benign serialized structure and forwards it directly to eval().
This maps to CWE-502 (Unsafe Deserialization) because untrusted or indirectly controlled data is deserialized using an execution primitive, allowing arbitrary PHP to run whenever stored preferences are materialized.
Potential impact
- An attacker may execute arbitrary PHP code in the context of the web server.
- An attacker could read or modify application data, including credentials and configuration settings.
- An attacker can potentially escalate privileges within the application or underlying system, depending on environment hardening.
- An attacker may install backdoors or modify content, impacting site integrity and availability.
- An attacker may execute arbitrary PHP code in the context of the web server.
- An attacker could read or modify application data, including credentials and configuration settings.
- An attacker can potentially escalate privileges within the application or underlying system, depending on environment hardening.
- An attacker may install backdoors or modify content, impacting site integrity and availability.
General mitigation guidance
Effective mitigation typically focuses on removing execution semantics from deserialization paths and reducing trust in persisted data.
Recommended patterns include:
- Replace eval()-based reconstruction with safe, structured parsing or native serialization mechanisms that do not execute code.
- Enforce strict typing and schema validation on all preference data before deserialization, rejecting malformed or unexpected formats.
- Treat data read from the database as untrusted until validated, especially when written by asynchronous processes or third-party integrations.
- Apply least-privilege principles to application components that can modify user_prefs, limiting write capabilities to well-audited code paths.
- Introduce centralized sanitization and encoding routines for preference data to ensure it cannot be interpreted as executable PHP.
Effective mitigation typically focuses on removing execution semantics from deserialization paths and reducing trust in persisted data.
Recommended patterns include:
- Replace eval()-based reconstruction with safe, structured parsing or native serialization mechanisms that do not execute code.
- Enforce strict typing and schema validation on all preference data before deserialization, rejecting malformed or unexpected formats.
- Treat data read from the database as untrusted until validated, especially when written by asynchronous processes or third-party integrations.
- Apply least-privilege principles to application components that can modify user_prefs, limiting write capabilities to well-audited code paths.
- Introduce centralized sanitization and encoding routines for preference data to ensure it cannot be interpreted as executable PHP.
How teams detect issues like this
Detection generally combines code-level inspection with behavioral monitoring:
- Use static analysis to flag eval() usage and custom deserialization handlers that operate on database-backed fields like user_prefs.
- During code review, treat any function that converts strings to executable PHP (e.g., eval, create_function, dynamic includes) as a high-risk pattern, especially when input originates from persistence layers.
- Establish security linters or CI policies that block unsafe deserialization constructs and require justification or redesign for dynamic execution paths.
- Monitor application logs and database records for anomalous or code-like payloads in preference fields, which may indicate attempted exploitation.
Detection generally combines code-level inspection with behavioral monitoring:
- Use static analysis to flag eval() usage and custom deserialization handlers that operate on database-backed fields like user_prefs.
- During code review, treat any function that converts strings to executable PHP (e.g., eval, create_function, dynamic includes) as a high-risk pattern, especially when input originates from persistence layers.
- Establish security linters or CI policies that block unsafe deserialization constructs and require justification or redesign for dynamic execution paths.
- Monitor application logs and database records for anomalous or code-like payloads in preference fields, which may indicate attempted exploitation.
