Ultra Addons for Contact Form 7 vulnerability: check, update and recover

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

The Ultra Addons for Contact Form 7 vulnerability (CVE-2026-102435) affects plugin versions 3.5.54 and earlier when PDF Generator is enabled and a form uses it. Version 3.5.55 fixes the flaw. Check your installed version and PDF Generator settings first, then update and look for signs of deleted files.

What the Ultra Addons for Contact Form 7 vulnerability allows

CVE-2026-102435 is an unauthenticated PHP object injection flaw that can lead to arbitrary file deletion. An attacker does not need a WordPress account or administrator access.

The flaw is in how Ultra Addons for Contact Form 7 handles file paths during PDF generation. An attacker can abuse it to delete files that the web server's operating-system account has permission to delete.

PHP object injection means that untrusted input can be turned into a PHP object. That object may then cause code to run when PHP processes or destroys it. In this case, the result can be file deletion.

The Wordfence vulnerability advisory identifies two requirements beyond the affected plugin version:

• The PDF Generator add-on must be active.
• At least one Contact Form 7 form must be configured to generate PDFs.

Both conditions matter. A site with an affected plugin version but no active PDF Generator is outside the documented attack conditions.

Why deleting wp-config.php is dangerous

The wp-config.php file holds WordPress database connection details, authentication keys, salts and other settings.

If an attacker deletes that file, WordPress can lose its database configuration. Instead of showing the normal website, it may display the WordPress setup screen.

Whoever reaches that screen first may be able to point WordPress at a database they control, complete installation with their own administrator account and then run code on the server. This depends on the site's setup and file permissions. The CVE describes deletion of wp-config.php as a path to remote code execution.

File deletion alone does not guarantee a takeover. A missing configuration file can also cause database connection errors or server errors instead of a setup screen.

Which versions are affected, and what is fixed?

The vulnerability affects Ultra Addons for Contact Form 7 versions up to and including 3.5.54. The first patched release is 3.5.55.

The WordPress plugin changelog dates version 3.5.55 to October 11, 2026, with a note that issues reported by Wordfence were resolved. The public vulnerability disclosure followed on November 2.

Version 3.5.57 was released on November 1, 2026. It includes further PDF-related fixes. Install the latest available patched release rather than stopping at the minimum fixed version.

Why Wordfence and Patchstack give different scores

Wordfence assigns a CVSS 3.1 score of 9.8. Its assessment reflects an attack that requires no login and can severely affect confidentiality, integrity and availability.

Patchstack's advisory assigns 8.6 and labels the issue high priority.

The databases apply different scoring assessments. Neither score changes the affected versions or the need to patch.

Is CVE-2026-102435 being exploited?

As of November 5, 2026, the reviewed public advisories do not document confirmed attacks in the wild or identify a public proof-of-concept exploit.

CVE-2026-102435 is absent from CISA's Known Exploited Vulnerabilities catalog as of its November 4, 2026 update.

Patchstack says exploitation is expected. That is a forecast, not evidence of an observed attack.

The absence of public reports does not establish that an exposed site has never been targeted.

How to check whether your WordPress site is exposed

You can perform the first checks in the WordPress dashboard. WP-CLI, the WordPress command-line tool, helps when you have server access.

Step 1: Check the installed plugin version

Open Plugins > Installed Plugins and find Ultra Addons for Contact Form 7.

If the version is 3.5.54 or earlier, continue checking the PDF feature and plan an update.

From your WordPress installation directory, run:

wp plugin get ultimate-addons-for-contact-form-7 --field=version

Example output (illustrative):

3.5.54

This version is affected. A version of 3.5.55 or newer contains the reported fix.

If WP-CLI says the plugin is not installed, check that you are using the correct WordPress installation path.

Step 2: Check whether PDF Generator is enabled

Open the WordPress dashboard and go to:

UACF7 Addons > All Addons > PDF Generate

Find the PDF Generate switch and inspect its state.

An enabled switch means the add-on is active. A disabled switch means that part of the documented attack path is unavailable.

If you cannot find the setting, confirm that you are inspecting Ultra Addons on the correct WordPress installation.

Step 3: Check which forms generate PDFs

Go to:

Contact > Contact Forms > (edit the form) > Addons for CF7 Options > PDF Generator Settings > Enable PDF Generator

Check the Enable PDF Generator switch for each form.

Record which forms have it enabled and which published pages contain those forms.

Your site matches the documented vulnerable configuration when all these conditions are true:

1. Ultra Addons version is 3.5.54 or earlier.
2. The site-wide PDF Generate switch is enabled.
3. A Contact Form 7 form has Enable PDF Generator switched on.

A disabled module removes this documented attack path, but updating the plugin remains necessary.

How to update or disable PDF Generator safely

Before changing a working form, save its configuration and confirm that you have a usable backup. Record where generated PDFs are sent so you can check that behavior afterward.

Update Ultra Addons

In WordPress, open Plugins > Installed Plugins, find Ultra Addons and install its latest available update.

Developers can run:

wp plugin update ultimate-addons-for-contact-form-7

Then verify the installed version:

wp plugin get ultimate-addons-for-contact-form-7 --field=version

The expected result is 3.5.55 or newer. On November 5, 2026, the latest published version is 3.5.57.

After updating, open a form that generates PDFs and submit it with harmless sample details. Check whether the expected PDF is produced and reaches its intended destination.

If the site uses other Ultra Addons features, check those workflows as well.

Disable PDF Generator if you cannot update

Go to UACF7 Addons > All Addons > PDF Generate and switch it off.

Save the change, then confirm that the feature remains disabled.

Forms that depend on this add-on will stop generating their PDFs. That may affect emailed receipts, registration documents or other attachments. The underlying Contact Form 7 forms may still submit normally, depending on their configuration.

If you cannot confirm that PDF Generator is off, deactivate Ultra Addons entirely until you can patch it.

Use the dashboard or:

wp plugin deactivate ultimate-addons-for-contact-form-7

This disables the plugin's other add-on features too. Conditional fields, redirects, custom styling and other integrations may stop working.

Keep the plugin disabled until it is patched. Test affected forms before restoring normal traffic.

Triage checklist for each WordPress site

Use this table for one site or copy it into your incident notes. Record the result, the time checked and any action taken.

On a normal WordPress installation with an existing configuration, setup-config.php stops with a message that wp-config.php already exists, including when WordPress finds it one directory above the installation.

If the configuration setup form appears instead, do not enter credentials or complete installation. Restrict access and investigate. A custom server rule may block the setup URL entirely.

A passing checksum check or an empty log search does not prove the site is clean. These checks cover only the files and requests available to inspect.

Check plugin versions across several sites

For developers maintaining multiple WordPress installations, put the path to each site's WordPress root in a Bash array.

Replace the example paths with your actual paths:

#!/usr/bin/env bash

sites=(
"/var/www/site-one"
"/var/www/site-two"
"/var/www/site-three"
)

for site in "${sites[@]}"; do
printf '%s: ' "$site"

if wp --path="$site" plugin is-installed \
ultimate-addons-for-contact-form-7 2>/dev/null; then

wp --path="$site" plugin get \
ultimate-addons-for-contact-form-7 \
--field=version 2>/dev/null || echo "CHECK FAILED"
else
echo "NOT INSTALLED OR CHECK FAILED"
fi
done

Example output (illustrative):

/var/www/site-one: 3.5.54
/var/www/site-two: 3.5.57
/var/www/site-three: NOT INSTALLED OR CHECK FAILED

Check the first site immediately. Its reported version is vulnerable.

The second site has the patched version. Investigate any failed check, since an incorrect path or command error can affect the report.

This script checks versions only. Inspect PDF Generator settings and configured forms separately.

How to check if the vulnerability was already used

Updating stops the documented exploit path, but it does not restore deleted files.

If the site previously ran an affected version with PDF Generator enabled, inspect it for damage.

Check for a WordPress setup screen

Open the homepage and /wp-admin/setup-config.php in a private browser window.

If the configuration file exists, the setup script normally reports that wp-config.php already exists. If the configuration form appears, restrict public access immediately.

Do not enter database credentials or start a new installation.

Check the server's WordPress directory for wp-config.php. WordPress normally stores it in its installation root and also supports placing it one directory above that root.

A missing file is a serious finding, but it does not establish the cause. A failed deployment, manual change or hosting problem can produce similar symptoms.

Check files against official checksums

WP-CLI can compare WordPress core files and supported plugins against their official distributions.

Run:

wp core verify-checksums

Then check Ultra Addons:

wp plugin verify-checksums ultimate-addons-for-contact-form-7

These commands compare distributed files with checksums published by WordPress.org.

They do not verify wp-config.php, user uploads or all custom files.

If a checksum fails, record the affected file before making changes. Investigate missing core files, unexpected PHP files and altered plugin code.

If WP-CLI fails because WordPress cannot load its configuration, inspect the files through your hosting file manager, SSH or a backup copy.

Search access logs for suspicious Contact Form 7 submissions

Contact Form 7 commonly submits forms through its REST API endpoint:

/wp-json/contact-form-7/v1/contact-forms/{form-id}/feedback

Search your web server access logs for POST requests to that route.

For a typical Apache access log:

grep 'POST /wp-json/contact-form-7/v1/contact-forms/' \
/var/log/apache2/access.log

For a typical Nginx access log:

grep 'POST /wp-json/contact-form-7/v1/contact-forms/' \
/var/log/nginx/access.log

These are example log locations for common server configurations. Your hosting provider may store logs elsewhere, compress rotated files or retain them centrally.

The commands are text searches, not exploit detectors.

Normal form submissions also use this endpoint. Look for unexplained bursts, unfamiliar source addresses, unusual request patterns and submissions near the time files disappeared.

Check successful and failed HTTP responses. Correlate requests with file modification times, server errors and security alerts.

Some sites use alternate REST API URL formats. Search for the Contact Form 7 feedback route in those logs too.

Standard access logs often record request paths, methods, timestamps, source addresses and response codes. They may not contain the POST body needed to establish what was submitted.

Preserve the original logs before filtering or rotating them.

How to recover if wp-config.php or another file was deleted

A deleted configuration file can expose the site to further damage. Restrict access before restoring normal service.

Step 1: Restrict public access

Use your hosting control panel, web server configuration or an access-control rule to restrict the affected installation.

Make sure unauthorized visitors cannot reach the WordPress setup process.

Do not rely on WordPress maintenance mode when the configuration file is missing. WordPress may fail before its maintenance controls can run.

Preserve a copy of the current files and available logs before restoring anything.

Step 2: Restore the missing files from backup

Identify a known-good backup from before the suspected deletion.

Restore the original wp-config.php and any other missing files through your hosting backup system or a controlled file restore.

Avoid creating a fresh configuration through the public installer. The original file may contain database settings, table prefixes and site-specific constants that a new installation would not reproduce.

Check the restored configuration against the database and environment that the site is meant to use.

Restore deleted or modified core and plugin files from trusted packages or a verified backup. Review custom files and uploads separately.

A missing wp-config.php file alone does not mean the existing database has been erased. Confirm the database state before considering a full database restore.

Step 3: Rotate database credentials and WordPress salts

If the configuration file was deleted or unauthorized activity is suspected, change the site's database password.

Update the corresponding password in wp-config.php. Test the database connection through a restricted environment before reopening the site.

Replace the WordPress authentication keys and salts with fresh values. Once the original configuration is restored, run this command from the WordPress root:

wp config shuffle-salts

The WP-CLI shuffle-salts documentation confirms that this command refreshes the salts in wp-config.php.

Replacing these values invalidates existing authentication cookies and requires users to sign in again.

Protect the restored configuration file with appropriate ownership and permissions. Do not publish credentials or salt values in support tickets or incident reports.

Step 4: Check whether the site was taken over

Treat the incident as a confirmed compromise if you find unauthorized administrator accounts, unexpected database changes, injected code or evidence that an attacker completed a takeover.

A recovered homepage is not sufficient proof of a clean installation.

If an attacker reached the installer or gained administrator control, replacing the deleted file alone is insufficient.

Preserve evidence and follow the step-by-step guide to cleaning a hacked WordPress site. The cleanup must cover files, accounts, database contents, scheduled tasks and attacker persistence.

Do not reopen public access until the compromise has been contained and the site has been checked.

What the earlier PDF Generator flaw means for this decision

CVE-2026-102435 is the second serious unauthenticated vulnerability disclosed in the PDF Generator feature within weeks.

The earlier issue, CVE-2026-82901, was published on September 26, 2026. It affected versions through 3.5.50 and allowed arbitrary file uploads through a signature form field when PDF Generator was enabled.

That earlier flaw was fixed in version 3.5.51. The module was disabled by default.

The new file-deletion flaw affects versions through 3.5.54. It was disclosed on November 2, 2026.

The two issues have different technical causes and effects, but both require the same optional PDF Generator feature.

If your business does not need PDFs from contact forms, keep the module disabled after updating.

If PDFs are essential, keep the plugin updated, limit which forms use PDF generation and test the affected workflows after each update.

What to do after fixing the exposed sites

Record the affected sites, installed versions, PDF Generator status, update dates and any findings from the file and log checks.

Set up WordPress plugin vulnerability monitoring across your sites so new advisories reach the person responsible for updates.

Check that you can recover the site before another incident. Follow the process for testing a WordPress backup restore using a separate environment, with particular attention to configuration files and database access.

If any investigation confirms unauthorized changes, keep the site restricted and proceed with full incident cleanup.