CVE-2025-7384: PHP Object Injection in Database for Contact Form 7 Plugin (CVSS 9.8)

If you collect form submissions on your WordPress site, there is a good chance you are running one of the entry-storage add-ons that hooks into Contact Form 7, WPForms, or Elementor Forms. One of the most popular of those add-ons, the Database for Contact Form 7, WPforms, Elementor forms plugin, was found to contain a critical PHP Object Injection vulnerability tracked as CVE-2025-7384. With a CVSS score of 9.8, the flaw lets an unauthenticated attacker reach in over the public web and, in the worst case, delete wp-config.php and take over the site.

The plugin is installed on more than 70,000 sites. If you are one of them and you have not already updated to version 1.4.4, this post explains exactly what the vulnerability is, how attackers exploit it, what they can do once they are in, and how to lock the door behind you.

CVE Details

• CVE ID: CVE-2025-7384
• CVSS v3.1 score: 9.8 (Critical)
• Vulnerability type: PHP Object Injection via unsafe deserialization (CWE-502)
• Affected plugin: Database for Contact Form 7, WPforms, Elementor forms
• Affected versions: All versions up to and including 1.4.3
• Patched version: 1.4.4
• Authentication required: None (unauthenticated)
• Public disclosure: August 2025

The bug lives in the plugin’s get_lead_detail function, which feeds user-controlled data into PHP’s unserialize() without sanitization or validation. Because the request can be made without logging in, anyone on the internet can reach the vulnerable code path.

How the vulnerability works

PHP Object Injection is a class of vulnerability that occurs when an application calls unserialize() on data that an attacker can influence. The unserialize() function does not just decode a string; it rebuilds PHP objects in memory based on whatever class names and properties the serialized blob describes. If the application has any class with a “magic method” like __wakeup, __destruct, or __toString that performs sensitive actions, an attacker can craft a serialized object that triggers those methods on the server when the data is deserialized.

By itself, an unsafe unserialize() call only matters if useful “gadgets” exist somewhere in the loaded code. That is where Contact Form 7 enters the picture. When Contact Form 7 is active alongside the vulnerable database plugin, it ships classes whose magic methods can be chained together into what security researchers call a POP (Property-Oriented Programming) chain. Researchers analyzing CVE-2025-7384 demonstrated that this chain can be steered into arbitrary file deletion on the server, including the deletion of wp-config.php.

The attack flow is straightforward from the attacker’s perspective:

1. Send an unauthenticated request to the vulnerable endpoint with a carefully crafted serialized payload in place of the lead detail value.
2. The plugin calls unserialize() on the payload, instantiating Contact Form 7 objects with attacker-controlled properties.
3. When PHP later destroys those objects, the magic methods fire in a sequence the attacker has chosen, leading to arbitrary file deletion.
4. If wp-config.php is deleted, WordPress falls back to its installation wizard the next time someone visits the site.
5. The attacker walks through that wizard, points the site at a database they control or the original database with new credentials, and emerges as the administrator.

For a deeper look at this class of bug, see our explainer on PHP Object Injection in WordPress.

Real-world impact

An unauthenticated remote vulnerability rated 9.8 in a plugin running on tens of thousands of business sites is about as bad as a WordPress flaw gets. Concretely, an attacker who successfully exploits CVE-2025-7384 can:

• Delete wp-config.php, forcing the site into reinstallation mode and giving the attacker a path to administrative takeover.
• Cause a full denial of service by deleting other critical files such as index.php or core PHP files, taking the site offline.
• Stage further attacks, including uploading webshells, dropping backdoors, exfiltrating customer data captured in form submissions, and pivoting into other sites that share the same hosting account.
• Read submitted form data already collected by the plugin, which can include names, email addresses, phone numbers, mailing addresses, and free-text fields that may contain sensitive information.

Because exploitation requires no authentication, automated scanners and botnets can spray exploit requests across the entire WordPress ecosystem. Critical PHP Object Injection bugs of this kind have historically been weaponized within hours of public disclosure.

How to check if you are affected

The vulnerable plugin is sometimes mistaken for the official Contact Form 7 plugin because of the similar name. To check whether you have it installed and which version is running:

1. Log in to your WordPress admin dashboard and navigate to Plugins → Installed Plugins.
2. Search for Database for Contact Form 7. The plugin slug is advanced-cf7-db, so you can also look for that string in the plugin description or under wp-content/plugins/advanced-cf7-db/ via SFTP.
3. If the plugin is present, note the version number listed beneath its title. Anything 1.4.3 or earlier is vulnerable.
4. Confirm whether Contact Form 7 itself is also installed, since that combination is what unlocks the file-deletion gadget chain. Even without Contact Form 7, however, you should still treat the plugin as exploitable, because other gadget chains may exist.

If you manage many sites, you can query each site’s REST API or use WP-CLI to enumerate plugin versions in bulk:

wp plugin list --format=csv | grep advanced-cf7-db

How to fix it

The vendor released version 1.4.4 to address the vulnerability. Updating is the single most important step, but because this is a deserialization flaw, there are a few extra hardening actions worth taking.

1. Update the plugin

From Plugins → Installed Plugins, click Update Now for Database for Contact Form 7 until the version reads 1.4.4 or later. If automatic updates are disabled, you can update through WP-CLI:

wp plugin update advanced-cf7-db

2. Audit your database for malicious payloads

The patch in 1.4.4 only conditionally deserializes older records, which means malicious data inserted before the update may still be triggered later. Take a backup, then review entries stored by the plugin (typically in custom tables prefixed with wpcf7_ or similar) for unusual serialized strings beginning with O: followed by a class name. Anything that looks like a serialized PHP object rather than plain text should be deleted or quarantined.

3. Confirm the site has not already been compromised

If your site was running a vulnerable version while exploit attempts were active, assume breach until proven otherwise. Check for:

• Unfamiliar administrator accounts in Users → All Users.
• Recent changes to wp-config.php, .htaccess, or files in wp-content/uploads/.
• Unexpected scheduled tasks under wp_options -> cron.
• Modified core files (compare against a clean copy of WordPress).
• Outbound connections from your server to unfamiliar IP addresses.

If you find evidence of compromise, follow our recovery guide on what to do when your WordPress site has been hacked.

4. Add defense in depth

A web application firewall can virtually patch this kind of bug while you roll out the update across many sites. Make sure your WAF is set to inspect and block POST bodies containing PHP serialized objects targeting known WordPress endpoints. Combine that with file integrity monitoring so that a deletion of wp-config.php alerts you immediately rather than after the site is reinstalled by an attacker.

Takeaway

CVE-2025-7384 is a textbook PHP Object Injection bug: an innocuous-looking unserialize() call in a popular plugin, weaponized through the gadget classes of another popular plugin sitting next to it. The fix on your end is simple, but the lesson is broader. WordPress sites accumulate plugins over time, and a critical vulnerability in a single one of them can cascade into a full takeover when combined with whatever else you happen to be running.

Keep your plugin inventory lean, update promptly, audit the data your plugins store, and assume that the next critical CVE is already being scanned for. The sites that come through these waves intact are not the ones running the fewest plugins or the most exotic stack; they are the ones with disciplined update routines, monitoring, and a backup they can actually restore from.