CVE-2026-115190 in Mautic
Summary
by MITRE • 10/26/2026
An insecure deserialization (PHP object injection) vulnerability exists in Mautic's handling of segment filters and custom field properties. Several code paths that read these stored values from the database deserialize them without restricting which PHP classes may be instantiated, instead of using Mautic's safe deserialization helper. An attacker who is able to store a crafted serialized value in these segment filter or custom field properties can cause arbitrary PHP objects to be instantiated when Mautic later processes the data, for example during segment evaluation, contact export, or custom field API requests. Combined with gadget chains available in Mautic's dependencies, this could allow an attacker to execute arbitrary code on the server, read, modify, or delete data stored in the Mautic instance, including contact data, and affect its availability. Exploitation requires high privileges or an existing ability to write to the affected stored data.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified as a PHP object injection flaw within the Mautic marketing automation platform stems from improper handling of serialized data during deserialization processes. Specifically, code paths responsible for reading segment filters and custom field properties from the database fail to restrict which PHP classes may be instantiated when unserializing these values. Instead of utilizing Mautic's designated safe deserialization helper functions that enforce strict class whitelisting or type checking, the application directly invokes standard PHP serialization mechanisms on user-controllable input stored in persistent storage. This architectural oversight allows an attacker who has gained the ability to write crafted serialized payloads into segment filter configurations or custom field properties to trigger arbitrary object instantiation when Mautic subsequently processes this data during routine operations such as segment evaluation, contact export generation, or API requests involving custom fields.
From a technical perspective, this flaw aligns with CWE-502, which describes Deserialization of Untrusted Data, and is further characterized by the lack of integrity verification for serialized objects. The exploitation mechanism relies on the presence of gadget chains within Mautic's dependency tree. Gadget chains are sequences of existing PHP classes whose methods can be chained together to achieve a malicious outcome, such as remote code execution or file inclusion, without requiring new vulnerabilities in those specific libraries. When an attacker injects a serialized object that references these gadgets into the vulnerable fields, the subsequent deserialization process instantiates these objects and executes their magic methods, effectively bypassing security controls due to the unrestricted nature of the unserialization routine.
The operational impact of this vulnerability is severe, potentially leading to full server compromise if sufficient gadget chains are available within the environment. An attacker could execute arbitrary code on the backend server, gaining control over the underlying operating system processes associated with the web application. Beyond remote code execution, the flaw enables unauthorized access to sensitive data stored within the Mautic instance. This includes personal contact information, email lists, and campaign analytics, which can be read, modified, or deleted by the attacker. Furthermore, the ability to manipulate segment filters could allow for denial of service conditions by causing resource exhaustion during complex segment evaluations or corrupting critical configuration settings that affect application availability.
Exploitation of this vulnerability requires a high level of privilege within the Mautic interface or an existing capability to write data into the affected database fields. This typically means that low-privilege users cannot directly exploit the flaw unless they can manipulate inputs through other vulnerabilities such as cross-site scripting or insecure direct object references that allow them to inject serialized payloads into segment filters or custom field definitions. Once the payload is stored, it remains dormant until a privileged action triggers its deserialization, making this an asynchronous attack vector that requires careful timing and persistence in data injection efforts.
To mitigate this risk, immediate remediation should focus on enforcing strict class whitelisting during all deserialization operations within Mautic. Developers must ensure that the safe deserialization helper is utilized exclusively for processing any serialized data originating from user inputs or database storage, thereby preventing the instantiation of unexpected PHP classes. Additionally, implementing input validation and sanitization at the point of entry for segment filters and custom field properties can prevent malicious payloads from being stored in the first place. Security teams should also review dependency versions to identify if known gadget chains are present and consider upgrading libraries where possible. Monitoring logs for unusual deserialization errors or unexpected object instantiations can aid in detecting attempted exploitation activities before they result in successful compromise.