PHP object injection is becoming an increasingly serious vulnerability class across the WordPress ecosystem. Its growth is driven by the complexity of plugin-based environments and by large-scale exploitation observed in real attacks. The risk spans from widely deployed plugins with flaws that can be exploited without authentication to supply chain incidents affecting hundreds of thousands of websites. These weaknesses are difficult to identify and relatively easy to convert into practical attack techniques.
This article explains the mechanics of PHP object injection, the reasons traditional scanners often fail to detect it, and how modern DAST methods can uncover and confirm real exploitable risk before vulnerable code reaches production.
PHP object injection is no longer a rare or niche WordPress security concern.
It has developed into a fast-growing category of vulnerabilities that is already being exploited at scale.
According to Patchstack, the number of highly exploitable WordPress vulnerabilities rose by 113% in 2025. This trend shows that threat actors are increasingly focusing on weaknesses that can be reused across large numbers of sites. PHP object injection fits this pattern well because affected code is often reachable, the issue is hard to detect, and successful exploitation can have severe consequences.
Threat actors are not limiting their activity to specific plugins one by one. Instead, they scan large volumes of WordPress installations in search of any exposed deserialization entry point. In this model, the popularity of a plugin is less important than whether the vulnerable path can be accessed in a live deployment.
The EssentialPlugin supply chain attack in April 2026 demonstrates how this threat has evolved. A malicious backdoor was inserted in September 2025 during a change of ownership and stayed inactive until April 2026. The incident affected 31 plugins with a combined declared install base of about 400,000 sites. This number reflects stated installations, not confirmed compromises. The activation mechanism used an unauthenticated REST API endpoint that pulled a serialized PHP object from a server controlled by the attacker. Static analysis would not normally expose this behavior, while runtime testing can detect it.
Recent CVEs point to the same pattern:
- CVE-2025-7697 – Google Sheets integration plugin; exploitation does not require authentication; 40,000+ installs
- CVE-2025-7384 – Database for Contact Form 7; CVSS 9.8; exploitation does not require authentication; 70,000+ sites
- CVE-2025-6464 – Forminator Forms; exploitation does not require authentication; 600,000+ installs; real impact requires another plugin or theme that provides a usable gadget chain
- CVE-2025-6742 – SureForms; exploitation does not require authentication; 200,000+ installs
These cases are not separate, unrelated mistakes. They point to a broader weakness in the way WordPress plugins process data and in the way PHP handles object deserialization. This is the kind of vulnerability class that modern DAST platforms are designed to address. Rather than relying only on code patterns, they verify whether exploitation is possible in a running application.
How PHP Object Injection Works: Unsafe Deserialization in Practice
PHP object injection is based on a predictable but risky pattern: deserializing data that can be influenced by an external party.
Unsafe Deserialization in PHP
PHP object injection typically results from incorrect use of the unserialize() function. This function rebuilds PHP objects from serialized strings, including the object’s properties and behavior.
If input controlled by a threat actor is passed into unserialize(), the application effectively gives that external input influence over object creation and execution flow.
// Vulnerable
$data = $_COOKIE['user_prefs'];
$prefs = unserialize($data);
// Safer alternative
$data = $_COOKIE['user_prefs'];
$prefs = json_decode($data, true);The vulnerability appears when untrusted input is handled as if it were safe serialized data. In modern WordPress plugins, this pattern may appear in cookies, AJAX handlers, REST APIs, and form-processing logic.
Why WordPress Environments Increase the Risk
WordPress applications are especially exposed because of their modular architecture. A typical site runs many plugins and themes, and each of them can introduce its own PHP classes into the runtime environment.
This creates a broad “gadget pool” — the full set of PHP classes available inside the application that may be combined during deserialization. A vulnerable plugin does not have to contain a complete exploit chain on its own. Other installed components can supply the missing parts.
CVE-2025-7384 illustrates this clearly. The vulnerable plugin by itself did not provide a complete exploitation path. However, when it was used together with Contact Form 7, arbitrary file deletion became possible through a gadget chain.
Key elements include:
- Magic methods such as __wakeup(), __destruct(), and __toString()
- Gadget chains that are formed across plugins at runtime
- Interactions between WordPress core, installed plugins, and themes
This means exploitability depends on the complete application context, not only on the code of the vulnerable plugin.
Real-World Impact of Successful Exploitation
PHP object injection can result in multiple high-impact outcomes:
- Remote code execution through chained method calls
- Arbitrary file deletion, such as deleting wp-config.php, which effectively disables the site and causes a denial of service
- SQL injection caused by unsafe handling of object properties
- Authentication bypass and session manipulation
- Persistent access through placement of a web shell
In supply chain scenarios, the impact can be broader. In the EssentialPlugin incident, injected objects operated as loaders. They retrieved instructions from external command-and-control servers and supported continued compromise.
Risk can remain even after a vulnerable plugin is patched. Serialized payloads stored in the database during the vulnerable period may still be exploitable depending on how the application processes them later. Without data cleanup, remediation may therefore remain incomplete.
For security teams, this makes the risk immediate, practical, and potentially long-term.
Why CVSS Scores Alone Often Underestimate the Risk
CVSS is useful as a baseline for evaluating vulnerability severity. Version 4.0 also adds supplemental metrics such as safety and automatable exploitation. However, CVSS still cannot fully represent environment-specific factors, including the presence of gadget chains across different plugins and themes.
As a result, PHP object injection vulnerabilities may receive scores that are lower than their practical exploitability in typical WordPress environments would suggest. A weakness that appears moderate when viewed in isolation can become critical when combined with common components already present on a site.
This exposes an important limitation of static scoring. It cannot reflect runtime behavior or the complexity of a specific environment. In many cases, confirming exploitability in a live application is more valuable than relying only on theoretical severity.
Why PHP Object Injection Is Difficult to Detect in Practice
PHP object injection is difficult to detect because the issue is fundamentally connected to application behavior at runtime.
Static analysis tools can identify insecure use of unserialize() and mark it as suspicious. However, they cannot reliably determine whether attacker-controlled input can actually reach that function in a deployed environment. They also cannot assess whether usable gadget chains exist across multiple installed plugins.
Black-box testing can provide runtime verification, but it has its own limitations:
- An application may process a payload without producing any visible output
- Serialized data patterns are easy to recognize but difficult to prove exploitable
- Exploitation often relies on indirect side effects rather than direct application responses
This creates a detection gap. Some scanners report too many potential issues based on recognizable patterns. Others miss the issue entirely because they cannot confirm exploitability. PHP object injection sits directly in this gap.
Supply chain scenarios make detection even more complex. If malicious payloads are retrieved from external services rather than submitted directly by users, traditional scanning methods may not observe the behavior at all. Detection requires visibility into how the application processes external data while it is running.
How Invicti Detects and Validates PHP Object Injection Vulnerabilities
Solving these detection challenges requires a different approach from static or pattern-based analysis. Advanced dynamic application security testing (DAST) is especially useful in this context.
Runtime Testing Across the Full Application Surface
Invicti’s DAST engine examines WordPress applications externally and focuses on how they behave in conditions similar to production. The scanner covers:
- Plugin-defined routes
- AJAX endpoints
- REST APIs
- Authenticated admin interfaces
- Custom forms and input handlers
Every input vector is tested with payloads adapted to its context. For PHP object injection, this includes serialized object strings designed to trigger controlled, non-destructive side effects during deserialization.
Invicti DAST identifies vulnerabilities that are actually reachable and exploitable in the running application.
Proof-Based Validation with Out-of-Band Detection
Many PHP object injection vulnerabilities are blind. In such cases, the application processes malicious input without returning any visible sign that exploitation succeeded.
Invicti addresses this through out-of-band detection. Payloads are designed to trigger external interactions, such as DNS or HTTP callbacks, when deserialization takes place.
A received callback confirms that:
- Attacker-controlled input reached unserialize()
- The deserialization process executed code
- The vulnerability is real and exploitable
This removes uncertainty from the result. Instead of reporting only possible issues, Invicti provides confirmed findings supported by observable evidence. This reduces false positives and helps security teams focus on real risk.
What a Confirmed Finding Looks Like
An Invicti DAST finding for PHP object injection typically contains:
- The exact injection point, such as a parameter, endpoint, or cookie
- The serialized payload used during testing
- Timestamped out-of-band callback evidence linked to the original scan for blind vulnerabilities
- Full request and response data for context
- Severity classification and CVSS score
- Clear remediation guidance tailored to the vulnerability
This level of detail helps developers understand, verify, and fix the issue without additional investigation.
If you would like to test the capabilities of Invicti platform, please leave your contact details in the form below, and we will get in touch with you.
