Summary
FacturaScripts contains an unsafe deserialization flaw in WidgetSelect::processFormData() that can process attacker-controlled serialized PHP objects from multiple-select form fields. An authenticated attacker may abuse this behavior to delete selected application or backup files, potentially causing denial of service or enabling an application reinstall hijack.
FacturaScripts contains an unsafe deserialization flaw in WidgetSelect::processFormData() that can process attacker-controlled serialized PHP objects from multiple-select form fields. An authenticated attacker may abuse this behavior to delete selected application or backup files, potentially causing denial of service or enabling an application reinstall hijack.
Affected context
The vulnerability occurs in FacturaScripts deployments where authenticated users can submit multiple-select form data handled by WidgetSelect::processFormData(). Risk is present when raw POST values reach unserialize() without an allowed_classes restriction and the resulting object lifecycle can invoke destructive behavior. The practical impact depends on the web process permissions and the files accessible to that process.
The vulnerability occurs in FacturaScripts deployments where authenticated users can submit multiple-select form data handled by WidgetSelect::processFormData(). Risk is present when raw POST values reach unserialize() without an allowed_classes restriction and the resulting object lifecycle can invoke destructive behavior. The practical impact depends on the web process permissions and the files accessible to that process.
Exploit preconditions
- Attack surface: Authenticated web application form handling - Required access: A valid account permitted to submit the affected form data - Trigger point: Processing a multiple-select field in
WidgetSelect::processFormData()
- Attacker-controlled input: A serialized PHP object supplied through POST
data
- Why exploitation is possible: Raw input is passed to unserialize() without
restricting which classes may be instantiated, allowing object destructor
behavior to affect accessible files
- Attack surface: Authenticated web application form handling - Required access: A valid account permitted to submit the affected form data - Trigger point: Processing a multiple-select field in
WidgetSelect::processFormData()
- Attacker-controlled input: A serialized PHP object supplied through POST
data
- Why exploitation is possible: Raw input is passed to unserialize() without
restricting which classes may be instantiated, allowing object destructor
behavior to affect accessible files
Why this happens
The underlying bug is unsafe deserialization of attacker-controlled PHP data. Calling unserialize() on raw request input without an allowed_classes policy permits unexpected classes to be reconstructed and their magic methods to run during the object lifecycle. This maps to CWE-502, Unsafe Deserialization, because untrusted serialized data is treated as a valid object graph rather than as constrained application data.
The underlying bug is unsafe deserialization of attacker-controlled PHP data. Calling unserialize() on raw request input without an allowed_classes policy permits unexpected classes to be reconstructed and their magic methods to run during the object lifecycle. This maps to CWE-502, Unsafe Deserialization, because untrusted serialized data is treated as a valid object graph rather than as constrained application data.
Potential impact
- An attacker may delete application files such as configuration files.
- The vulnerability could remove backup data or other files accessible to the web process.
- Successful abuse can cause application denial of service.
- Deleting key files may enable or contribute to an application reinstall hijack.
- The affected application could lose integrity or availability.
- An attacker may delete application files such as configuration files.
- The vulnerability could remove backup data or other files accessible to the web process.
- Successful abuse can cause application denial of service.
- Deleting key files may enable or contribute to an application reinstall hijack.
- The affected application could lose integrity or availability.
General mitigation guidance
Mitigation generally centers on eliminating unsafe deserialization of request data and reducing the trust placed in serialized client input. Prefer simple, schema-validated representations such as bounded identifiers or structured data formats that do not instantiate executable objects. Where PHP deserialization cannot be avoided, use strict class allowlists and validate the expected type and structure before processing. Enforce authorization for sensitive form operations, isolate configuration and backup files from the web process, and apply least-privilege filesystem permissions. Secure-by-default workflows should also prevent user-controlled values from selecting arbitrary filesystem paths.
Mitigation generally centers on eliminating unsafe deserialization of request data and reducing the trust placed in serialized client input. Prefer simple, schema-validated representations such as bounded identifiers or structured data formats that do not instantiate executable objects. Where PHP deserialization cannot be avoided, use strict class allowlists and validate the expected type and structure before processing. Enforce authorization for sensitive form operations, isolate configuration and backup files from the web process, and apply least-privilege filesystem permissions. Secure-by-default workflows should also prevent user-controlled values from selecting arbitrary filesystem paths.
How teams detect issues like this
Detection can include static analysis for unserialize() calls that consume request parameters, especially where no allowed_classes restriction is present. Code review should examine magic methods such as __destruct() on classes reachable from deserialized data, as well as form handlers that pass raw POST values into object APIs. Runtime monitoring can alert on unusual deletion attempts involving configuration or backup paths. CI policy checks and automated review tools may flag unsafe deserialization and unrestricted filesystem operations.
Detection can include static analysis for unserialize() calls that consume request parameters, especially where no allowed_classes restriction is present. Code review should examine magic methods such as __destruct() on classes reachable from deserialized data, as well as form handlers that pass raw POST values into object APIs. Runtime monitoring can alert on unusual deletion attempts involving configuration or backup paths. CI policy checks and automated review tools may flag unsafe deserialization and unrestricted filesystem operations.
