Description

The Live Composer – Free WordPress Website Builder plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 2.1.18 via deserialization of untrusted input . This makes it possible for authenticated attackers, with contributor-level access and above, to inject a PHP Object. No known POP chain is present in the vulnerable software, which means this vulnerability has no impact unless another plugin or theme containing a POP chain is installed on the site. If a POP chain is present via an additional plugin or theme installed on the target system, it may allow the attacker to perform actions like delete arbitrary files, retrieve sensitive data, or execute code depending on the POP chain present.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-08T12:16:52.443Z",
  "pubdate": "2026-09-08T12:16:52.443Z",
  "executiveSummary": "The Live Composer – Free WordPress Website Builder plugin is susceptible to a PHP Object Injection vulnerability affecting all versions up to and including 2.1.18.\nThis vulnerability originates from the insecure deserialization of untrusted user-supplied input, allowing authenticated attackers with at least contributor-level privileges to inject malicious PHP objects into the application scope.\nThe inherent risk of this flaw is contingent upon the existence of a Property Oriented Programming (POP) chain within the local environment, such as those present in other installed plugins or themes.\nWithout a pre-existing POP chain, the vulnerability lacks a direct execution vector. However, if a valid gadget chain is accessible within the WordPress environment, an attacker can leverage the injection to execute arbitrary code, delete sensitive files, or exfiltrate restricted data.\nThe attack is limited to authenticated users, requiring at least contributor-level access, thereby mitigating risk from unauthenticated external actors, but remaining a critical threat from malicious or compromised internal user accounts.",
  "technicalDetails": "The root cause of this vulnerability is the application's failure to sanitize or validate user-supplied input before passing it to the PHP unserialize() function. PHP Object Injection occurs when an attacker can control the serialized string passed to this function, leading to the instantiation of arbitrary PHP objects within the application's memory space.\nBy manipulating the serialized input, an attacker can define the properties of the instantiated object. While the Live Composer plugin itself does not contain a built-in gadget chain (POP chain), the vulnerability exploits the underlying PHP architecture where magic methods—such as __wakeup(), __destruct(), or __toString()—are automatically triggered during or after the object's lifecycle.\nThe attack flow proceeds as follows: First, the attacker identifies an injection point where user input is processed via unserialize(). Second, the attacker crafts a malicious serialized payload containing serialized object data that targets classes already loaded into the WordPress environment. Third, the attacker submits this payload through the vulnerable plugin interface while authenticated as a contributor or higher. Upon processing the request, the application unserializes the object, triggering the associated magic methods.\nThe post-exploitation impact is entirely dependent on the availability of 'gadgets'—existing classes in the WordPress codebase, themes, or other plugins that perform dangerous operations (e.g., file system manipulation, database interaction, or execution of system commands) within their magic methods. If an attacker discovers a suitable gadget chain, the deserialization process allows them to chain these operations to achieve Remote Code Execution (RCE), arbitrary file deletion, or sensitive information disclosure.\nThis vulnerability is classified as a significant security flaw because it transforms a standard input parameter into a vehicle for privilege escalation and system compromise. The requirement for contributor-level authentication restricts the attack surface but does not eliminate the risk, as WordPress sites often contain multiple users with contributor privileges. Defenders must treat the presence of unserialize() on user-controlled input as a critical security debt."
}