CVE-2025-4665: Pre-Authentication SQL Injection in CFDB7 Puts 600,000+ WordPress Sites at Risk

Does your WordPress site use the Contact Form 7 Database Addon – CFDB7 plugin to store form submissions? Check your version immediately. CVE-2025-4665 is a critical SQL injection vulnerability. An unauthenticated attacker – someone with no account on your site at all – can query your database, steal sensitive data, and in some setups execute arbitrary code on your server.

With more than 600,000 active installations, CFDB7 ranks among the most popular add-ons in the Contact Form 7 ecosystem. That install base makes this vulnerability especially dangerous. Hundreds of thousands of sites remained exposed before a patch appeared in September 2025.

CVE-2025-4665 CFDB7 SQL injection: CVE Details at a Glance

• CVE ID: CVE-2025-4665
• Plugin: Contact Form 7 Database Addon – CFDB7 (by Arshid)
• Vulnerability type: SQL Injection (CWE-89) chained with PHP Object Injection
• CVSS 3.1 score: 9.6 (Critical)
• Affected versions: All versions up to and including 1.3.2
• Patched version: 1.3.3 (released September 16, 2025)
• Authentication required: None – fully pre-authentication
• Discovered by: Mandiant (MNDT-2025-0006)

CVE-2025-4665 CFDB7 SQL injection: How the Vulnerability Works

CFDB7 stores every Contact Form 7 submission in a custom database table. Site owners can then view and manage entries from the WordPress dashboard. The plugin includes a bulk-action feature. It lets administrators select multiple submissions and delete or export them.

The problem lies in how the plugin processes those bulk-action requests. User-supplied input – specifically the list of submission IDs to act on – flows directly into a SQL query without parameterization or sanitization. The endpoint does not verify that the request comes from a logged-in user. So an unauthenticated visitor can craft a malicious request and inject arbitrary SQL statements.

To make matters worse, the vulnerability chains into a second flaw: insecure deserialization. Data retrieved from the database through the injected query passes to PHP’s unserialize() function without restricting which classes can instantiate. If the site has any PHP library that includes a usable “gadget chain” – a sequence of class methods that can trigger during deserialization – then an attacker can pivot from reading data to executing code on the server.

In practical terms, this is a two-stage attack. First, SQL injection lets the attacker control what data the database returns. Then, insecure deserialization lets that controlled data trigger code execution. Each flaw is serious on its own. Together they create a path from zero access to full server compromise.

Real-World Impact

The consequences of this vulnerability depend on what your site stores and how your server configuration works. The range of possible damage is wide:

• Data theft: Contact form submissions often contain names, email addresses, phone numbers, and free-text messages. An attacker can exfiltrate all of this. If your forms collect payment details, medical information, or other regulated data, the breach becomes a compliance incident.
• Credential exposure: SQL injection against the WordPress database means the attacker can read the wp_users table, which contains hashed passwords. While hashed, weak passwords can crack offline.
• Database manipulation: Beyond reading data, an attacker can insert, modify, or delete records – including creating new administrator accounts.
• Remote code execution: If a suitable PHP gadget chain exists on the server (common in sites running multiple plugins), the deserialization flaw can let an attacker execute system commands, install backdoors, or deploy malware.
• Lateral movement: On shared hosting, a compromised site can sometimes access other sites on the same server.

Because the attack requires no authentication and can automate, it is the kind of vulnerability that gets swept up in mass-scanning campaigns within days of public disclosure.

How to Check If You Are Affected

Start by checking whether CFDB7 exists on your site:

1. Log in to your WordPress dashboard and go to Plugins → Installed Plugins.
2. Look for Contact Form 7 Database Addon – CFDB7 in the list.
3. Check the version number. If it is 1.3.2 or lower, your site is vulnerable.

If you manage multiple WordPress sites, you can also check via WP-CLI:

wp plugin list -fields=name,version,status | grep cfdb7

If the plugin exists but remains deactivated, it is not actively exploitable. But you should still update it before reactivating.

How to Fix It

The fix is straightforward: update CFDB7 to version 1.3.3 or later. The patch adds proper SQL parameterization using WordPress’s $wpdb->prepare() method. It also restricts deserialization by passing ['allowed_classes' => false] to prevent arbitrary object instantiation.

1. Go to Dashboard → Updates (or Plugins → Installed Plugins) and update CFDB7 to the latest version.
2. After updating, review your site for signs of compromise. Look for unfamiliar administrator accounts under Users → All Users. Check for recently modified files in your wp-content directory. Also review your server access logs for unusual POST requests to admin-ajax.php or admin-post.php.
3. If you find evidence of exploitation, change all administrator passwords. Revoke and regenerate WordPress salts and keys in wp-config.php. Consider restoring from a clean backup.
4. As an additional hardening measure, consider using a web application firewall (WAF) that can detect and block SQL injection payloads at the network edge.

Takeaway

CVE-2025-4665 is a textbook example of why input sanitization and parameterized queries are non-negotiable in plugin development – and why keeping plugins updated is the single most important security habit for WordPress site owners. A plugin that stores form data needs to handle that data internally with extra care. The database it reads from is also the database an attacker targets.

If you run CFDB7, update now. If you are not sure which plugins your site uses or whether they are current, now is a good time to audit. Checking takes a few minutes. Not checking can lead to a full site compromise.