33,183 or 145: two ZoomEye queries for the same WordPress plugin, and only one of them is an install count
A researcher published a second-order PHP object injection flaw in the Duplicator WordPress plugin on 22 October 2026, tracked as CVE-2026-82814 and scored 8.8. Two ZoomEye queries run for this article produced counts separated by two orders of magnitude. Understanding the gap is more useful than either number.
The two measurements
| Query | Matches | Collected (UTC) |
|---|---|---|
http.body="Duplicator" |
33,183 | 22 Oct 2026, 05:36 |
http.body="/wp-content/plugins/duplicator" |
145 | 22 Oct 2026, 05:37 |
Search links appear in the references. The first query matches any HTTP body containing the token "Duplicator", which includes plugin pages, blog posts about the plugin, documentation, tutorials, and installer pages installed by sites that no longer run it. The second matches a specific asset path, which is closer to an installation signal.
Why the narrow query is the better one, and still not a count of vulnerable sites
The path query is narrower because /wp-content/plugins/duplicator appears in a page body when a WordPress site loads an asset from that plugin directory. That is a stronger indicator of an installation than a text mention.
It remains an indicator rather than an inventory. A site that has deactivated but not deleted the plugin may still emit the path. A site that removes plugin asset query strings, concatenates assets or serves from a CDN may not. A site that hardened against enumeration may hide the path entirely. And the plugin reports more than one million active installations, which the 145 figure obviously does not represent.
State that last point plainly to anyone who asks whether 145 means the world has 145 vulnerable sites. It does not. It means 145 assets in the tested population emit that path in a response body that ZoomEye indexed.
What the flaw does, because it changes what to look for
The vulnerability is a second-order PHP object injection. An unauthenticated attacker places a base64-encoded PHP object in an ordinary WordPress comment, where it stays dormant. If an administrator later creates a Duplicator package containing that comment and uses the package to migrate the site, the standalone installer treats the stored value as a PHP object and activates it.
The activation happens in DUPX_UpdateEngine::unserializeTest(), which decodes base64 strings and passes them to PHP's native unserialize() without restricting allowed classes. In Duplicator Free up to 1.5.17, the result is arbitrary operating-system command execution as the web-server user. In Duplicator Pro up to 4.6.10, the Duplicator\Libs\Index\IndexList destructor deletes arbitrary files, including wp-config.php, which can reopen the WordPress setup process.
Fixed in 5.0.0, where SnapUtil::safeUnserialize() sets allowed_classes to false.
The exposure question that actually decides risk
Neither query can see whether a site holds a dormant payload in its comment table, and neither can see whether an old backup archive exists. The second condition is the one the vendor guidance addresses, because updating the plugin does not fix archives generated before the patch. Wordfence advises generating fresh packages with the patched release before any migration.
Those two invisible conditions explain why an installation count does not convert into a risk count. A site running an affected version with no archives and no pending comments is not exposed to the described path. A site that already migrated from an old archive has a different question to answer, and no external scan can raise it.
Turning 145 into something an organisation can use
- Use the path query as a fingerprint discovery step, then verify against your own inventory. The external result narrows where the plugin appears; it does not establish your version.
- Check the installed version on every WordPress site you operate. Anything below 5.0.0 on Duplicator Free, or below 5.0.0 on Duplicator Pro, is in range.
- List backup archives with creation dates. Any archive created before the upgrade to 5.0.0 should be replaced rather than reused.
- If a migration ran on an older archive, look for both impacts: unexpected processes spawned by the web-server user, and a
wp-config.phpthat is missing with the setup wizard reachable again. The fourth step is the only one that detects the second-order path after the fact, and it depends on a log that many WordPress sites do not keep.
Two numbers, one honest conclusion
The pair of results makes a useful teaching case about query scope. A broad body query returns 33,183 and a path-specific query returns 145 for the same plugin on the same day. Neither is wrong, and neither is an install count for a plugin with over a million active installations.
The reporting itself does not quantify affected installations, does not state whether any archive has been used as a delivery container, and confirms no public proof of concept and no active exploitation. The EPSS figure quoted is 0.5% for 30 days, a forecast rather than an observation.
References
- SecurityOnline, "Duplicator WordPress Plugin Patched for High-Severity PHP Object Injection Vulnerability", 22 October 2026: https://securityonline.info/duplicator-wordpress-plugin-php-object-injection/
- Wordfence Threat Intelligence report on CVE-2026-82814 referenced in the reporting (discovery 30 August 2026).
- ZoomEye search for
http.body="Duplicator", 33,183 matches, 22 October 2026 05:36 UTC: https://www.zoomeye.ai/searchResult?q=aHR0cC5ib2R5PSJEdXBsaWNhdG9yIg%3D%3D - ZoomEye search for
http.body="/wp-content/plugins/duplicator", 145 matches, 22 October 2026 05:37 UTC: https://www.zoomeye.ai/searchResult?q=aHR0cC5ib2R5PSIvd3AtY29udGVudC9wbHVnaW5zL2R1cGxpY2F0b3Ii
Top comments (0)