If you use Duplicator to move WordPress sites between hosts, domains or staging servers, check which version you are on before your next migration. CVE-2026-82814 is an unauthenticated PHP object injection in Duplicator (free) up to and including 1.5.17 and Duplicator Pro up to and including 4.6.10. It is rated 8.8 (High). Duplicator has more than 1 million active installations, and according to Dr. Web’s write-up, about 61% of them were still on the 1.4 and 1.5 branches as of October 21, 2026.
What makes this one unusual is the two-stage attack. The attacker does not need an account and does not need to reach Duplicator at all. They leave a crafted comment on your site, and it sits in the database, even while it is still pending moderation, until you build a package and run the migration. As of 2026-10-25 no exploitation has been reported and CISA has not added it to its catalog. Because the trigger is your own next migration, the fix is quick: update first, then clean up.
The fix: update to Duplicator 5.0.0 or later
The vendor fixed it in 5.0.0, released on September 8, 2026. Starting with 5.0.0, the free and Pro editions ship from one codebase, which is why the version number jumps from 1.5.17 straight to 5.0.0. If your plugin screen shows 1.5.x or Pro 4.6.x, you are on a vulnerable build. The current release on WordPress.org is 5.0.6.
Take a backup of the files and database first. Then check and update with WP-CLI:
# Show every Duplicator plugin (free and Pro) and its version
wp plugin list --fields=name,version,status,update | grep -i duplicator
# Update the free plugin from WordPress.org
wp plugin update duplicator
# Confirm you are on 5.0.0 or newer
wp plugin get duplicator --field=versionPro builds update through your Duplicator license, so use the Plugins screen or download the new zip from your Duplicator account. If you manage many sites, run the wp plugin list line over all of them. Every site with a 1.5.x or 4.6.x version is a candidate.
Step 2: throw away old packages and installer files
Updating the plugin does not fix packages you already built, because each package bundles its own installer. An archive created with 1.5.17 still has the vulnerable installer inside. Delete those packages and build new ones after the update.
Also remove installer files left behind by earlier migrations. Look for them on every site you have ever migrated to:
# Run from the site's document root; review the output before deleting anything
find . -maxdepth 2 ( -name 'installer.php' -o -name '*_installer.php'
-o -name 'installer-backup.php' -o -name 'dup-installer'
-o -name '*_archive.zip' -o -name '*_archive.daf' ) -printLeftover installers and archives in a public directory are a risk even without this CVE. I explained why in Never, EVER leave any backups inside your domain document root.
Step 3: check comments before you build a package
The payload is a serialized PHP object stored in public content, and comments are the documented carrier. Turning on moderation does not protect you, because WordPress stores pending comments in the same table that gets migrated. Before you create a new package, search for serialized object strings in comments. This query is read-only:
-- Replace wp_ with your table prefix (wp db prefix)
SELECT comment_ID, comment_approved, comment_author_IP, comment_date
FROM wp_comments
WHERE CONCAT_WS(' ', comment_author, comment_author_email, comment_author_url, comment_content)
REGEXP 'O:[0-9]+:"|C:[0-9]+:"';Or with WP-CLI, which picks up the prefix automatically:
P=$(wp db prefix)
wp db query "SELECT comment_ID, comment_approved, comment_date FROM ${P}comments WHERE CONCAT_WS(' ', comment_author, comment_author_url, comment_content) REGEXP 'O:[0-9]+:"|C:[0-9]+:"'"
# Review, then permanently delete the matches (no trash)
wp comment delete 123 456 --force
# While you are at it, clear out the moderation queue and spam
wp comment delete $(wp comment list --status=hold --format=ids) --force
wp comment delete $(wp comment list --status=spam --format=ids) --forceReal visitors almost never write O:8:" in a comment, so any match deserves a close look. If you want to wipe comments entirely before a migration, I covered several methods in How to delete all comments in WordPress.
Why this works
During a migration, the Duplicator installer runs a database search-and-replace to swap the old URL for the new one. Serialized data can’t be edited as plain text, so the installer unserializes values to test and fix them, in DUPX_UpdateEngine::unserializeTest() according to the CVE record. A malicious comment containing a serialized object therefore turns into a live PHP object inside the installer process.
- Duplicator free: the bundled Requests 1.7 library provides a gadget chain that can lead to OS command execution.
- Duplicator Pro: a destructor gadget can delete any existing file the installer’s PHP process can write to. If that file is
wp-config.php, WordPress shows the setup wizard, and whoever reaches it first can point the site at their own database.
Building a backup alone does not trigger it, and Wordfence did not identify a restore as a trigger either. The danger is the migrate or import step with search-and-replace on a package built after the malicious content was stored. That is why updating the plugin, rebuilding packages and cleaning comments covers the whole chain.
If you already migrated with an old version
Most migrations were not attacked. Still, if you ran a 1.5.x or Pro 4.6.x migration recently, spend five minutes on the destination site:
# wp-config.php must exist and point to YOUR database
ls -l wp-config.php
wp config get DB_NAME
wp config get DB_HOST
# Core files untouched?
wp core verify-checksums
# Any admin accounts you don't recognize?
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredIf DB_HOST is a server you don’t own, or there are admins you didn’t create, treat the site as compromised. Follow How to clean up a hacked WordPress site, and check whether you have a breach-reporting duty. Under GDPR Article 33 that window is 72 hours.
Migrating without a plugin installer in OpenPanel
If both sites live on the same server, you often don’t need a migration plugin at all. In OpenPanel’s WordPress Manager, the Clone tab copies the files and database tables and updates the links for you. Backups (files, database, or both) are made and restored from the same screen, so no installer.php ever lands in a public folder. In cPanel the closest match is the Backup and Backup Wizard pages, or WP Toolkit if your host provides it. Those also work without a public installer script, but URL changes are usually up to you.
Prevention
- Update migration and backup plugins before every migration, not only when you remember. They run code that touches your entire database.
- Build packages right before you migrate and delete them afterward. Don’t reuse an archive from months ago.
- Empty the spam and pending comment queues before packaging. They are attacker-controlled data that you are about to feed into a search-and-replace.
- After any migration, remove the installer, the archive and the
dup-installerfolder, and confirmwp-config.phpis intact.
TL;DR
CVE-2026-82814 affects Duplicator up to 1.5.17 and Duplicator Pro up to 4.6.10. A crafted comment, even an unapproved one, turns into code execution (free) or deletion of wp-config.php (Pro) when you later migrate. Back up, update to 5.0.0 or later (5.0.6 is current as of 2026-10-25), delete old packages and leftover installer files, search your comments for serialized objects, and rebuild packages only after updating.
