An Anonymous Comment Can Hand Duplicator a Payload That Fires at Migration Time, and Under a Third of Free Installs Run the Fix

Wordfence disclosed on Tuesday, October 20 a flaw in Duplicator, the WordPress backup and migration plugin with more than one million active installs, and in its paid Pro edition. The flaw, CVE-2026-82814, is a PHP object injection that Wordfence rates 8.8 (High) on CVSS 3.1. What makes it unusual is when it fires. An anonymous visitor can leave a comment that does nothing on arrival. If an administrator later builds a Duplicator package that includes the comment and runs a standard migration or import from it, the package’s installer reads the stored text as a PHP object and activates it. Wordfence says that gives an attacker an operating-system command on the Free edition, and on Pro a file-deletion primitive that it developed into a site takeover.

The fix shipped six weeks ago, in Duplicator 5.0.0 on September 8, and most Free installs have not taken it. WordPress.org’s statistics API showed 31.4 percent of reporting installs on the 5.0 series on October 20, against 56.06 percent on 1.5 and 5.44 percent on 1.4, with 7.1 percent grouped as “other.” There is no 1.5.18: the last release on the old branch is 1.5.17, the highest version Wordfence lists as affected. Wordfence’s post reports no attacks, and we found no reports of any. The CVE record was still reserved when we checked at 19:33 UTC (the CVE Services API returned the state RESERVED and NVD returned no record), and an attack needs an administrator to migrate from a package built after the payload was planted.

Below: how the attack works in Wordfence’s account, what we confirmed by reading the code of Duplicator 1.5.17, 5.0.0 and 5.0.6, how the install base splits and why exposure is narrower than the install count, what to do first, and where this fits.

The attack, step by step

Wordfence calls this “a second-order vulnerability”: the harmful input is stored in one request and does its damage in a later, legitimate action. Duplicator builds a package: the site’s files, a copy of its database and a standalone installer that rebuilds the site somewhere else. During a standard migration the installer rewrites values such as the old site address and file path to the new ones. Some of those values sit inside PHP-serialized strings, which record lengths and class names, so the installer parses them in order to repair them. Wordfence says the function that does the parsing, DUPX_UpdateEngine::unserializeTest(), passes the value to PHP’s native unserialize() without restricting which classes may be created. PHP’s manual describes what that allows: when the value is an object, “PHP will automatically attempt to call the __unserialize() or __wakeup() methods (if one exists),” and “Unserialization can result in code being loaded and executed due to object instantiation and autoloading.”

The attacker’s part is a comment. Wordfence says wp-comments-post.php takes a comment with no account, cookie or nonce, and that a comment waiting for moderation is still saved in the database and copied into the next package. We checked WordPress core on GitHub: wp-comments-post.php contains no nonce check, and the submission handler in comment.php asks for a nonce only on the path for users who hold the unfiltered_html capability. The installer’s search-and-replace engine also decodes values that are entirely base64, so the comment can look like a block of encoded text while carrying a serialized object.

1. An unauthenticated visitor posts a comment that holds an encoded PHP object.
2. WordPress stores it, approved or not.
3. An administrator builds a new Duplicator package, which copies the stored value.
4. The administrator uses that package for a standard migration or import.
5. The installer’s Update Data step decodes and deserializes the stored value, and the object’s methods run.

The consequences differ by edition, according to Wordfence.

Wordfence states the boundaries itself. The payload must be stored before the package is built, and the administrator must then run a standard migration or import that reaches the replacement step. Wordfence did not demonstrate the chain through restore or recovery modes, which do not use the same engine. It also says “Comment moderation does not stop this chain because an unapproved comment is still stored and can be copied into a package,” and that disabling public comments “removes the carrier we demonstrated, but it is not a substitute for updating because other attacker-controlled database content may also reach the vulnerable migration engine.” In the Pro case the takeover does not reveal the original site’s database or its credentials; it runs on a separate database the attacker controls.

The timeline in Wordfence’s post

Public disclosure came 50 days after the vendor was told and 42 days after the patch. The weekdays and day counts are our arithmetic.

What the plugin code shows

We downloaded Duplicator 1.5.17, 5.0.0 and 5.0.6 from WordPress.org and read the installer code. We did not run it. In each place we checked, the code matches Wordfence’s account.

Three details from the 1.5.17 engine matter for defenders. First, the parsing test is reached through fixSerializedAndCheck(), which the engine calls for any cell that still looks like serialized data after replacement. Second, the engine only works on a cell that contains one of the strings the migration is replacing, such as the old site address, in plain form or after base64 decoding. A payload aimed at a known site can include that address, so this is a precondition rather than a barrier, but it fits Wordfence’s result that restore and recovery modes, which skip the replacement step, did not trigger the bug. Third, the base64 path accepts only a value that is base64 from its first character to its last: a character-set check, a strict decode, and a re-encode that must reproduce the input exactly.

The vendor’s changelog does not name the change. The entries for 5.0.0 through 5.0.6 on Duplicator’s changelog page do not mention deserialization or the CVE. The nearest line, under 5.0.0, reads “Updated bundled PHP and JavaScript dependencies to address published security advisories.” We did not find a separate Duplicator advisory. PHP’s manual also goes further than the fix does: its warning says “Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes.” The 5.0.0 change closes the object-creation route Wordfence demonstrated; we did not test the installer or look for other consequences of parsing hostile serialized text.

Who is exposed, and how many have updated

WordPress.org publishes the share of reporting installs by version series. On October 20 it read as follows.

At least 61.5 percent of reporting installs sit on a series that Wordfence lists as vulnerable. Duplicator Pro is sold from duplicator.com, so these figures cover only the Free edition and say nothing about how many Pro customers have updated.

The install count overstates the practical exposure. An attack needs three things to line up: a planted payload, a package built afterward, and a standard migration or import from that package. Wordfence says simply creating a backup does not trigger the flaw, so the risk sits with sites that migrate or import. But a planted comment can wait in the database until the next migration, whenever that is, and in Wordfence’s Free-edition test the command ran as the web-server user, the user the site’s PHP runs as.

On severity, Wordfence’s page gives the score without a vector we could read. The number is still informative: 8.8 is exactly what CVSS 3.1 assigns to a network attack with low complexity and no privileges that needs user interaction, leaves the scope unchanged and has high impact on confidentiality, integrity and availability, which would fit the administrator’s migration step. With no user interaction, the same vector scores 9.8. That is our arithmetic, not Wordfence’s statement.

We cannot tell from the data why so many sites have not moved. The requirements are not the reason: the readme headers of 1.5.17, 5.0.0 and 5.0.6 give the same minimums, WordPress 5.3 and PHP 7.4. What changed is the product. Duplicator’s changelog describes 5.0.0 as moving Lite onto the engine Pro uses, with a redesigned backup experience and a new AutoTune feature, and the fix has no backport to 1.5.x, so a site that wants the fix has to take the redesign. WordPress.org’s download counter shows how updates arrive: six days between September 9 and October 15 saw 291,900 to 327,694 downloads each, while every other day from September 6 to October 19 stayed between 7,132 and 58,828. Our reading is that releases reach a block of sites that update on their own and miss the rest; the counter does not say why.

Updating does not repair packages that already exist. Wordfence says an old package keeps the installer from the version that built it, and its tests bear that out. Duplicator Pro 5.0.5’s normal Import ran the older installer from a package built with Pro 4.6.10 and reached the vulnerable path, while its automatic Restore forced restore mode, skipped the search-and-replace step and did not trigger the bug. Duplicator Free 5.0.0 declined to restore a package built with 1.5.17 automatically and told the administrator to download it and run its installer by hand, which can still reach the vulnerable code if the package holds a malicious stored value.

What to do first

1. Update Duplicator Free and Pro to 5.0.0 or later before building another package. The current Free release on WordPress.org is 5.0.6, updated on October 14.
2. Build a fresh package before any migration or import. Wordfence says an older package is not dangerous while it sits in storage, but it carries its original installer, so a standard migration from it can still reach the old code. Wordfence also advises removing publicly accessible installer files that are no longer needed.
3. If you cannot update today, do not run a standard migration or import from a package built with an affected version. Closing comments until you can update removes only the carrier Wordfence demonstrated, not the flaw.
4. Look for a planted comment with the query in the next section. It is a quick check, not a clean bill of health.
5. Know what your firewall covers. Wordfence says the generic object injection protection in its firewall already gave all of its users a degree of protection, and that the vulnerability-specific rule is for Premium, Care and Response customers now and for free users on November 14. Wordfence sells those plans. Treat the firewall as a layer, not a fix.

A quick look for the planted comment

The query lists comments that contain no spaces, run longer than 40 characters and begin with Tzo, YTo or Qzo. That is how base64 text starts when the decoded text starts with O:, a: or C:, the serialization tags for an object, an array and a custom-serialized object. Replace wp_ with your table prefix, save the query as check.sql and run wp db query < check.sql.

SELECT comment_ID, comment_approved, comment_date_gmt, LENGTH(comment_content) AS len
FROM wp_comments
WHERE comment_content NOT LIKE '% %'
  AND LENGTH(comment_content) > 40
  AND (comment_content LIKE 'Tzo%'
    OR comment_content LIKE 'YTo%'
    OR comment_content LIKE 'Qzo%');

A hit deserves a closer look. A clean result proves little, because Wordfence says other attacker-controlled database content may also reach the engine. We checked the three prefixes in Python and the query’s logic on nine sample rows in SQLite; we did not run it on MySQL or MariaDB.

Where this fits

Duplicator has been a target before. NVD’s record for CVE-2020-11738 describes a directory traversal in versions before 1.3.28, and CISA added it to its Known Exploited Vulnerabilities catalog on November 3, 2021. Wordfence’s post does not say this flaw is under attack; given that history, we would read that as a snapshot, not a forecast.

The pattern is becoming familiar. Wordfence’s earlier Events Calendar chains also started with an anonymous comment, though those fired when the page was rendered, and this one waits for a migration. Argus is also the system credited with the Ghostscript flaw we covered on October 12. Wordfence says it helped trace attacker-controlled data “beyond the request that stored it” into the later migration, and calls the result “a relationship that endpoint-by-endpoint testing can easily miss.” Backup tools are also where this month’s UpdraftCentral story sits: attackers holding UpdraftCentral keys install backdoor plugins, and no UpdraftPlus update stops it.

Sources and method

Wordfence’s blog page returns an empty response to scripted fetchers, so we read the full text of its disclosure from its RSS feed; every Wordfence quotation comes from that text. The code facts come from the Duplicator 1.5.17, 5.0.0 and 5.0.6 packages downloaded from WordPress.org: we read the installer’s update engine, the helper that unserializes, the bundled Requests library and the readme headers, and searched the installer folder for raw unserialize calls. The 5.0.0 package’s files carry the date September 8, 2026, the release date Wordfence gives. Install counts, version shares, the release list and the download counter come from WordPress.org’s plugin APIs, queried on October 20, and the CVE state from the CVE Services API and NVD at 19:33 UTC. The PHP quotations come from the PHP manual page for unserialize, the changelog quotation from Duplicator’s changelog page, the WordPress core facts from files in WordPress’s development repository (trunk), and the CVE-2020-11738 facts from NVD and CISA’s KEV feed. The 8.8 score is Wordfence’s; the shares, day counts, weekdays and the CVSS check are our arithmetic. We did not run PHP or the installer, did not test any exploit, and did not examine Duplicator Pro, so everything about Pro rests on Wordfence’s account and the vendor confirmation it reports. Times are UTC.