PHP object injection in WordPress plugins: Why it’s on the rise and how to detect it

PHP object injection is no longer a niche issue in WordPress security. It has become a rapidly expanding vulnerability class with real-world exploitation at scale.

Highly exploitable WordPress vulnerabilities increased by 113% in 2025, according to Patchstack – a signal that attackers are prioritizing issues that can be weaponized across large numbers of sites. PHP object injection fits squarely into this category because it is often reachable, difficult to detect, and capable of high-impact outcomes.

Attackers are not targeting individual plugins in isolation. They scan large numbers of WordPress deployments indiscriminately, looking for any exposed deserialization point. In this model, plugin popularity is secondary – what matters is whether the vulnerability is reachable in a live environment.

The EssentialPlugin supply chain attack from April 2026 illustrates how this threat has evolved. A malicious backdoor was introduced in September 2025 during an ownership transition and remained dormant until April 2026. It affected 31 plugins, with a combined install base of roughly 400,000 sites based on declared installs, not confirmed compromises. The activation relied on an unauthenticated REST API endpoint that retrieved a serialized PHP object from an attacker-controlled server. This is a pattern invisible to static analysis but detectable through runtime testing.

Recent CVEs reinforce the same trend:

• CVE-2025-7697 – Google Sheets integration plugin, unauthenticated, 40,000+ installs
• CVE-2025-7384 – Database for Contact Form 7, CVSS 9.8, unauthenticated, 70,000+ sites
• CVE-2025-6464 – Forminator Forms, unauthenticated, 600,000+ installs – requires a separate plugin or theme with a usable gadget chain to achieve impact
• CVE-2025-6742 – SureForms, unauthenticated, 200,000+ installs

These are not isolated flaws. They reflect a systemic issue in how WordPress plugins process data and how PHP handles object deserialization. This is exactly the type of vulnerability class modern DAST platforms are designed to address by validating exploitability in running applications rather than identifying patterns in code alone.

How PHP object injection works: A case of unsafe deserialization

At the core of PHP object injection is a predictable but dangerous pattern: unsafe deserialization of user-controlled data.

Unsafe deserialization in PHP

PHP object injection originates from unsafe use of the unserialize() function. This function reconstructs PHP objects from serialized strings, including their properties and behaviors.

When attacker-controlled input is passed into unserialize(), the application effectively allows external control 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 arises when untrusted input is treated as trusted serialized data. In modern WordPress plugins, this pattern appears in cookies, AJAX handlers, REST APIs, and form processing logic.

Why WordPress environments amplify the risk

WordPress applications are particularly exposed because of how they are composed. A typical installation includes dozens of plugins and themes, each introducing its own PHP classes into the runtime.

This creates a large “gadget pool” – the collection of all PHP classes available in the application that can be chained together during deserialization. An attacker does not need the vulnerable plugin to contain a complete exploit chain. Other installed components can provide the missing pieces.

CVE-2025-7384 demonstrates this clearly. The vulnerable plugin alone did not provide a full exploitation path, but when combined with Contact Form 7, it enabled arbitrary file deletion through a gadget chain.

Key elements include:

• Magic methods such as __wakeup(), __destruct(), and __toString()
• Cross-plugin gadget chains built at runtime
• Interaction between core, plugins, and themes

This means exploitability depends on the full application context, not just the vulnerable code.

Real-world impact of successful exploitation

PHP object injection can lead to a range of high-impact outcomes:

• Remote code execution through chained method calls
• Arbitrary file deletion (for example, deleting wp-config.php effectively disables the site, resulting in a denial of service)
• SQL injection through unsafe property handling
• Authentication bypass and session manipulation
• Persistent access via web shell placement

In supply chain attacks, the impact can extend further. In the EssentialPlugin case, injected objects acted as loaders, retrieving instructions from external command-and-control servers and enabling ongoing compromise.

Even after patching, risk may persist. Serialized payloads stored in the database during the vulnerable period can remain exploitable depending on application logic, making remediation incomplete without data cleanup.

For security teams, this means the risk is immediate, practical, and potentially long-lived.

Why CVSS scores alone often underestimate the risk

CVSS provides a useful baseline for assessing vulnerability severity, and version 4.0 introduces supplemental metrics such as safety and automatable exploitation. However, it still cannot model environment-specific factors like the presence of gadget chains across plugins and themes.

As a result, PHP object injection vulnerabilities are often scored lower than their real-world exploitability in typical WordPress deployments would warrant. A vulnerability that appears moderate in isolation can become critical when combined with commonly installed components.

This highlights a key limitation of static scoring. It cannot account for runtime behavior or environmental complexity. Confirming exploitability in a live application is often more meaningful than relying on theoretical severity alone.

Why PHP object injection is difficult to detect in practice

Detecting PHP object injection is challenging because it is fundamentally a runtime problem.

Static analysis tools can identify and flag the insecure use of unserialize(), but they cannot determine whether attacker-controlled input reaches it in a deployed environment. They also cannot evaluate the presence of usable gadget chains across multiple plugins.

Black-box testing promises runtime verification but comes with its own challenges:

• The application may not produce visible output when a payload is processed
• Serialized data patterns are easy to recognize but hard to validate
• Exploitation often depends on indirect side effects rather than direct responses

This creates a detection gap. Many scanners either over-report based on patterns or under-report because they cannot confirm exploitability. PHP object injection sits directly in that gap.

Supply chain scenarios make this even more complex. If malicious payloads are fetched from external services rather than submitted directly by users, traditional scanning approaches may not observe the behavior at all. Detecting this requires observing how the application processes external data at runtime.

How Invicti detects and validates PHP object injection vulnerabilities

Addressing these detection challenges requires a fundamentally different approach from static or pattern-based analysis, which is where advanced dynamic application security testing (DAST) is especially useful. 

Runtime testing across the full application surface

Invicti’s DAST engine analyzes WordPress applications from the outside in, focusing on how they behave in production-like conditions. The scanner covers:

• Plugin-defined routes
• AJAX endpoints
• REST APIs
• Authenticated admin interfaces
• Custom forms and input handlers

Each input vector is tested with context-aware payloads. For PHP object injection, this includes serialized object strings designed to trigger controlled, non-destructive side effects when deserialized.

Unlike static tools, 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, meaning that the application processes malicious input without returning any visible indication of success.

Invicti addresses this with out-of-band detection. Payloads are constructed to trigger external interactions – such as DNS or HTTP callbacks – when deserialization occurs.

When a callback is received, it confirms:

• Attacker-controlled input reached unserialize()
• The deserialization process executed code
• The vulnerability is real and exploitable

This eliminates guesswork. Instead of reporting potential issues, Invicti provides confirmed findings backed by observable evidence to reduce false positives and focus teams on real risk.

What a confirmed finding looks like

An Invicti DAST finding for PHP object injection typically includes:

• The exact injection point – parameter, endpoint, or cookie
• The serialized payload used during testing
• Timestamped out-of-band callback evidence correlated to the originating 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 allows developers to understand, validate, and fix issues without additional investigation.

Detecting vulnerable plugins at scale

Invicti’s dynamic SCA automatically identifies WordPress components and correlates them with known vulnerabilities.

Using runtime fingerprinting techniques, it detects plugin versions based on file paths, scripts, and application behavior. When a vulnerable version is identified, Invicti performs targeted testing of known injection points.

This removes the need for manual configuration and ensures consistent coverage across large environments.

Using CI/CD to catch vulnerable plugins before production

The detection gap becomes even more pronounced when looking at how WordPress plugins are deployed and updated in practice. 

Why plugin vulnerabilities require runtime testing

WordPress plugin vulnerabilities often originate in third-party code. A simple plugin update can introduce a critical issue without any change to application code.

This makes the problem invisible to SAST tools. The vulnerability exists in dependencies and only becomes visible when the application is running.

The EssentialPlugin attack demonstrates this clearly. The malicious functionality was delivered through the plugin update mechanism itself. Without runtime testing, there is no reliable way to detect it.

Integrating Invicti into CI/CD pipelines

A practical integration pattern includes:

1. Triggering a scan after deployment to a staging environment
2. Evaluating results against defined severity thresholds
3. Failing builds when confirmed high or critical vulnerabilities are found
4. Automatically creating tickets in issue tracking systems

This ensures vulnerabilities are identified and addressed before reaching production.

Scanning on plugin updates

Plugin updates are a natural trigger point for security scans. Any change to the plugin set should initiate testing. This can be implemented by monitoring:

• Changes to plugin directories
• Dependency updates
• Deployment events affecting WordPress components

This approach ensures that vulnerabilities introduced through updates are detected immediately, reducing exposure windows.

Verifying remediation and reducing long-term risk

After patching a vulnerable plugin, a follow-up scan is essential to confirm resolution. Invicti provides comparison reporting that highlights resolved and remaining issues between scans.

There is also a critical post-remediation risk. Malicious data introduced before patching may persist in the database. Serialized objects stored during the vulnerable period can remain exploitable depending on application logic.

Security teams should:

• Audit and clean stored serialized data
• Replace unsafe deserialization patterns
• Use allowed_classes restrictions where necessary
• Reduce plugin count to limit the gadget pool
• Treat plugin ownership changes as a supply chain risk signal

These steps reduce both immediate risk and long-term exposure.

See how Invicti detects PHP object injection across your WordPress stack

PHP object injection vulnerabilities in WordPress plugins are increasing in both frequency and sophistication. The shift toward supply chain-driven attacks shows that detection methods must evolve alongside them.

Invicti’s proof-based DAST approach validates these vulnerabilities in running applications with out-of-band confirmation. Integrated into CI/CD pipelines, it ensures that vulnerable plugins are identified before they reach production.

Request a demo to see how Invicti detects and validates PHP object injection across your WordPress environment, and explore the vulnerability database to see what issues the scanner finds.