Summary
A critical unsafe deserialization vulnerability in e107's installer allows unauthenticated attackers to submit crafted serialized data through the previous_steps parameter. When the installer remains reachable after deployment, this may enable arbitrary PHP function execution with the privileges of the web server process.
A critical unsafe deserialization vulnerability in e107's installer allows unauthenticated attackers to submit crafted serialized data through the previous_steps parameter. When the installer remains reachable after deployment, this may enable arbitrary PHP function execution with the privileges of the web server process.
Affected context
The vulnerability occurs in e107 installations where install.php remains accessible after a normal installation and processes attacker-controlled POST data. The affected code deserializes the previous_steps parameter more than once without restricting permitted classes, allowing bundled object behavior to reach a callable execution path.
The vulnerability occurs in e107 installations where install.php remains accessible after a normal installation and processes attacker-controlled POST data. The affected code deserializes the previous_steps parameter more than once without restricting permitted classes, allowing bundled object behavior to reach a callable execution path.
Exploit preconditions
- Attack surface: The publicly reachable e107 install.php endpoint
- Required access: No authentication is generally required if the installer can be reached
- Trigger point: Processing of the attacker-controlled previous_steps POST parameter
- Why exploitation is possible: Serialized objects are reconstructed without class restrictions, allowing a crafted object graph to influence a callable during string coercion
- Attack surface: The publicly reachable e107 install.php endpoint
- Required access: No authentication is generally required if the installer can be reached
- Trigger point: Processing of the attacker-controlled previous_steps POST parameter
- Why exploitation is possible: Serialized objects are reconstructed without class restrictions, allowing a crafted object graph to influence a callable during string coercion
Why this happens
The underlying flaw is unsafe deserialization of attacker-controlled data using unserialize() without an allowed-class policy or equivalent trust boundary. This maps to CWE-502: Deserialization of Untrusted Data, because serialized input can reconstruct objects whose methods, properties, or coercion behavior affect application execution before the data is treated as ordinary configuration.
The underlying flaw is unsafe deserialization of attacker-controlled data using unserialize() without an allowed-class policy or equivalent trust boundary. This maps to CWE-502: Deserialization of Untrusted Data, because serialized input can reconstruct objects whose methods, properties, or coercion behavior affect application execution before the data is treated as ordinary configuration.
Potential impact
- An attacker may execute arbitrary PHP functions
- The web server process could be compromised
- Application data and configuration may be modified or disclosed
- The server could be used for lateral movement or persistence
- Site integrity, availability, and confidentiality may be affected
- An attacker may execute arbitrary PHP functions
- The web server process could be compromised
- Application data and configuration may be modified or disclosed
- The server could be used for lateral movement or persistence
- Site integrity, availability, and confidentiality may be affected
General mitigation guidance
Mitigation generally focuses on eliminating unsafe deserialization of request data and reducing exposure of installation functionality.
Common defensive patterns include:
- Replacing object deserialization with structured formats such as JSON where object reconstruction is unnecessary
- Applying strict allowlists when deserialization is unavoidable
- Validating input against a narrow schema before processing it
- Ensuring installation and setup endpoints are disabled, removed, or access-controlled after deployment
- Avoiding dynamic callable resolution from user-controlled values
- Running the web process with least privilege and isolating application files and credentials
- Treating all installer parameters as untrusted regardless of their expected workflow
Mitigation generally focuses on eliminating unsafe deserialization of request data and reducing exposure of installation functionality.
Common defensive patterns include:
- Replacing object deserialization with structured formats such as JSON where object reconstruction is unnecessary
- Applying strict allowlists when deserialization is unavoidable
- Validating input against a narrow schema before processing it
- Ensuring installation and setup endpoints are disabled, removed, or access-controlled after deployment
- Avoiding dynamic callable resolution from user-controlled values
- Running the web process with least privilege and isolating application files and credentials
- Treating all installer parameters as untrusted regardless of their expected workflow
How teams detect issues like this
Detection can include static analysis for unserialize() calls that consume request parameters, especially when no allowed-class restriction is present. Code review should examine installer endpoints, duplicate deserialization paths, magic methods, string coercion, and data flows from serialized properties into callable or filesystem operations.
Runtime monitoring may flag unexpected requests to installation endpoints, unusual serialized payload patterns, process behavior inconsistent with normal CMS activity, and changes to installer files. CI policies and automated security review tools can enforce bans or approvals for unsafe deserialization APIs.
Detection can include static analysis for unserialize() calls that consume request parameters, especially when no allowed-class restriction is present. Code review should examine installer endpoints, duplicate deserialization paths, magic methods, string coercion, and data flows from serialized properties into callable or filesystem operations.
Runtime monitoring may flag unexpected requests to installation endpoints, unusual serialized payload patterns, process behavior inconsistent with normal CMS activity, and changes to installer files. CI policies and automated security review tools can enforce bans or approvals for unsafe deserialization APIs.
